linux/drivers, branch v2.6.27.40

hwmon: (it87) Fix VID reading on IT8718F

2009-12-08T19:17:33Z

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:31Z

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:31Z

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:28Z

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:27Z

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:24Z

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:23Z

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:15Z

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:13Z

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

V4L/DVB (13109): tda18271: fix signedness issue in tda18271_rf_tracking_filters_init

2009-12-08T19:17:11Z

commit a57c1dcb93e43357ed3f666e5a2b5d5071dd3930 upstream. While having tda18271 module set with debug=17 (cal & info prints) and cal=0 (delay calibration process until first use) - I discovered that during the calibration process, if the frequency test for 69750000 returned a bcal of 0 (see tda18721-fe.c in tda18271_powerscan func) that the tuner wouldn't be able to pickup any of the frequencies in the range (all the other frequencies bands returned bcal=1). I spent some time going over the code and the NXP's tda18271 spec (ver.4 of it i think) and adding a lot of debug prints and walking/stepping through the calibration process. I found that when the powerscan fails to find a frequency, the rf calibration is not run and the default value is supposed to be used in its place (pulled from the RF_CAL_map table) - but something was getting goofed up there. Now, my c coding skills are very rusty, but i think root of the problem is a signedness issue with the math operation for calculating the rf_a1 and rf_a2 values in tda18271_rf_tracking_filters_init func, which results in values like 20648 for rf_a1 (when it should probably have a value like 0, or so slightly negative that it should be zero - this bad value for rf_a1 would in turn makes the approx calc within tda18271c2_rf_tracking_filters_correction go out of whack). The simplest solution i found was to explicitly convert the signedness of the denominator to avoid the implicit conversion. The values placed into the u32 rf_freq array should never exceed about 900mhz, so i think the s32 max value shouldn't be an issue in this case. I've tested it out a little, and even when i get a bcal=0 with the modified code, the default calibration value gets used, rf_a1 is zero, and the tuner seems to lock on the stream and mythtv seems to play it fine. Signed-off-by: Seth Barry Signed-off-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman