Skip to content
  1. Jan 18, 2012
  3. Jan 17, 2012
  5. Jan 16, 2012
  7. Jan 14, 2012
    • 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