linux-stable.git/drivers, branch v3.2.57

net: asix: add missing flag to struct driver_info

2014-04-09T01:20:46+00:00

commit d43ff4cd798911736fb39025ec8004284b1b0bc2 upstream.

The struct driver_info ax88178_info is assigned the function
asix_rx_fixup_common as it's rx_fixup callback. This means that
FLAG_MULTI_PACKET must be set as this function is cloning the
data and calling usbnet_skb_return. Not setting this flag leads
to usbnet_skb_return beeing called a second time from within
the rx_process function in the usbnet module.

Signed-off-by: Emil Goode 
Reported-by: Bjørn Mork 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

net: asix: handle packets crossing URB boundaries

2014-04-09T01:20:45+00:00

commit 8b5b6f5413e97c3e8bafcdd67553d508f4f698cd upstream.

ASIX AX88772B started to pack data even more tightly. Packets and the ASIX packet
header may now cross URB boundaries. To handle this we have to introduce
some state between individual calls to asix_rx_fixup().

Signed-off-by: Lucas Stach 
Signed-off-by: David S. Miller 
[ Emil: backported to 3.2:
 - dropped changes to drivers/net/usb/ax88172a.c 
 - Introduced some static function declarations as the functions
   are not used outside of asix.c (sparse is complaining about it) ]
Signed-off-by: Emil Goode 
Signed-off-by: Ben Hutchings

asix: asix_rx_fixup surgery to reduce skb truesizes

2014-04-09T01:20:45+00:00

commit a9e0aca4b37885b5599e52211f098bd7f565e749 upstream.

asix_rx_fixup() is complex, and does some unnecessary memory copies (at
least on x86 where NET_IP_ALIGN is 0)

Also, it tends to provide skbs with a big truesize (4096+256 with
MTU=1500) to upper stack, so incoming trafic consume a lot of memory and
I noticed early packet drops because we hit socket rcvbuf too fast.

Switch to a different strategy, using copybreak so that we provide nice
skbs to upper stack (including the NET_SKB_PAD to avoid future head
reallocations in some paths)

With this patch, I no longer see packets drops or tcp collapses on
various tcp workload with a AX88772 adapter.

Signed-off-by: Eric Dumazet 
Cc: Aurelien Jacobs 
Cc: Greg Kroah-Hartman 
Cc: Trond Wuellner 
Cc: Grant Grundler 
Cc: Paul Stewart 
Reviewed-by: Grant Grundler 
Reviewed-by: Grant Grundler 
Signed-off-by: David S. Miller 
[ Emil: Backported to 3.2: fixed small conflict ]
Signed-off-by: Emil Goode 
Signed-off-by: Ben Hutchings

staging: speakup: Prefix set_mask_bits() symbol

2014-04-09T01:20:44+00:00

This is part of commit ca2beaf84d96 ('staging: speakup: Prefix
externally-visible symbols') upstream.  It is required as preparation
for commit 00a1a053ebe5 ('ext4: atomically set inode->i_flags in
ext4_set_inode_flags()').

Signed-off-by: Ben Hutchings

Input: synaptics - add manual min/max quirk for ThinkPad X240

2014-04-09T01:20:44+00:00

commit 8a0435d958fb36d93b8df610124a0e91e5675c82 upstream.

This extends Benjamin Tissoires manual min/max quirk table with support for
the ThinkPad X240.

Signed-off-by: Hans de Goede 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Ben Hutchings

Input: synaptics - add manual min/max quirk

2014-04-09T01:20:44+00:00

commit 421e08c41fda1f0c2ff6af81a67b491389b653a5 upstream.

The new Lenovo Haswell series (-40's) contains a new Synaptics touchpad.
However, these new Synaptics devices report bad axis ranges.
Under Windows, it is not a problem because the Windows driver uses RMI4
over SMBus to talk to the device. Under Linux, we are using the PS/2
fallback interface and it occurs the reported ranges are wrong.

Of course, it would be too easy to have only one range for the whole
series, each touchpad seems to be calibrated in a different way.

We can not use SMBus to get the actual range because I suspect the firmware
will switch into the SMBus mode and stop talking through PS/2 (this is the
case for hybrid HID over I2C / PS/2 Synaptics touchpads).

So as a temporary solution (until RMI4 land into upstream), start a new
list of quirks with the min/max manually set.

Signed-off-by: Benjamin Tissoires 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Ben Hutchings

PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabled

2014-04-01T23:59:02+00:00

commit 3cdeb713dc66057b50682048c151eae07b186c42 upstream.

Andreas reported that after 1f42db786b14 ("PCI: Enable INTx if BIOS left
them disabled"), pciehp surprise removal stopped working.

This happens because pci_reenable_device() on the hotplug bridge (used in
the pciehp_configure_device() path) clears the Interrupt Disable bit, which
apparently breaks the bridge's MSI hotplug event reporting.

Previously we cleared the Interrupt Disable bit in do_pci_enable_device(),
which is used by both pci_enable_device() and pci_reenable_device().  But
we use pci_reenable_device() after the driver may have enabled MSI or
MSI-X, and we *set* Interrupt Disable as part of enabling MSI/MSI-X.

This patch clears Interrupt Disable only when MSI/MSI-X has not been
enabled.

Fixes: 1f42db786b14 PCI: Enable INTx if BIOS left them disabled
Link: https://bugzilla.kernel.org/show_bug.cgi?id=71691
Reported-and-tested-by: Andreas Noever 
Signed-off-by: Bjorn Helgaas 
CC: Sarah Sharp 
Signed-off-by: Ben Hutchings

intel_idle: Check cpu_idle_get_driver() for NULL before dereferencing it.

2014-04-01T23:59:02+00:00

commit 3735d524da64b70b41c764359da36f88aded3610 upstream.

If the machine is booted without any cpu_idle driver set
(b/c disable_cpuidle() has been called) we should follow
other users of cpu_idle API and check the return value
for NULL before using it.

Reported-and-tested-by: Mark van Dijk 
Suggested-by: Jan Beulich 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings

tg3: Don't check undefined error bits in RXBD

2014-04-01T23:59:02+00:00

[ Upstream commit d7b95315cc7f441418845a165ee56df723941487 ]

Redefine the RXD_ERR_MASK to include only relevant error bits. This fixes
a customer reported issue of randomly dropping packets on the 5719.

Signed-off-by: Michael Chan 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

virtio-net: alloc big buffers also when guest can receive UFO

2014-04-01T23:59:02+00:00

[ Upstream commit 0e7ede80d929ff0f830c44a543daa1acd590c749 ]

We should alloc big buffers also when guest can receive UFO
packets to let the big packets fit into guest rx buffer.

Fixes 5c5167515d80f78f6bb538492c423adcae31ad65
(virtio-net: Allow UFO feature to be set and advertised.)

Cc: Rusty Russell 
Cc: Michael S. Tsirkin 
Cc: Sridhar Samudrala 
Signed-off-by: Jason Wang 
Acked-by: Michael S. Tsirkin 
Acked-by: Rusty Russell 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings