linux-toradex.git/drivers/net, branch v2.6.27.54 Linux kernel for Apalis and Colibri modules ath9k_hw: fix parsing of HT40 5 GHz CTLs 2010-09-20T20:03:20+00:00 Luis R. Rodriguez lrodriguez@atheros.com 2010-08-30T23:26:33+00:00 d14a2c2005c205bcd6742cac79dacd69436603b6 commit 904879748d7439a6dabdc6be9aad983e216b027d upstream. The 5 GHz CTL indexes were not being read for all hardware devices due to the masking out through the CTL_MODE_M mask being one bit too short. Without this the calibrated regulatory maximum values were not being picked up when devices operate on 5 GHz in HT40 mode. The final output power used for Atheros devices is the minimum between the calibrated CTL values and what CRDA provides. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 904879748d7439a6dabdc6be9aad983e216b027d upstream.

The 5 GHz CTL indexes were not being read for all hardware
devices due to the masking out through the CTL_MODE_M mask
being one bit too short. Without this the calibrated regulatory
maximum values were not being picked up when devices operate
on 5 GHz in HT40 mode. The final output power used for Atheros
devices is the minimum between the calibrated CTL values and
what CRDA provides.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
bonding: select current active slave when enslaving device for mode tlb and alb 2010-08-02T17:18:51+00:00 Jiri Pirko jpirko@redhat.com 2009-03-26T00:23:38+00:00 1671a40d1e83733a1bc71444f9a1277b5c83336b commit 5a29f7893fbe681f1334285be7e41e56f0de666c upstream. I've hit an issue on my system when I've been using RealTek RTL8139D cards in bonding interface in mode balancing-alb. When I enslave a card, the current active slave (bond->curr_active_slave) is not set and the link is therefore not functional. ---- # cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008) Bonding Mode: adaptive load balancing Primary Slave: None Currently Active Slave: None MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: eth1 MII Status: up Link Failure Count: 0 Permanent HW addr: 00:1f:1f:01:2f:22 ---- The thing that gets it right is when I unplug the cable and then I put it back into the NIC. Then the current active slave is set to eth1 and link is working just fine. Here is dmesg log with bonding DEBUG messages turned on: ---- ADDRCONF(NETDEV_UP): bond0: link is not ready event_dev: bond0, event: 1 IFF_MASTER event_dev: bond0, event: 8 IFF_MASTER bond_ioctl: master=bond0, cmd=35216 slave_dev=cac5d800: slave_dev->name=eth1: eth1: ! NETIF_F_VLAN_CHALLENGED event_dev: eth1, event: 8 eth1: link up, 100Mbps, full-duplex, lpa 0xC5E1 event_dev: eth1, event: 1 event_dev: eth1, event: 8 IFF_SLAVE Initial state of slave_dev is BOND_LINK_UP bonding: bond0: enslaving eth1 as an active interface with an up link. ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready event_dev: bond0, event: 4 IFF_MASTER bond0: no IPv6 routers present <<<<cable unplug>>>> eth1: link down event_dev: eth1, event: 4 IFF_SLAVE bonding: bond0: link status definitely down for interface eth1, disabling it event_dev: bond0, event: 4 IFF_MASTER <<<<cable plug>>>> eth1: link up, 100Mbps, full-duplex, lpa 0xC5E1 event_dev: eth1, event: 4 IFF_SLAVE bonding: bond0: link status definitely up for interface eth1. bonding: bond0: making interface eth1 the new active one. event_dev: eth1, event: 8 IFF_SLAVE event_dev: eth1, event: 8 IFF_SLAVE bonding: bond0: first active interface up! event_dev: bond0, event: 4 IFF_MASTER ---- The current active slave is set by calling bond_select_active_slave() function from bond_miimon_commit() function when the slave (eth1) link goes to state up. I also tested this on other machine with Broadcom NetXtreme II BCM5708 1000Base-T NIC and there all works fine. The thing is that this adapter is down and goes up after few seconds after it is enslaved. This patch calls bond_select_active_slave() in bond_enslave() function for modes alb and tlb and makes sure that the current active slave is set up properly even when the slave state is already up. Tested on both systems, works fine. Notice: The same problem can maybe also occrur in mode 8023AD but I'm unable to test that. Signed-off-by: Jiri Pirko <jpirko@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Jean Delvare <jdelvare@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 5a29f7893fbe681f1334285be7e41e56f0de666c upstream.

I've hit an issue on my system when I've been using RealTek RTL8139D cards in
bonding interface in mode balancing-alb. When I enslave a card, the current
active slave (bond->curr_active_slave) is not set and the link is therefore
not functional.

----
# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)

Bonding Mode: adaptive load balancing
Primary Slave: None
Currently Active Slave: None
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth1
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:1f:1f:01:2f:22
----

The thing that gets it right is when I unplug the cable and then I put it back
into the NIC. Then the current active slave is set to eth1 and link is working
just fine. Here is dmesg log with bonding DEBUG messages turned on:
----
ADDRCONF(NETDEV_UP): bond0: link is not ready
event_dev: bond0, event: 1
IFF_MASTER
event_dev: bond0, event: 8
IFF_MASTER
bond_ioctl: master=bond0, cmd=35216
slave_dev=cac5d800:
slave_dev->name=eth1:
eth1: ! NETIF_F_VLAN_CHALLENGED
event_dev: eth1, event: 8
eth1: link up, 100Mbps, full-duplex, lpa 0xC5E1
event_dev: eth1, event: 1
event_dev: eth1, event: 8
IFF_SLAVE
Initial state of slave_dev is BOND_LINK_UP
bonding: bond0: enslaving eth1 as an active interface with an up link.
ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
event_dev: bond0, event: 4
IFF_MASTER
bond0: no IPv6 routers present

<<<<cable unplug>>>>

eth1: link down
event_dev: eth1, event: 4
IFF_SLAVE
bonding: bond0: link status definitely down for interface eth1, disabling it
event_dev: bond0, event: 4
IFF_MASTER

<<<<cable plug>>>>

eth1: link up, 100Mbps, full-duplex, lpa 0xC5E1
event_dev: eth1, event: 4
IFF_SLAVE
bonding: bond0: link status definitely up for interface eth1.
bonding: bond0: making interface eth1 the new active one.
event_dev: eth1, event: 8
IFF_SLAVE
event_dev: eth1, event: 8
IFF_SLAVE
bonding: bond0: first active interface up!
event_dev: bond0, event: 4
IFF_MASTER
----

The current active slave is set by calling bond_select_active_slave() function
from bond_miimon_commit() function when the slave (eth1) link goes to state up.

I also tested this on other machine with Broadcom NetXtreme II BCM5708
1000Base-T NIC and there all works fine. The thing is that this adapter is down
and goes up after few seconds after it is enslaved.

This patch calls bond_select_active_slave() in bond_enslave() function for modes
alb and tlb and makes sure that the current active slave is set up properly even
when the slave state is already up. Tested on both systems, works fine.

Notice: The same problem can maybe also occrur in mode 8023AD but I'm unable to
test that.

Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
hostap: Protect against initialization interrupt 2010-08-02T17:18:50+00:00 Tim Gardner tim.gardner@canonical.com 2010-06-08T17:33:02+00:00 e75c279c6760282546dbc794b8368d6a8ff12c92 commit d6a574ff6bfb842bdb98065da053881ff527be46 upstream. Use an irq spinlock to hold off the IRQ handler until enough early card init is complete such that the handler can run without faulting. Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit d6a574ff6bfb842bdb98065da053881ff527be46 upstream.

Use an irq spinlock to hold off the IRQ handler until
enough early card init is complete such that the handler
can run without faulting.

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
sky2: enable rx/tx in sky2_phy_reinit() 2010-08-02T17:18:50+00:00 Brandon Philips brandon@ifup.org 2010-06-16T16:21:58+00:00 2339fdd79dfe5f17b0b44d89a9475aa8f912be2a commit 38000a94a902e94ca8b5498f7871c6316de8957a upstream. sky2_phy_reinit is called by the ethtool helpers sky2_set_settings, sky2_nway_reset and sky2_set_pauseparam when netif_running. However, at the end of sky2_phy_init GM_GP_CTRL has GM_GPCR_RX_ENA and GM_GPCR_TX_ENA cleared. So, doing these commands causes the device to stop working: $ ethtool -r eth0 $ ethtool -A eth0 autoneg off Fix this issue by enabling Rx/Tx after running sky2_phy_init in sky2_phy_reinit. Signed-off-by: Brandon Philips <bphilips@suse.de> Tested-by: Brandon Philips <bphilips@suse.de> Cc: stable@kernel.org Tested-by: Mike McCormack <mikem@ring3k.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 38000a94a902e94ca8b5498f7871c6316de8957a upstream.

sky2_phy_reinit is called by the ethtool helpers sky2_set_settings,
sky2_nway_reset and sky2_set_pauseparam when netif_running.

However, at the end of sky2_phy_init GM_GP_CTRL has GM_GPCR_RX_ENA and
GM_GPCR_TX_ENA cleared. So, doing these commands causes the device to
stop working:

$ ethtool -r eth0
$ ethtool -A eth0 autoneg off

Fix this issue by enabling Rx/Tx after running sky2_phy_init in
sky2_phy_reinit.

Signed-off-by: Brandon Philips <bphilips@suse.de>
Tested-by: Brandon Philips <bphilips@suse.de>
Cc: stable@kernel.org
Tested-by: Mike McCormack <mikem@ring3k.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
cpmac: do not leak struct net_device on phy_connect errors 2010-08-02T17:18:50+00:00 Florian Fainelli florian@openwrt.org 2010-06-20T22:07:48+00:00 1a9e5fa66baa4dfd6bc366fbe84b172c6da9321b commit ed770f01360b392564650bf1553ce723fa46afec upstream. If the call to phy_connect fails, we will return directly instead of freeing the previously allocated struct net_device. Signed-off-by: Florian Fainelli <florian@openwrt.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit ed770f01360b392564650bf1553ce723fa46afec upstream.

If the call to phy_connect fails, we will return directly instead of freeing
the previously allocated struct net_device.

Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ARCNET: Limit com20020 PCI ID matches for SOHARD cards 2010-07-05T18:08:42+00:00 Andreas Bombe aeb@debian.org 2010-05-18T06:12:46+00:00 88102a584bf833892493a514430bcebd53d8f017 commit e7971c80a8e0299f91272ad8e8ac4167623e1862 upstream. The SH SOHARD ARCNET cards are implemented using generic PLX Technology PCI<->IOBus bridges. Subvendor and subdevice IDs were not specified, causing the driver to attach to any such bridge and likely crash the system by attempting to initialize an unrelated device. Fix by specifying subvendor and subdevice according to the values found in the PCI-ID Repository at http://pci-ids.ucw.cz/ . Signed-off-by: Andreas Bombe <aeb@debian.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit e7971c80a8e0299f91272ad8e8ac4167623e1862 upstream.

The SH SOHARD ARCNET cards are implemented using generic PLX Technology
PCI<->IOBus bridges. Subvendor and subdevice IDs were not specified,
causing the driver to attach to any such bridge and likely crash the
system by attempting to initialize an unrelated device.

Fix by specifying subvendor and subdevice according to the values found
in the PCI-ID Repository at http://pci-ids.ucw.cz/ .

Signed-off-by: Andreas Bombe <aeb@debian.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
b44 WOL setup: one-bit-off stack corruption kernel panic fix 2010-04-01T22:52:27+00:00 Stanislav Brabec sbrabec@suse.cz 2009-12-09T05:00:22+00:00 68cd8670ee25e0d6b0a7472672dcd3843f70a1c6 commit e0188829cb724e7d12a2d4e343b368ff1d6e1471 upstream. About 50% of shutdowns of b44 Ethernet adapter ends by kernel panic with kernels compiled with stack-protector. Checking b44_magic_pattern() return values, one call of b44_magic_pattern() returns 127. It means, that set_bit(128, pmask) was called on line 1509. It means that bit 0 of 17th byte of pmask was overwritten. But pmask has only 16 bytes. Stack corruption happens. It seems that set_bit() on line 1509 always writes one bit off. The fix does not only solve the stack corruption, but also makes Wake On LAN working on my onboard B44 on Asus A7V-333X mainboard. It seems that this problem affects all kernel versions since commit 725ad800 ([PATCH] b44: add wol for old nic) on 2006-06-20. Signed-off-by: Stanislav Brabec <sbrabec@suse.cz> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit e0188829cb724e7d12a2d4e343b368ff1d6e1471 upstream.

About 50% of shutdowns of b44 Ethernet adapter ends by kernel panic
with kernels compiled with stack-protector.

Checking b44_magic_pattern() return values, one call of
b44_magic_pattern() returns 127. It means, that set_bit(128, pmask)
was called on line 1509. It means that bit 0 of 17th byte of pmask was
overwritten. But pmask has only 16 bytes. Stack corruption happens.

It seems that set_bit() on line 1509 always writes one bit off.

The fix does not only solve the stack corruption, but also makes Wake
On LAN working on my onboard B44 on Asus A7V-333X mainboard.

It seems that this problem affects all kernel versions since commit
725ad800 ([PATCH] b44: add wol for old nic) on 2006-06-20.

Signed-off-by: Stanislav Brabec <sbrabec@suse.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
bonding: ignore updelay param when there is no active slave 2010-04-01T22:52:26+00:00 Jiri Pirko jpirko@redhat.com 2009-04-24T03:57:29+00:00 9776e39de376c2dd759f1d8d7f568111139b330e commit 41f8910040639eb106b1a5b5301aab79ecde4940 upstream. Pointed out by Sean E. Millichamp. Quote from Documentation/networking/bonding.txt: "Note that when a bonding interface has no active links, the driver will immediately reuse the first link that goes up, even if the updelay parameter has been specified (the updelay is ignored in this case). If there are slave interfaces waiting for the updelay timeout to expire, the interface that first went into that state will be immediately reused. This reduces down time of the network if the value of updelay has been overestimated, and since this occurs only in cases with no connectivity, there is no additional penalty for ignoring the updelay." This patch actually changes the behaviour in this way. Signed-off-by: Jiri Pirko <jpirko@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Jean Delvare <jdelvare@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 41f8910040639eb106b1a5b5301aab79ecde4940 upstream.

Pointed out by Sean E. Millichamp.

Quote from Documentation/networking/bonding.txt:
"Note that when a bonding interface has no active links, the
driver will immediately reuse the first link that goes up, even if the
updelay parameter has been specified (the updelay is ignored in this
case).  If there are slave interfaces waiting for the updelay timeout
to expire, the interface that first went into that state will be
immediately reused.  This reduces down time of the network if the
value of updelay has been overestimated, and since this occurs only in
cases with no connectivity, there is no additional penalty for
ignoring the updelay."

This patch actually changes the behaviour in this way.

Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
sky2: Set SKY2_HW_RAM_BUFFER in sky2_init 2010-04-01T22:52:20+00:00 Mike McCormack mikem@ring3k.org 2009-09-21T04:08:52+00:00 698051b7655e0289f7a49b4a7e363cb6cec10735 commit 74a61ebf653c6abe459f228eb40e9f24f7ef1fb7 upstream. The SKY2_HW_RAM_BUFFER bit in hw->flags was checked in sky2_mac_init(), before being set later in sky2_up(). Setting SKY2_HW_RAM_BUFFER in sky2_init() where other hw->flags are set should avoid this problem recurring. Signed-off-by: Mike McCormack <mikem@ring3k.org> Acked-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 74a61ebf653c6abe459f228eb40e9f24f7ef1fb7 upstream.

The SKY2_HW_RAM_BUFFER bit in hw->flags was checked in sky2_mac_init(),
 before being set later in sky2_up().

Setting SKY2_HW_RAM_BUFFER in sky2_init() where other hw->flags are set
 should avoid this problem recurring.

Signed-off-by: Mike McCormack <mikem@ring3k.org>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
r8169: Fix receive buffer length when MTU is between 1515 and 1536 2010-04-01T22:52:18+00:00 Raimonds Cicans ray@apollo.lv 2009-11-13T10:52:19+00:00 e2db86fdddfbf179ebc8e717b50770cf7acf78b6 commit 8812304cf1110ae16b0778680f6022216cf4716a upstream. In r8169 driver MTU is used to calculate receive buffer size. Receive buffer size is used to configure hardware incoming packet filter. For jumbo frames: Receive buffer size = Max frame size = MTU + 14 (ethernet header) + 4 (vlan header) + 4 (ethernet checksum) = MTU + 22 Bug: driver for all MTU up to 1536 use receive buffer size 1536 As you can see from formula, this mean all IP packets > 1536 - 22 (for vlan tagged, 1536 - 18 for not tagged) are dropped by hardware filter. Example: host_good> ifconfig eth0 mtu 1536 host_r8169> ifconfig eth0 mtu 1536 host_good> ping host_r8169 Ok host_good> ping -s 1500 host_r8169 Fail host_good> ifconfig eth0 mtu 7000 host_r8169> ifconfig eth0 mtu 7000 host_good> ping -s 1500 host_r8169 Ok Bonus: got rid of magic number 8 Signed-off-by: Raimonds Cicans <ray@apollo.lv> Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 8812304cf1110ae16b0778680f6022216cf4716a upstream.

In r8169 driver MTU is used to calculate receive buffer size.
Receive buffer size is used to configure hardware incoming packet filter.

For jumbo frames:
Receive buffer size = Max frame size = MTU + 14 (ethernet header) + 4
(vlan header) + 4 (ethernet checksum) = MTU + 22

Bug:
driver for all MTU up to 1536 use receive buffer size 1536

As you can see from formula, this mean all IP packets > 1536 - 22
(for vlan tagged, 1536 - 18 for not tagged) are dropped by hardware
filter.

Example:

host_good>  ifconfig eth0 mtu 1536
host_r8169> ifconfig eth0 mtu 1536
host_good>  ping host_r8169
Ok
host_good>  ping -s 1500 host_r8169
Fail
host_good>  ifconfig eth0 mtu 7000
host_r8169> ifconfig eth0 mtu 7000
host_good>  ping -s 1500 host_r8169
Ok

Bonus: got rid of magic number 8

Signed-off-by: Raimonds Cicans <ray@apollo.lv>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>