linux-toradex.git/drivers/net, branch v3.2.33 Linux kernel for Apalis and Colibri modules Revert "ath9k_hw: Updated AR9003 tx gain table for 5GHz" 2012-10-30T23:26:57+00:00 Felix Fietkau nbd@openwrt.org 2012-10-17T11:50:43+00:00 36aa56684247a98e92bf5ca97d8c0833cbe9b909 commit 73b26df5fa1a6245d6fc982362518b620bc7c2fe upstream. This reverts commit a240dc7b3c7463bd60cf0a9b2a90f52f78aae0fd. This commit is reducing tx power by at least 10 db on some devices, e.g. the Buffalo WZR-HP-G450H. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Cc: rmanohar@qca.qualcomm.com Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 73b26df5fa1a6245d6fc982362518b620bc7c2fe upstream.

This reverts commit a240dc7b3c7463bd60cf0a9b2a90f52f78aae0fd.

This commit is reducing tx power by at least 10 db on some devices,
e.g. the Buffalo WZR-HP-G450H.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: rmanohar@qca.qualcomm.com
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
iwlwifi: fix 6000 series channel switch command 2012-10-30T23:26:48+00:00 Johannes Berg johannes.berg@intel.com 2012-09-25T14:40:12+00:00 735dbc9e51ae26e10eb3a0f277cfd2d81ca675bb commit 8f7b8db6e0557c8437adf9371e020cd89a7e85dc upstream. The channel switch command for 6000 series devices is larger than the maximum inline command size of 320 bytes. The command is therefore refused with a warning. Fix this by allocating the command and using the NOCOPY mechanism. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> [bwh: Backported to 3.2: adjust filename, context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 8f7b8db6e0557c8437adf9371e020cd89a7e85dc upstream.

The channel switch command for 6000 series devices
is larger than the maximum inline command size of
320 bytes. The command is therefore refused with a
warning. Fix this by allocating the command and
using the NOCOPY mechanism.

Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
net/wireless: ipw2200: Fix panic occurring in ipw_handle_promiscuous_tx() 2012-10-30T23:26:47+00:00 Stanislav Yakovlev stas.yakovlev@gmail.com 2012-10-15T14:14:32+00:00 de5bfe1d956feac7a0ed4df18a3f5eefd8c75a1c commit bf11315eeda510ea4fc1a2bf972d8155d31d89b4 upstream. The driver does not count space of radiotap fields when allocating skb for radiotap packet. This leads to kernel panic with the following call trace: ... [67607.676067] [<c152f90f>] error_code+0x67/0x6c [67607.676067] [<c142f831>] ? skb_put+0x91/0xa0 [67607.676067] [<f8cf5e5b>] ? ipw_handle_promiscuous_tx+0x16b/0x2d0 [ipw2200] [67607.676067] [<f8cf5e5b>] ipw_handle_promiscuous_tx+0x16b/0x2d0 [ipw2200] [67607.676067] [<f8cf899b>] ipw_net_hard_start_xmit+0x8b/0x90 [ipw2200] [67607.676067] [<f8741c5a>] libipw_xmit+0x55a/0x980 [libipw] [67607.676067] [<c143d3e8>] dev_hard_start_xmit+0x218/0x4d0 ... This bug was found by VittGam. https://bugzilla.kernel.org/show_bug.cgi?id=43255 Signed-off-by: Stanislav Yakovlev <stas.yakovlev@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit bf11315eeda510ea4fc1a2bf972d8155d31d89b4 upstream.

The driver does not count space of radiotap fields when allocating skb for
radiotap packet. This leads to kernel panic with the following call trace:

...
[67607.676067] [<c152f90f>] error_code+0x67/0x6c
[67607.676067] [<c142f831>] ? skb_put+0x91/0xa0
[67607.676067] [<f8cf5e5b>] ? ipw_handle_promiscuous_tx+0x16b/0x2d0 [ipw2200]
[67607.676067] [<f8cf5e5b>] ipw_handle_promiscuous_tx+0x16b/0x2d0 [ipw2200]
[67607.676067] [<f8cf899b>] ipw_net_hard_start_xmit+0x8b/0x90 [ipw2200]
[67607.676067] [<f8741c5a>] libipw_xmit+0x55a/0x980 [libipw]
[67607.676067] [<c143d3e8>] dev_hard_start_xmit+0x218/0x4d0
...

This bug was found by VittGam.
https://bugzilla.kernel.org/show_bug.cgi?id=43255

Signed-off-by: Stanislav Yakovlev <stas.yakovlev@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
skge: Add DMA mask quirk for Marvell 88E8001 on ASUS P5NSLI motherboard 2012-10-30T23:26:33+00:00 Graham Gower graham.gower@gmail.com 2012-10-08T08:34:50+00:00 380fd8550acc9c04fb2b7835a9663b5a0e53b840 [ Upstream commit a2af139ff1cd85df586690ff626619ab1ee88b0a ] Marvell 88E8001 on an ASUS P5NSLI motherboard is unable to send/receive packets on a system with >4gb ram unless a 32bit DMA mask is used. This issue has been around for years and a fix was sent 3.5 years ago, but there was some debate as to whether it should instead be fixed as a PCI quirk. http://www.spinics.net/lists/netdev/msg88670.html However, 18 months later a similar workaround was introduced for another chipset exhibiting the same problem. http://www.spinics.net/lists/netdev/msg142287.html Signed-off-by: Graham Gower <graham.gower@gmail.com> Signed-off-by: Jan Ceuleers <jan.ceuleers@computer.org> Acked-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
[ Upstream commit a2af139ff1cd85df586690ff626619ab1ee88b0a ]

Marvell 88E8001 on an ASUS P5NSLI motherboard is unable to send/receive
packets on a system with >4gb ram unless a 32bit DMA mask is used.

This issue has been around for years and a fix was sent 3.5 years ago, but
there was some debate as to whether it should instead be fixed as a PCI quirk.
http://www.spinics.net/lists/netdev/msg88670.html

However, 18 months later a similar workaround was introduced for another
chipset exhibiting the same problem.
http://www.spinics.net/lists/netdev/msg142287.html

Signed-off-by: Graham Gower <graham.gower@gmail.com>
Signed-off-by: Jan Ceuleers <jan.ceuleers@computer.org>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
e1000: fix vlan processing regression 2012-10-30T23:26:29+00:00 Jiri Pirko jpirko@redhat.com 2012-03-20T18:10:01+00:00 e48980d0eff084cc9ec51df85d655739c235668d commit 52f5509fe8ccb607ff9b84ad618f244262336475 upstream. This patch fixes a regression introduced by commit "e1000: do vlan cleanup (799d531)". Apparently some e1000 chips (not mine) are sensitive about the order of setting vlan filter and vlan stripping/inserting functionality. So this patch changes the order so it's the same as before vlan cleanup. Reported-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Jiri Pirko <jpirko@redhat.com> Tested-by: Ben Greear <greearb@candelatech.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> [Jonathan Nieder: It doesn't apply cleanly to kernels before v3.3-rc1~182^2~581 (net: introduce and use netdev_features_t for device features sets) but a backport is straightforward.] Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Tested-by: Andrey Jr. Melnikov <temnota@kmv.ru> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 52f5509fe8ccb607ff9b84ad618f244262336475 upstream.

This patch fixes a regression introduced by commit "e1000: do vlan
cleanup (799d531)".

Apparently some e1000 chips (not mine) are sensitive about the order of
setting vlan filter and vlan stripping/inserting functionality. So this
patch changes the order so it's the same as before vlan cleanup.

Reported-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Tested-by: Ben Greear <greearb@candelatech.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[Jonathan Nieder: It doesn't apply cleanly to kernels before
v3.3-rc1~182^2~581 (net: introduce and use netdev_features_t for
device features sets) but a backport is straightforward.]
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Tested-by: Andrey Jr. Melnikov <temnota@kmv.ru>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
e1000: fix lockdep splat in shutdown handler 2012-10-17T02:50:10+00:00 Jesse Brandeburg jesse.brandeburg@intel.com 2012-01-04T20:23:33+00:00 79c43665e46e20bf3b1029e0cb28e294b84ba6c0 commit 3a3847e007aae732d64d8fd1374126393e9879a3 upstream. As reported by Steven Rostedt, e1000 has a lockdep splat added during the recent merge window. The issue is that cancel_delayed_work is called while holding our private mutex. There is no reason that I can see to hold the mutex during pci shutdown, it was more just paranoia that I put the mutex_lock around the call to e1000_down. In a quick survey lots of drivers handle locking differently when being called by the pci layer. The assumption here is that we don't need the mutexes' protection in this function because the driver could not be unloaded while in the shutdown handler which is only called at reboot or poweroff. Reported-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Steven Rostedt <rostedt@goodmis.org> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 3a3847e007aae732d64d8fd1374126393e9879a3 upstream.

As reported by Steven Rostedt, e1000 has a lockdep splat added
during the recent merge window.  The issue is that
cancel_delayed_work is called while holding our private mutex.

There is no reason that I can see to hold the mutex during pci
shutdown, it was more just paranoia that I put the mutex_lock
around the call to e1000_down.

In a quick survey lots of drivers handle locking differently when
being called by the pci layer.  The assumption here is that we
don't need the mutexes' protection in this function because
the driver could not be unloaded while in the shutdown handler
which is only called at reboot or poweroff.

Reported-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Steven Rostedt <rostedt@goodmis.org>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
r8169: 8168c and later require bit 0x20 to be set in Config2 for PME signaling. 2012-10-17T02:50:01+00:00 Francois Romieu romieu@fr.zoreil.com 2012-04-17T09:12:01+00:00 68deb46c5269e37f1b1ca257a4b9f3e30e2fa786 commit d387b427c973974dd619a33549c070ac5d0e089f upstream. The new 84xx stopped flying below the radars. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Hayes Wang <hayeswang@realtek.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit d387b427c973974dd619a33549c070ac5d0e089f upstream.

The new 84xx stopped flying below the radars.

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
r8169: Config1 is read-only on 8168c and later. 2012-10-17T02:50:00+00:00 Francois Romieu romieu@fr.zoreil.com 2012-04-17T09:10:11+00:00 65d75135acc35455003acb92d8381a055eec15cb commit 851e60221926a53344b4227879858bef841b0477 upstream. Suggested by Hayes. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Hayes Wang <hayeswang@realtek.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 851e60221926a53344b4227879858bef841b0477 upstream.

Suggested by Hayes.

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
rapidio/rionet: fix multicast packet transmit logic 2012-10-17T02:49:38+00:00 Alexandre Bounine alexandre.bounine@idt.com 2012-10-05T00:15:48+00:00 927ba3c8a63892480157f13ba912c04ef9d4b012 commit 7c4a6106d6451fc03c491e61df37c044505d843a upstream. Fix multicast packet transmit logic to account for repetitive transmission of single skb: - correct check for available buffers (this bug may produce NULL pointer crash dump in case of heavy traffic); - update skb user count (incorrect user counter causes a warning dump from net_tx_action routine during multicast transfers in systems with three or more rionet participants). Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: David S. Miller <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 7c4a6106d6451fc03c491e61df37c044505d843a upstream.

Fix multicast packet transmit logic to account for repetitive transmission
of single skb:
- correct check for available buffers (this bug may produce NULL pointer
  crash dump in case of heavy traffic);
- update skb user count (incorrect user counter causes a warning dump from
  net_tx_action routine during multicast transfers in systems with three or
  more rionet participants).

Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
ath9k: Disable ASPM only for AR9285 2012-10-17T02:48:55+00:00 Sujith Manoharan c_manoha@qualcomm.com 2012-09-21T18:44:28+00:00 03b6b180216ccfa64746329e9ce71e8fc9df828b commit 046b6802c8d3c8a57448485513bf7291633e0fa3 upstream. Currently, ASPM is disabled for all WLAN+BT combo chipsets when BTCOEX is enabled. This is incorrect since the workaround is required only for WB195, which is a AR9285+AR3011 combo solution. Fix this by checking for the HW version when enabling the workaround. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Tested-by: Paul Stewart <pstew@chromium.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.2: ath9k_hw_get_btcoex_scheme() function is missing] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 046b6802c8d3c8a57448485513bf7291633e0fa3 upstream.

Currently, ASPM is disabled for all WLAN+BT combo chipsets
when BTCOEX is enabled. This is incorrect since the workaround
is required only for WB195, which is a AR9285+AR3011 combo
solution. Fix this by checking for the HW version when enabling
the workaround.

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Tested-by: Paul Stewart <pstew@chromium.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[bwh: Backported to 3.2: ath9k_hw_get_btcoex_scheme() function is missing]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>