linux/drivers/net, branch v3.11.3

cw1200: Don't perform SPI transfers in interrupt context

2013-10-01T16:41:02Z

commit aec8e88c947b7017e2b4bbcb68a4bfc4a1f8ad35 upstream. When we get an interrupt from the hardware, the first thing the driver does is tell the device to mask off the interrupt line. Unfortunately this involves a SPI transaction in interrupt context. Some (most?) SPI controllers perform the transfer asynchronously and try to sleep. This is bad, and triggers a BUG(). So, work around this by using adding a hwbus hook for the cw1200 driver core to call. The cw1200_spi driver translates this into irq_disable()/irq_enable() calls instead, which can safely be called in interrupt context. Apparently the platforms I used to develop the cw1200_spi driver used synchronous spi_sync() implementations, which is why this didn't surface until now. Many thanks to Dave Sizeburns for the inital bug report and his services as a tester. Signed-off-by: Solomon Peachy Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

cw1200: Prevent a lock-related hang in the cw1200_spi driver

2013-10-01T16:41:02Z

commit 85ba8f529c57ac6e2fca9be0d9e17920a1afb2e8 upstream. The cw1200_spi driver tries to mirror the cw1200_sdio driver's lock API, which relies on sdio_claim_host/sdio_release_host to serialize hardware operations across multiple threads. Unfortunately the implementation was flawed, as it lacked a way to wake up the lock requestor when there was contention, often resulting in a hang. This problem was uncovered while trying to fix the spi-transfers-in-interrupt-context BUG() corrected in the previous patch. Many thanks to Dave Sizeburns for his assistance in fixing this. Signed-off-by: Solomon Peachy Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

skge: fix broken driver

2013-10-01T16:41:01Z

commit c194992cbe71c20bb3623a566af8d11b0bfaa721 upstream. The patch 136d8f377e1575463b47840bc5f1b22d94bf8f63 broke the skge driver. Note this part of the patch: + if (skge_rx_setup(skge, e, nskb, skge->rx_buf_size) < 0) { + dev_kfree_skb(nskb); + goto resubmit; + } + pci_unmap_single(skge->hw->pdev, dma_unmap_addr(e, mapaddr), dma_unmap_len(e, maplen), PCI_DMA_FROMDEVICE); skb = e->skb; prefetch(skb->data); - skge_rx_setup(skge, e, nskb, skge->rx_buf_size); The function skge_rx_setup modifies e->skb to point to the new skb. Thus, after this change, the new buffer, not the old, is returned to the networking stack. This bug is present in kernels 3.11, 3.11.1 and 3.12-rc1. The patch should be queued for 3.11-stable. Signed-off-by: Mikulas Patocka Reported-by: Mikulas Patocka Reported-by: Vasiliy Glazov Tested-by: Mikulas Patocka Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

tg3: Expand led off fix to include 5720

2013-10-01T16:41:01Z

commit 300cf9b93f74c3d969a0ad50bdac65416107c44c upstream. Commit 989038e217e94161862a959e82f9a1ecf8dda152 ("tg3: Don't turn off led on 5719 serdes port 0") added code to skip turning led off on port 0 of the 5719 since it powered down other ports. This workaround needs to be enabled on the 5720 as well. Signed-off-by: Nithin Nayak Sujir Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

tg3: Don't turn off led on 5719 serdes port 0

2013-10-01T16:41:01Z

commit 989038e217e94161862a959e82f9a1ecf8dda152 upstream. Turning off led on port 0 of the 5719 serdes causes all other ports to lose power and stop functioning. Add tg3_phy_led_bug() function to check for this condition. We use a switch() in tg3_phy_led_bug() for consistency with the tg3_phy_power_bug() function. Signed-off-by: Nithin Nayak Sujir Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

rt2800: fix wrong TX power compensation

2013-10-01T16:40:58Z

commit 6e956da2027c767859128b9bfef085cf2a8e233b upstream. We should not do temperature compensation on devices without EXTERNAL_TX_ALC bit set (called DynamicTxAgcControl on vendor driver). Such devices can have totally bogus TSSI parameters on the EEPROM, but still threaded by us as valid and result doing wrong TX power calculations. This fix inability to connect to AP on slightly longer distance on some Ralink chips/devices. Reported-and-tested-by: Fabien ADAM Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

rt2800: change initialization sequence to fix system freeze

2013-10-01T16:40:58Z

commit f4e1a4d3ecbb9e42bdf8e7869ee8a4ebfa27fb20 upstream. My commit commit c630ccf1a127578421a928489d51e99c05037054 Author: Stanislaw Gruszka Date: Sat Mar 16 19:19:46 2013 +0100 rt2800: rearrange bbp/rfcsr initialization make Maxim machine freeze when try to start wireless device. Initialization order and sending MCU_BOOT_SIGNAL request, changed in above commit, is important. Doing things incorrectly make PCIe bus problems, which can froze the machine. This patch change initialization sequence like vendor driver do: function NICInitializeAsic() from 2011_1007_RT5390_RT5392_Linux_STA_V2.5.0.3_DPO (PCI devices) and DPO_RT5572_LinuxSTA_2.6.1.3_20121022 (according Mediatek, latest driver for RT8070/RT3070/RT3370/RT3572/RT5370/RT5372/RT5572 USB devices). It fixes freezes on Maxim system. Resolve: https://bugzilla.redhat.com/show_bug.cgi?id=1000679 Reported-and-tested-by: Maxim Polyakov Bisected-by: Igor Gnatenko Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

bgmac: fix internal switch initialization

2013-10-01T16:40:58Z

commit 6a391e7bf26c04a6df5f77290e1146941d210d49 upstream. Some devices (BCM4749, BCM5357, BCM53572) have internal switch that requires initialization. We already have code for this, but because of the typo in code it was never working. This resulted in network not working for some routers and possibility of soft-bricking them. Use correct bit for switch initialization and fix typo in the define. Signed-off-by: Rafał Miłecki Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: usb: cdc_ether: Use wwan interface for Telit modules

2013-10-01T16:40:58Z

commit 0092820407901a0b2c4e343e85f96bb7abfcded1 upstream. Signed-off-by: Fabio Porcedda Acked-by: Oliver Neukum Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: mvneta: properly disable HW PHY polling and ensure adjust_link() works

2013-09-27T00:21:45Z

commit 714086029116b6b0a34e67ba1dd2f0d1cf26770c upstream. This commit fixes a long-standing bug that has been reported by many users: on some Armada 370 platforms, only the network interface that has been used in U-Boot to tftp the kernel works properly in Linux. The other network interfaces can see a 'link up', but are unable to transmit data. The reports were generally made on the Armada 370-based Mirabox, but have also been given on the Armada 370-RD board. The network MAC in the Armada 370/XP (supported by the mvneta driver in Linux) has a functionality that allows it to continuously poll the PHY and directly update the MAC configuration accordingly (speed, duplex, etc.). The very first versions of the driver submitted for review were using this hardware mechanism, but due to this, the driver was not integrated with the kernel phylib. Following reviews, the driver was changed to use the phylib, and therefore a software based polling. In software based polling, Linux regularly talks to the PHY over the MDIO bus, and sees if the link status has changed. If it's the case then the adjust_link() callback of the driver is called to update the MAC configuration accordingly. However, it turns out that the adjust_link() callback was not configuring the hardware in a completely correct way: while it was setting the speed and duplex bits correctly, it wasn't telling the hardware to actually take into account those bits rather than what the hardware-based PHY polling mechanism has concluded. So, in fact the adjust_link() callback was basically a no-op. However, the network happened to be working because on the network interfaces used by U-Boot for tftp on Armada 370 platforms because the hardware PHY polling was enabled by the bootloader, and left enabled by Linux. However, the second network interface not used for tftp (or both network interfaces if the kernel is loaded from USB, NAND or SD card) didn't had the hardware PHY polling enabled. This patch fixes this situation by: (1) Making sure that the hardware PHY polling is disabled by clearing the MVNETA_PHY_POLLING_ENABLE bit in the MVNETA_UNIT_CONTROL register in the driver ->probe() function. (2) Making sure that the duplex and speed selections made by the adjust_link() callback are taken into account by clearing the MVNETA_GMAC_AN_SPEED_EN and MVNETA_GMAC_AN_DUPLEX_EN bits in the MVNETA_GMAC_AUTONEG_CONFIG register. This patch has been tested on Armada 370 Mirabox, and now both network interfaces are usable after boot. [ Problem introduced by commit c5aff18 ("net: mvneta: driver for Marvell Armada 370/XP network unit") ] Signed-off-by: Thomas Petazzoni Cc: Willy Tarreau Cc: Jochen De Smet Cc: Peter Sanford Cc: Ethan Tuttle Cc: Chény Yves-Gael Cc: Ryan Press Cc: Simon Guinot Cc: vdonnefort@lacie.com Acked-by: Jason Cooper Tested-by: Vincent Donnefort Tested-by: Yves-Gael Cheny Tested-by: Gregory CLEMENT Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman