linux-stable.git/drivers/net/wireless, branch v3.2.19 Linux kernel stable tree rtlwifi: Preallocate USB read buffers and eliminate kalloc in read routine 2012-05-30T23:44:05+00:00 Larry Finger Larry.Finger@lwfinger.net 2012-03-19T20:44:31+00:00 e290f74d471e775b61f5639b4c03c5cc71114578 commit a7959c1394d4126a70a53b914ce4105f5173d0aa upstream. The current version of rtlwifi for USB operations uses kmalloc to acquire a 32-bit buffer for each read of the device. When _usb_read_sync() is called with the rcu_lock held, the result is a "sleeping function called from invalid context" BUG. This is reported for two cases in https://bugzilla.kernel.org/show_bug.cgi?id=42775. The first case has the lock originating from within rtlwifi and could be fixed by rearranging the locking; however, the second originates from within mac80211. The kmalloc() call is removed from _usb_read_sync() by creating a ring buffer pointer in the private area and allocating the buffer data in the probe routine. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> [This version will apply to 3.2 and earlier. - Larry] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit a7959c1394d4126a70a53b914ce4105f5173d0aa upstream.

The current version of rtlwifi for USB operations uses kmalloc to
acquire a 32-bit buffer for each read of the device. When
_usb_read_sync() is called with the rcu_lock held, the result is
a "sleeping function called from invalid context" BUG. This is
reported for two cases in https://bugzilla.kernel.org/show_bug.cgi?id=42775.
The first case has the lock originating from within rtlwifi and could
be fixed by rearranging the locking; however, the second originates from
within mac80211. The kmalloc() call is removed from _usb_read_sync()
by creating a ring buffer pointer in the private area and
allocating the buffer data in the probe routine.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[This version will apply to 3.2 and earlier. - Larry]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
b43legacy: Fix error due to MMIO access with SSB unpowered 2012-05-30T23:43:59+00:00 Larry Finger Larry.Finger@lwfinger.net 2012-05-06T21:01:05+00:00 5bd4e74937adf1f00f29e5983fe1b364accb74ea commit 8f4b20388fa77226a3605627a33a23f90d559e50 upstream. There is a dummy read of a PCI MMIO register that occurs before the SSB bus has been powered, which is an error. This bug has not been seen earlier, but was apparently exposed when udev was updated to version 182. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 8f4b20388fa77226a3605627a33a23f90d559e50 upstream.

There is a dummy read of a PCI MMIO register that occurs before the SSB bus
has been powered, which is an error. This bug has not been seen earlier,
but was apparently exposed when udev was updated to version 182.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
brcm80211: smac: fix endless retry of A-MPDU transmissions 2012-05-20T21:56:46+00:00 Arend van Spriel arend@broadcom.com 2012-02-09T20:08:58+00:00 3af384d0469065da1646d275efffb7dbbe0e435c commit 5e379203c7788b7af01150bfadbc74d2797a2ef4 upstream. The A-MPDU code checked against a retry limit, but it was using the wrong variable to do so. This patch fixes this to assure proper retry mechanism. This problem had a side-effect causing the mac80211 flush callback to remain waiting forever as well. That side effect has been fixed by commit by Stanislaw Gruszka: commit f96b08a7e6f69c0f0a576554df3df5b1b519c479 Date: Tue Jan 17 12:38:50 2012 +0100 brcmsmac: fix tx queue flush infinite loop Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42576 Cc: Stanislaw Gruszka <sgruszka@redhat.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Alwin Beukers <alwin@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 5e379203c7788b7af01150bfadbc74d2797a2ef4 upstream.

The A-MPDU code checked against a retry limit, but it was using
the wrong variable to do so. This patch fixes this to assure
proper retry mechanism.

This problem had a side-effect causing the mac80211 flush callback
to remain waiting forever as well. That side effect has been fixed
by commit by Stanislaw Gruszka:

commit f96b08a7e6f69c0f0a576554df3df5b1b519c479
Date:   Tue Jan 17 12:38:50 2012 +0100

    brcmsmac: fix tx queue flush infinite loop

    Reference:
    https://bugzilla.kernel.org/show_bug.cgi?id=42576

Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Alwin Beukers <alwin@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
brcm80211: smac: pass missing argument to 'brcms_b_mute' 2012-05-20T21:56:38+00:00 Jonathan Nieder jrnieder@gmail.com 2012-05-12T00:35:33+00:00 7f2595b65b39999f10347c871cd5146f7bc17532 [Not needed upstream --- this bug is specific to 3.2.y.] Commit c6c44893c864, which removes the flag argument from brcms_b_mute, is not part of 3.2.y, and we forgot to adjust a new call accordingly when applying commit badc4f07622f ("brcm80211: smac: resume transmit fifo upon receiving frames"). drivers/net/wireless/brcm80211/brcmsmac/main.c: In function 'brcms_c_recvctl': drivers/net/wireless/brcm80211/brcmsmac/main.c:7882:4: error: too few arguments to function 'brcms_b_mute' drivers/net/wireless/brcm80211/brcmsmac/main.c:2538:13: note: declared here Earlier build tests missed this because they didn't include this driver due to 'depends on BCMA=n'. Reported-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
[Not needed upstream --- this bug is specific to 3.2.y.]

Commit c6c44893c864, which removes the flag argument from brcms_b_mute,
is not part of 3.2.y, and we forgot to adjust a new call accordingly
when applying commit badc4f07622f ("brcm80211: smac: resume transmit
fifo upon receiving frames").

 drivers/net/wireless/brcm80211/brcmsmac/main.c: In function 'brcms_c_recvctl':
 drivers/net/wireless/brcm80211/brcmsmac/main.c:7882:4: error: too few arguments to function 'brcms_b_mute'
 drivers/net/wireless/brcm80211/brcmsmac/main.c:2538:13: note: declared here

Earlier build tests missed this because they didn't include this driver
due to 'depends on BCMA=n'.

Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
iwlwifi: use 6000G2B for 6030 device series 2012-05-11T12:15:03+00:00 Wey-Yi Guy wey-yi.w.guy@intel.com 2012-04-25T15:10:08+00:00 20d6f19dca576a671ab61403c366c7154f802b36 commit 1ed2ec37b44e86eaa8e0a03b908a39c80f65ee45 upstream. "iwlwifi: use correct released ucode version" change the ucode api ok from 6000G2 to 6000G2B, but it shall belong to 6030 device series, not the 6005 device series. Fix it Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 1ed2ec37b44e86eaa8e0a03b908a39c80f65ee45 upstream.

"iwlwifi: use correct released ucode version" change
the ucode api ok from 6000G2 to 6000G2B, but it shall belong
to 6030 device series, not the 6005 device series. Fix it

Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
iwlwifi: use correct released ucode version 2012-05-11T12:15:02+00:00 Meenakshi Venkataraman meenakshi.venkataraman@intel.com 2012-04-22T14:55:27+00:00 37273f55830f0919d543250d191e1633ff53841c commit 78cbcf2b9dbe0565820dc7721316f9c401000a68 upstream. Report correctly the latest released version of the iwlwifi firmware for all iwlwifi-supported devices. Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 78cbcf2b9dbe0565820dc7721316f9c401000a68 upstream.

Report correctly the latest released version
of the iwlwifi firmware for all
iwlwifi-supported devices.

Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
iwlagn: allow up to uCode API 6 for 6000 devices 2012-05-11T12:15:02+00:00 Johannes Berg johannes.berg@intel.com 2011-11-04T14:22:37+00:00 13cb8e3a067538c5aacc846a032985d2b608bccd commit b914811524fbe9e91fe50845f5d7bd4316b8a6ee upstream. Since the uCode hasn't been released (yet?), warn only if using older than API 4, but load anything up to API 6. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit b914811524fbe9e91fe50845f5d7bd4316b8a6ee upstream.

Since the uCode hasn't been released (yet?),
warn only if using older than API 4, but load
anything up to API 6.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
iwlwifi: fix hardware queue programming 2012-05-11T12:14:56+00:00 Johannes Berg johannes.berg@intel.com 2012-04-23T21:17:50+00:00 e4c7f8df58b0edfa1912cd54bded9d543693903e commit 5ef4acd58ab2abd0dd0c8e3cacd61a0dc5d73646 upstream. Newer devices have 20 (5000 series) or 30 (6000 series) hardware queues, rather than the 16 that 4965 had. This was added to the driver a long time ago, but improperly: the queue registers for the higher queues aren't just continuations of the registers for the first 16 queues, they are in other places. Therefore, the hardware would lock up when trying to activate queue 16 or above and the device would have to be restarted. Thanks goes to Emmanuel who identified this and told me how the queue programming should be done. Note that we don't use queues 20 and higher today and doing so needs more work than this. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 5ef4acd58ab2abd0dd0c8e3cacd61a0dc5d73646 upstream.

Newer devices have 20 (5000 series) or 30 (6000 series)
hardware queues, rather than the 16 that 4965 had. This
was added to the driver a long time ago, but improperly:
the queue registers for the higher queues aren't just
continuations of the registers for the first 16 queues,
they are in other places. Therefore, the hardware would
lock up when trying to activate queue 16 or above and
the device would have to be restarted.

Thanks goes to Emmanuel who identified this and told me
how the queue programming should be done.

Note that we don't use queues 20 and higher today and
doing so needs more work than this.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
iwlwifi: do not nulify ctx->vif on reset 2012-05-11T12:14:55+00:00 Stanislaw Gruszka sgruszka@redhat.com 2012-04-18T15:01:15+00:00 77a23ae9ae9e552e885292b120d19434c25aad89 commit 8db4c7e25d153fb049e81715d72fa3be3a0c3b69 upstream. ctx->vif is dereferenced in different part of iwlwifi code, so do not nullify it. This should address at least one of the possible reasons of WARNING at iwlagn_mac_remove_interface, and perhaps some random crashes when firmware reset is performed. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.2: - Change filename iwl-mac80211.c to iwl-core.c - Change context in iwlagn_prepare_restart()] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 8db4c7e25d153fb049e81715d72fa3be3a0c3b69 upstream.

ctx->vif is dereferenced in different part of iwlwifi code, so do not
nullify it.

This should address at least one of the possible reasons of WARNING at
iwlagn_mac_remove_interface, and perhaps some random crashes when
firmware reset is performed.

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[bwh: Backported to 3.2:
 - Change filename iwl-mac80211.c to iwl-core.c
 - Change context in iwlagn_prepare_restart()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
wl1251: fix crash on remove due to leftover work item 2012-05-11T12:14:55+00:00 Grazvydas Ignotas notasas@gmail.com 2012-04-26T20:07:44+00:00 5183d50f79157ba0c0e4fcdf882421e6bdabc562 commit 4c1bcdb5a3354b250b82a67549f57ac27a3bb85f upstream. This driver currently leaves elp_work behind when stopping, which occasionally results in data corruption because work function ends up accessing freed memory, typical symptoms of this are various worker_thread crashes. Fix it by cancelling elp_work. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 4c1bcdb5a3354b250b82a67549f57ac27a3bb85f upstream.

This driver currently leaves elp_work behind when stopping, which
occasionally results in data corruption because work function ends
up accessing freed memory, typical symptoms of this are various
worker_thread crashes. Fix it by cancelling elp_work.

Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>