linux-toradex.git, branch v3.10.12

Linux 3.10.12

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

ARM: at91: dt: sam9260: add i2c gpio pinctrl

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

commit f89ae61bd74ae195c464bdd97a134e30908884d5 upstream.

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD 
Signed-off-by: Nicolas Ferre 
Cc: Boris BREZILLON 
Signed-off-by: Greg Kroah-Hartman

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

crypto: xor - Check for osxsave as well as avx in crypto/xor

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

commit edb6f29464afc65fc73767540b854abf63ae7144 upstream.

This affects xen pv guests with sufficiently old versions of xen and
sufficiently new hardware.  On such a system, a guest with a btrfs
root won't even boot.

Signed-off-by: John Haxby 
Signed-off-by: Herbert Xu 
Reported-by: Michael Marineau 
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

net: ipv6: tcp: fix potential use after free in tcp_v6_do_rcv

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

[ Upstream commit 3a1c756590633c0e86df606e5c618c190926a0df ]

In tcp_v6_do_rcv() code, when processing pkt options, we soley work
on our skb clone opt_skb that we've created earlier before entering
tcp_rcv_established() on our way. However, only in condition ...

  if (np->rxopt.bits.rxtclass)
    np->rcv_tclass = ipv6_get_dsfield(ipv6_hdr(skb));

... we work on skb itself. As we extract every other information out
of opt_skb in ipv6_pktoptions path, this seems wrong, since skb can
already be released by tcp_rcv_established() earlier on. When we try
to access it in ipv6_hdr(), we will dereference freed skb.

[ Bug added by commit 4c507d2897bd9b ("net: implement IP_RECVTOS for
  IP_PKTOPTIONS") ]

Signed-off-by: Daniel Borkmann 
Cc: Eric Dumazet 
Acked-by: Eric Dumazet 
Acked-by: Jiri Benc 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: fix null pointer dereference in __ip6addrlbl_add

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

[ Upstream commit 639739b5e609a5074839bb22fc061b37baa06269 ]

Commit b67bfe0d42cac56c512dd5da4b1b347a23f4b70a ("hlist: drop
the node parameter from iterators") changed the behavior of
hlist_for_each_entry_safe to leave the p argument NULL.

Fix this up by tracking the last argument.

Reported-by: Michele Baldessari 
Cc: Hideaki YOSHIFUJI 
Cc: Sasha Levin 
Signed-off-by: Hannes Frederic Sowa 
Tested-by: Michele Baldessari 
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