linux-toradex.git/drivers, branch v2.6.27.41

Revert "V4L/DVB (13190): em28xx: fix panic that can occur when starting audio streaming"

2009-12-08T23:02:43+00:00

This reverts commit 72c62be1f9f89d3f60408ab55728237f37911e08.

It breaks the build, and isn't necessary for the 2.6.27 tree.

Signed-off-by: Greg Kroah-Hartman

hwmon: (it87) Fix VID reading on IT8718F

2009-12-08T19:17:33+00:00

commit 371dc4a6d8c3c74a9a1c74b87c2affb3fcef6500 upstream

Comparing apples to bananas doesn't seem right.

The bug has been there since support for the IT8718F was added, so
VID never worked for this chip.

Signed-off-by: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman

dca: redesign locks to fix deadlocks

2009-12-08T19:17:31+00:00

commit eb4400e3a040b90a3ad805b01fcbc99a5f615c8f upstream.

Change spin_locks to irqsave to prevent dead-locks.
Protect adding and deleting to/from dca_providers list.
Drop the lock during dca_sysfs_add_req() and dca_sysfs_remove_req() calls
as they might sleep (use GFP_KERNEL allocation).

Signed-off-by: Maciej Sosnowski 
Acked-by: Jeff Kirsher 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

USB: usb-serial: replace shutdown with disconnect, release

2009-12-08T19:17:31+00:00

This is commit f9c99bb8b3a1ec81af68d484a551307326c2e933 back-ported to
2.6.27.39.

This patch (as1254-2) splits up the shutdown method of usb_serial_driver
into a disconnect and a release method.

The problem is that the usb-serial core was calling shutdown during
disconnect handling, but drivers didn't expect it to be called until
after all the open file references had been closed.  The result was an
oops when the close method tried to use memory that had been
deallocated by shutdown.

Signed-off-by: Alan Stern 
Tested-by: Rory Filer 
Signed-off-by: Greg Kroah-Hartman

USB: suspend/resume support for option driver

2009-12-08T19:17:28+00:00

commit 4901b2c34ecb6fc45909228ad269c8126efe4401 upstream.

This patch implements suspend and resume methods for the
option driver. With my hardware I can even suspend the system
and keep up a connection for a short time.

Signed-off-by: Oliver Neukum 
Signed-Off-By: Matthias Urlichs 
Signed-off-by: Greg Kroah-Hartman

USB: ohci: quirk AMD prefetch for USB 1.1 ISO transfer

2009-12-08T19:17:27+00:00

commit a1f17a872bc7b1cb7efdd5486a2963e88a536e61 upstream.

The following patch in the driver is required to avoid USB 1.1 device
failures that may occur due to requests from USB OHCI controllers may
be overwritten if the latency for any pending request by the USB
controller is very long (in the range of milliseconds).

Signed-off-by: Libin Yang 
Cc: David Brownell 
Cc: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

thinkpad-acpi: fix sign of ERESTARTSYS return

2009-12-08T19:17:24+00:00

commit 80a8d1228e90349b4514e8c925c061fa5cbcea75 upstream.

The returned error should be negative

Signed-off-by: Roel Kluin 
Acked-by: Henrique de Moraes Holschuh 
Signed-off-by: Andrew Morton 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

isdn: hfc_usb: Fix read buffer overflow

2009-12-08T19:17:23+00:00

commit 286e633ef0ff5bb63c07b4516665da8004966fec upstream.

Check whether index is within bounds before testing the element.

Signed-off-by: Roel Kluin 
Cc: Karsten Keil 
Signed-off-by: Andrew Morton 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

V4L/DVB (13230): s2255drv: Don't conditionalize video buffer completion on waiting processes

2009-12-08T19:17:15+00:00

commit 1f95725755ab67f3198df3b5bf7517f926f310ca upstream.

The s2255 driver had logic which aborted processing of a video frame
if there was no process waiting on the video buffer in question.  That
simply doesn't work when the application is doing things in an
asynchronous manner.  If the application went to the trouble to queue
the buffer in the first place, then the driver should always attempt
to complete it - even if the application at that moment has its
attention turned elsewhere.  Applications which always blocked waiting
for I/O on the capture device would not have been affected by this.
Applications which *mostly* blocked waiting for I/O on the capture
device probably only would have been somewhat affected (frame lossage,
at a rate which goes up as the application blocks less).  Applications
which never blocked on the capture device (e.g. polling only) however
would never have been able to receive any video frames, since in that
case this "is anyone waiting on this?" check on the buffer never would
have evalutated true.  This patch just deletes that harmful check
against the buffer's wait queue.

Signed-off-by: Mike Isely 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Michael Krufky 
Signed-off-by: Greg Kroah-Hartman

V4L/DVB (13190): em28xx: fix panic that can occur when starting audio streaming

2009-12-08T19:17:13+00:00

commit 96fbf771d86a90ff006bc62ca4d4de6474b3de31 upstream.

Because the counters were not reset when starting up streaming, they would
be reused from the previous run.  This can result in cases such that when the
second instance of streaming starts up, the "cnt" variable in
em28xx_audio_isocirq() can end up being negative, resulting in attempting to
write to memory before the start of runtime->dma_area (as well as having a
negative number of bytes to copy).

Signed-off-by: Devin Heitmueller 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Michael Krufky 
Signed-off-by: Greg Kroah-Hartman