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

Bluetooth: ath3k: workaround the compatibility issue with xHCI controller

2015-03-06T00:39:20+00:00

commit c561a5753dd631920c4459a067d22679b3d110d6 upstream.

BugLink: https://bugs.launchpad.net/bugs/1400215

ath3k devices fail to load firmwares on xHCI buses, but work well on
EHCI, this might be a compatibility issue between xHCI and ath3k chips.
As my testing result, those chips will work on xHCI buses again with
this patch.

This workaround is from Qualcomm, they also did some workarounds in
Windows driver.

Signed-off-by: Adam Lee 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Ben Hutchings

media/rc: Send sync space information on the lirc device

2015-03-06T00:39:19+00:00

commit a8f29e89f2b54fbf2c52be341f149bc195b63a8b upstream.

Userspace expects to see a long space before the first pulse is sent on
the lirc device.  Currently, if a long time has passed and a new packet
is started, the lirc codec just returns and doesn't send anything.  This
makes lircd ignore many perfectly valid signals unless they are sent in
quick sucession.  When a reset event is delivered, we cannot know
anything about the duration of the space.  But it should be safe to
assume it has been a long time and we just set the duration to maximum.

Signed-off-by: Austin Lund 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Ben Hutchings

staging: comedi: cb_pcidas64: fix incorrect AI range code handling

2015-03-06T00:39:19+00:00

commit be8e89087ec2d2c8a1ad1e3db64bf4efdfc3c298 upstream.

The hardware range code values and list of valid ranges for the AI
subdevice is incorrect for several supported boards.  The hardware range
code values for all boards except PCI-DAS4020/12 is determined by
calling `ai_range_bits_6xxx()` based on the maximum voltage of the range
and whether it is bipolar or unipolar, however it only returns the
correct hardware range code for the PCI-DAS60xx boards.  For
PCI-DAS6402/16 (and /12) it returns the wrong code for the unipolar
ranges.  For PCI-DAS64/Mx/16 it returns the wrong code for all the
ranges and the comedi range table is incorrect.

Change `ai_range_bits_6xxx()` to use a look-up table pointed to by new
member `ai_range_codes` of `struct pcidas64_board` to map the comedi
range table indices to the hardware range codes.  Use a new comedi range
table for the PCI-DAS64/Mx/16 boards (and the commented out variants).

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

Drivers: hv: vmbus: incorrect device name is printed when child device is unregistered

2015-03-06T00:39:19+00:00

commit 84672369ffb98a51d4ddf74c20a23636da3ad615 upstream.

Whenever a device is unregistered in vmbus_device_unregister (drivers/hv/vmbus_drv.c), the device name in the log message may contain garbage as the memory has already been freed by the time pr_info is called. Log example:
 [ 3149.170475] hv_vmbus: child device àõsèè0_5 unregistered

By logging the message just before calling device_unregister, the correct device name is printed:
[ 3145.034652] hv_vmbus: child device vmbus_0_5 unregistered

Also changing register & unregister messages to debug to avoid unnecessarily cluttering the kernel log.

Signed-off-by: Fernando M Soto 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

gpio: sysfs: fix memory leak in gpiod_sysfs_set_active_low

2015-03-06T00:39:18+00:00

commit 49d2ca84e433dab854c7a866bc6add09cfab682d upstream.

Fix memory leak in the gpio sysfs interface due to failure to drop
reference to device returned by class_find_device when setting the
gpio-line polarity.

Fixes: 0769746183ca ("gpiolib: add support for changing value polarity
in sysfs")
Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings

gpio: sysfs: fix memory leak in gpiod_export_link

2015-03-06T00:39:18+00:00

commit 0f303db08df0df9bd0966443ad6001e63960af16 upstream.

Fix memory leak in the gpio sysfs interface due to failure to drop
reference to device returned by class_find_device when creating a link.

Fixes: a4177ee7f1a8 ("gpiolib: allow exported GPIO nodes to be named
using sysfs links")
Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings

PCI: quirks: Fix backport of quirk_io()

2015-03-06T00:39:17+00:00

Commit 06cf35f903aa ('PCI: Handle read-only BARs on AMD CS553x
devices') added the function quirk_io() which calls
pcibios_bus_to_resource().

Prior to Linux 3.14, pcibios_bus_to_resource() takes a pointer to
struct pci_dev and looks up the device's bus itself, so we need
to pass dev not dev->bus.

Signed-off-by: Ben Hutchings

PCI: Handle read-only BARs on AMD CS553x devices

2015-02-20T00:49:42+00:00

commit 06cf35f903aa6da0cc8d9f81e9bcd1f7e1b534bb upstream.

Some AMD CS553x devices have read-only BARs because of a firmware or
hardware defect.  There's a workaround in quirk_cs5536_vsa(), but it no
longer works after 36e8164882ca ("PCI: Restore detection of read-only
BARs").  Prior to 36e8164882ca, we filled in res->start; afterwards we
leave it zeroed out.  The quirk only updated the size, so the driver tried
to use a region starting at zero, which didn't work.

Expand quirk_cs5536_vsa() to read the base addresses from the BARs and
hard-code the sizes.

On Nix's system BAR 2's read-only value is 0x6200.  Prior to 36e8164882ca,
we interpret that as a 512-byte BAR based on the lowest-order bit set.  Per
datasheet sec 5.6.1, that BAR (MFGPT) requires only 64 bytes; use that to
avoid clearing any address bits if a platform uses only 64-byte alignment.

[bhelgaas: changelog, reduce BAR 2 size to 64]
Fixes: 36e8164882ca ("PCI: Restore detection of read-only BARs")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85991#c4
Link: http://support.amd.com/TechDocs/31506_cs5535_databook.pdf
Link: http://support.amd.com/TechDocs/33238G_cs5536_db.pdf
Reported-and-tested-by: Nix 
Signed-off-by: Myron Stowe 
Signed-off-by: Bjorn Helgaas 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

enic: fix rx skb checksum

2015-02-20T00:49:41+00:00

[ Upstream commit 17e96834fd35997ca7cdfbf15413bcd5a36ad448 ]

Hardware always provides compliment of IP pseudo checksum. Stack expects
whole packet checksum without pseudo checksum if CHECKSUM_COMPLETE is set.

This causes checksum error in nf & ovs.

kernel: qg-19546f09-f2: hw csum failure
kernel: CPU: 9 PID: 0 Comm: swapper/9 Tainted: GF          O--------------   3.10.0-123.8.1.el7.x86_64 #1
kernel: Hardware name: Cisco Systems Inc UCSB-B200-M3/UCSB-B200-M3, BIOS B200M3.2.2.3.0.080820141339 08/08/2014
kernel: ffff881218f40000 df68243feb35e3a8 ffff881237a43ab8 ffffffff815e237b
kernel: ffff881237a43ad0 ffffffff814cd4ca ffff8829ec71eb00 ffff881237a43af0
kernel: ffffffff814c6232 0000000000000286 ffff8829ec71eb00 ffff881237a43b00
kernel: Call Trace:
kernel:   [] dump_stack+0x19/0x1b
kernel: [] netdev_rx_csum_fault+0x3a/0x40
kernel: [] __skb_checksum_complete_head+0x62/0x70
kernel: [] __skb_checksum_complete+0x11/0x20
kernel: [] nf_ip_checksum+0xcc/0x100
kernel: [] icmp_error+0x1f7/0x35c [nf_conntrack_ipv4]
kernel: [] ? netif_rx+0xb9/0x1d0
kernel: [] ? internal_dev_recv+0xdb/0x130 [openvswitch]
kernel: [] nf_conntrack_in+0xf0/0xa80 [nf_conntrack]
kernel: [] ? inet_del_offload+0x40/0x40
kernel: [] ipv4_conntrack_in+0x22/0x30 [nf_conntrack_ipv4]
kernel: [] nf_iterate+0xaa/0xc0
kernel: [] ? inet_del_offload+0x40/0x40
kernel: [] nf_hook_slow+0x84/0x140
kernel: [] ? inet_del_offload+0x40/0x40
kernel: [] ip_rcv+0x344/0x380

Hardware verifies IP & tcp/udp header checksum but does not provide payload
checksum, use CHECKSUM_UNNECESSARY. Set it only if its valid IP tcp/udp packet.

Cc: Jiri Benc 
Cc: Stefan Assmann 
Reported-by: Sunil Choudhary 
Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
Reviewed-by: Jiri Benc 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

tg3: tg3_disable_ints using uninitialized mailbox value to disable interrupts

2015-02-20T00:49:41+00:00

[ Upstream commit 05b0aa579397b734f127af58e401a30784a1e315 ]

During driver load in tg3_init_one, if the driver detects DMA activity before
intializing the chip tg3_halt is called. As part of tg3_halt interrupts are
disabled using routine tg3_disable_ints. This routine was using mailbox value
which was not initialized (default value is 0). As a result driver was writing
0x00000001 to pci config space register 0, which is the vendor id / device id.

This driver bug was exposed because of the commit a7877b17a667 (PCI: Check only
the Vendor ID to identify Configuration Request Retry). Also this issue is only
seen in older generation chipsets like 5722 because config space write to offset
0 from driver is possible. The newer generation chips ignore writes to offset 0.
Also without commit a7877b17a667, for these older chips when a GRC reset is
issued the Bootcode would reprogram the vendor id/device id, which is the reason
this bug was masked earlier.

Fixed by initializing the interrupt mailbox registers before calling tg3_halt.

Please queue for -stable.

Reported-by: Nils Holland 
Reported-by: Marcelo Ricardo Leitner 
Signed-off-by: Prashant Sreedharan 
Signed-off-by: Michael Chan 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings