linux/drivers/net, branch v3.10.14

rt2800: change initialization sequence to fix system freeze

2013-10-01T16:17:47Z

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 Cc: stable@vger.kernel.org # 3.10+ Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

rt2800: fix wrong TX power compensation

2013-10-01T16:17:45Z

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

bgmac: fix internal switch initialization

2013-10-01T16:17:45Z

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:17:45Z

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

ath9k: avoid accessing MRC registers on single-chain devices

2013-09-27T00:18:15Z

commit a1c781bb20ac1e03280e420abd47a99eb8bbdd3b upstream. They are not implemented, and accessing them might trigger errors Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ath9k: fix rx descriptor related race condition

2013-09-27T00:18:15Z

commit e96542e55a2aacf4bdeccfe2f17b77c4895b4df2 upstream. Similar to a race condition that exists in the tx path, the hardware might re-read the 'next' pointer of a descriptor of the last completed frame. This only affects non-EDMA (pre-AR93xx) devices. To deal with this race, defer clearing and re-linking a completed rx descriptor until the next one has been processed. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ath9k: always clear ps filter bit on new assoc

2013-09-27T00:18:15Z

commit 026d5b07c03458f9c0ccd19c3850564a5409c325 upstream. Otherwise in some cases, EAPOL frames might be filtered during the initial handshake, causing delays and assoc failures. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()

2013-09-27T00:18:15Z

commit 67d0cf50bd32b66eab709871714e55725ee30ce4 upstream. The driver fails to check the results of DMA mapping in twp places, which results in the following warning: [ 28.078515] ------------[ cut here ]------------ [ 28.078529] WARNING: at lib/dma-debug.c:937 check_unmap+0x47e/0x930() [ 28.078533] bcma-pci-bridge 0000:0e:00.0: DMA-API: device driver failed to check map error[device address=0x00000000b5d60d6c] [size=1876 bytes] [mapped as single] [ 28.078536] Modules linked in: bnep bluetooth vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) ipv6 b43 brcmsmac rtl8192cu rtl8192c_common rtlwifi mac802 11 brcmutil cfg80211 snd_hda_codec_conexant rng_core snd_hda_intel kvm_amd snd_hda_codec ssb kvm mmc_core snd_pcm snd_seq snd_timer snd_seq_device snd k8temp cordic joydev serio_raw hwmon sr_mod sg pcmcia pcmcia_core soundcore cdrom i2c_nforce2 i2c_core forcedeth bcma snd_page_alloc autofs4 ext4 jbd2 mbcache crc1 6 scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic pata_amd [ 28.078602] CPU: 1 PID: 2570 Comm: NetworkManager Tainted: G O 3.10.0-rc7-wl+ #42 [ 28.078605] Hardware name: Hewlett-Packard HP Pavilion dv2700 Notebook PC/30D6, BIOS F.27 11/27/2008 [ 28.078607] 0000000000000009 ffff8800bbb03ad8 ffffffff8144f898 ffff8800bbb03b18 [ 28.078612] ffffffff8103e1eb 0000000000000002 ffff8800b719f480 ffff8800b7b9c010 [ 28.078617] ffffffff824204c0 ffffffff81754d57 0000000000000754 ffff8800bbb03b78 [ 28.078622] Call Trace: [ 28.078624] [] dump_stack+0x19/0x1b [ 28.078634] [] warn_slowpath_common+0x6b/0xa0 [ 28.078638] [] warn_slowpath_fmt+0x41/0x50 [ 28.078650] [] check_unmap+0x47e/0x930 [ 28.078655] [] debug_dma_unmap_page+0x5c/0x70 [ 28.078679] [] dma64_getnextrxp+0x10c/0x190 [brcmsmac] [ 28.078691] [] dma_rx+0x62/0x240 [brcmsmac] [ 28.078707] [] brcms_c_dpc+0x211/0x9d0 [brcmsmac] [ 28.078717] [] ? brcms_dpc+0x27/0xf0 [brcmsmac] [ 28.078731] [] brcms_dpc+0x47/0xf0 [brcmsmac] [ 28.078736] [] tasklet_action+0x6c/0xf0 --snip-- [ 28.078974] [] SyS_sendmsg+0xd/0x20 [ 28.078979] [] tracesys+0xdd/0xe2 [ 28.078982] ---[ end trace 6164d1a08148e9c8 ]--- [ 28.078984] Mapped at: [ 28.078985] [] debug_dma_map_page+0x9d/0x150 [ 28.078989] [] dma_rxfill+0x102/0x3d0 [brcmsmac] [ 28.079001] [] brcms_c_init+0x87d/0x1100 [brcmsmac] [ 28.079010] [] brcms_init+0x21/0x30 [brcmsmac] [ 28.079018] [] brcms_c_up+0x150/0x430 [brcmsmac] As the patch adds a new failure mechanism to dma_rxfill(). When I changed the comment at the start of the routine to add that information, I also polished the wording. Signed-off-by: Larry Finger Cc: Brett Rudley Cc: Franky (Zhenhui) Lin Cc: Hante Meuleman Cc: brcm80211-dev-list@broadcom.com Acked-by: Arend van Spriel Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

mwifiex: do not create AP and P2P interfaces upon driver loading

2013-09-14T13:54:57Z

commit 1211c961170cedb21c30d5bb7e2033c8720b38db upstream. Bug 60747 - 1286:2044 [Microsoft Surface Pro] Marvell 88W8797 wifi show 3 interface under network https://bugzilla.kernel.org/show_bug.cgi?id=60747 This issue was also reported previously by OLPC and some folks from the community. There are 3 network interfaces with different types being created when mwifiex driver is loaded: 1. mlan0 (infra. STA) 2. uap0 (AP) 3. p2p0 (P2P_CLIENT) The Network Manager attempts to use all 3 interfaces above without filtering the managed interface type. As the result, 3 identical interfaces are displayed under network manager. If user happens to click on an entry under which its interface is uap0 or p2p0, the association will fail. Work around it by removing the creation of AP and P2P interfaces at driver loading time. These interfaces can be added with 'iw' or other applications manually when they are needed. Signed-off-by: Bing Zhao Signed-off-by: Avinash Patil Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

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

2013-09-14T13:54:56Z

[ Upstream commit 714086029116b6b0a34e67ba1dd2f0d1cf26770c ] 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 Cc: stable@vger.kernel.org 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