linux-toradex.git/drivers, branch v3.10.12

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

2013-09-14T13:54:57+00:00

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

drivers/rtc/rtc-max77686.c: Fix wrong register

2013-09-14T13:54:57+00:00

commit 1748cbf7f7c464593232cde914f5a103181a83b5 upstream.

Fix a read of the wrong register when checking whether the RTC timer has
reached the alarm time.

Signed-off-by: Sangjung Woo 
Signed-off-by: Myugnjoo Ham 
Reviewed-by: Jonghwa Lee 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jonghwan Choi 
Signed-off-by: Greg Kroah-Hartman

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

2013-09-14T13:54:56+00:00

[ 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

vhost_net: poll vhost queue after marking DMA is done

2013-09-14T13:54:56+00:00

[ Upstream commit 19c73b3e08d16ee923f3962df4abf6205127896a ]

We used to poll vhost queue before making DMA is done, this is racy if vhost
thread were waked up before marking DMA is done which can result the signal to
be missed. Fix this by always polling the vhost thread before DMA is done.

Signed-off-by: Jason Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

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

2013-09-14T13:54:56+00:00

[ Upstream commit 989038e217e94161862a959e82f9a1ecf8dda152 ]

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

net: usb: Add HP hs2434 device to ZLP exception table

2013-09-14T13:54:55+00:00

[ Upstream commit 03803a59e32453ee5737c6096a295f748f03cc49 ]

This patch adds another entry (HP hs2434 Mobile Broadband) to the list
of exceptional devices that require a zero length packet in order to
function properly. This list was added in commit 844e88f0. The hs2434
is manufactured by Sierra Wireless, who also produces the MC7710,
which the ZLP exception list was created for in the first place. So
hopefully it is just this one producer's devices that will need this
workaround.

Tested on a DM1-4310NR HP notebook, which does not function without this
change.

Signed-off-by: Rob Gardner 
Acked-by: Bjørn Mork 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

be2net: fix disabling TX in be_close()

2013-09-14T13:54:55+00:00

[ Upstream commit 6e1f99757a2b24b7255263b2240a0eb04215174d ]

commit fba875591 ("disable TX in be_close()") disabled TX in be_close()
to protect be_xmit() from touching freed up queues in the AER recovery
flow.  But, TX must be disabled *before* cleaning up TX completions in
the close() path, not after. This allows be_tx_compl_clean() to free up
all TX-req skbs that were notified to the HW.

Signed-off-by: Sathya Perla 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sfc: Fix lookup of default RX MAC filters when steered using ethtool

2013-09-14T13:54:55+00:00

[ Upstream commit f3851b0acc5a75bd33c6d344a2e4f920e1622ff0 ]

commit 385904f819e3 ('sfc: Don't use
efx_filter_{build,hash,increment}() for default MAC filters') used the
wrong name to find the index of default RX MAC filters at insertion/
update time.  This could result in memory corruption and would in any
case silently fail to update the filter.

Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

tun: signedness bug in tun_get_user()

2013-09-14T13:54:55+00:00

[ Upstream commit 15718ea0d844e4816dbd95d57a8a0e3e264ba90e ]

The recent fix d9bf5f1309 "tun: compare with 0 instead of total_len" is
not totally correct.  Because "len" and "sizeof()" are size_t type, that
means they are never less than zero.

Signed-off-by: Dan Carpenter 
Acked-by: Michael S. Tsirkin 
Acked-by: Neil Horman 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ip_tunnel: Do not use inner ip-header-id for tunnel ip-header-id.

2013-09-14T13:54:55+00:00

[ Upstream commit 4221f40513233fa8edeef7fc82e44163fde03b9b ]

Using inner-id for tunnel id is not safe in some rare cases.
E.g. packets coming from multiple sources entering same tunnel
can have same id. Therefore on tunnel packet receive we
could have packets from two different stream but with same
source and dst IP with same ip-id which could confuse ip packet
reassembly.

Following patch reverts optimization from commit
490ab08127 (IP_GRE: Fix IP-Identification.)

Signed-off-by: Pravin B Shelar 
CC: Jarno Rajahalme 
CC: Ansis Atteka 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman