1. 17 Jan, 2012 28 commits
  2. 16 Jan, 2012 9 commits
  3. 13 Jan, 2012 3 commits
    • Johannes Berg's avatar
      mac80211: fix no-op authorized transitions · 543d1b92
      Johannes Berg authored
      When userspace attempts to authorize a station
      that is already authorized, nothing happens as
      you'd expect. Similarly, when it unauthorizes
      a station that is associated, nothing happens.
      
      However, when it unauthorizes a station that
      isn't even associated yet, we erroneously try
      to move the station to associated. This seems
      to happen occasionally as a result of a race
      when wpa_supplicant attempts to unauthorize
      the port in managed mode. Particularly with my
      new patches to keep stations, it can then move
      a station into ASSOCIATED state before we have
      really associated, which is really confusing.
      
      I introduced this bug in
      "mac80211: refactor station state transitions"
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      543d1b92
    • Stanislaw Gruszka's avatar
      rt2800pci: fix spurious interrupts generation · dfd00c4c
      Stanislaw Gruszka authored
      Same devices can generate interrupt without properly setting bit in
      INT_SOURCE_CSR register (spurious interrupt), what will cause IRQ line
      will be disabled by interrupts controller driver.
      
      We discovered that clearing INT_MASK_CSR stops such behaviour. We
      previously first read that register, and then clear all know interrupt
      sources bits and do not touch reserved bits. After this patch, we write
      to all register content (I believe writing to reserved bits on that
      register will not cause any problems, I tested that on my rt2800pci
      device).
      
      This fix very bad performance problem, practically making device
      unusable (since worked without interrupts), reported in:
      https://bugzilla.redhat.com/show_bug.cgi?id=658451
      
      We previously tried to workaround that issue in commit
      4ba7d999 "rt2800pci: handle spurious
      interrupts", but it was reverted in commit
      82e5fc2a
      as thing, that will prevent to detect real spurious interrupts.
      Reported-and-tested-by: default avatarAmir Hedayaty <hedayaty@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Acked-by: default avatarGertjan van Wingerde <gwingerde@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      dfd00c4c
    • Dan Carpenter's avatar
      ipw2x00: signedness bug handling frame length · 92c1ff1f
      Dan Carpenter authored
      This is basically just a cleanup.  Large positive numbers get counted as
      negative but then get implicitly cast to positive again for the checks
      that matter.
      
      This does make a small difference in ipw_handle_promiscuous_rx() when we
      test "if (unlikely((len + IPW_RX_FRAME_SIZE) > skb_tailroom(rxb->skb)))"
      It should return there, but we don't return until a couple lines later
      when we test "if (len > IPW_RX_BUF_SIZE - sizeof(struct ipw_rt_hdr)) {".
      The difference is that in the second test the sizeof() means that there
      is an implied cast to unsigned.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      92c1ff1f