linux/drivers, branch v2.6.30.6

xenfb: connect to backend before registering fb

2009-09-09T03:34:06Z

commit 0a80fb10239b04c45e5e80aad8d4b2ca5ac407b2 upstream. As soon as the framebuffer is registered, our methods may be called by the kernel. This leads to a crash as xenfb_refresh() gets called before we have the irq. Connect to the backend before registering our framebuffer with the kernel. [ Fixes bug http://bugzilla.kernel.org/show_bug.cgi?id=14059 ] Signed-off-by: Michal Schmidt Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

ar9170: fix read & write outside array bounds

2009-09-09T03:34:05Z

commit e9d126cdfa60b575f1b5b02024c4faee27dccf07 upstream. Backport done by Christian Lamparter queue == __AR9170_NUM_TXQ would cause a bug on the next line. found by Smatch ( http://repo.or.cz/w/smatch.git ). Reported-by: Dan Carpenter Signed-off-by: Dan Carpenter Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

USB: EHCI: fix two new bugs related to Clear-TT-Buffer

2009-09-09T03:34:02Z

commit 7a0f0d951273eee889c2441846842348ebc00a2a upstream. This patch (as1273) fixes two(!) bugs introduced by the new Clear-TT-Buffer implementation in ehci-hcd. It is now possible for an idle QH to have some URBs on its queue -- this will happen if a Clear-TT-Buffer is pending for the QH's endpoint. Consequently we should not issue a warning when someone tries to unlink an URB from an idle QH; instead we should process the request immediately. The refcounts for QHs could get messed up, because submit_async() would increment the refcount when calling qh_link_async() and qh_link_async() would then refuse to link the QH into the schedule if a Clear-TT-Buffer was pending. Instead we should increment the refcount only when the QH actually is added to the schedule. The current code tries to be clever by leaving the refcount alone if an unlink is immediately followed by a relink; the patch changes this to an unconditional decrement and increment (although they occur in the opposite order). Signed-off-by: Alan Stern CC: David Brownell Tested-by: Manuel Lauss Tested-by: Matthijs Kooijman Signed-off-by: Greg Kroah-Hartman

USB: EHCI: use the new clear_tt_buffer interface

2009-09-09T03:34:01Z

commit 914b701280a76f96890ad63eb0fa99bf204b961c upstream. This patch (as1256) changes ehci-hcd and all the other drivers in the EHCI family to make use of the new clear_tt_buffer callbacks. When a Clear-TT-Buffer request is in progress for a QH, the QH is not allowed to be linked into the async schedule until the request is finished. At that time, if there are any URBs queued for the QH, it is linked into the async schedule. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: fix the clear_tt_buffer interface

2009-09-09T03:34:00Z

commit cb88a1b887bb8908f6e00ce29e893ea52b074940 upstream. This patch (as1255) updates the interface for calling usb_hub_clear_tt_buffer(). Even the name of the function is changed! When an async URB (i.e., Control or Bulk) going through a high-speed hub to a non-high-speed device is cancelled or fails, the hub's Transaction Translator buffer may be left busy still trying to complete the transaction. The buffer has to be cleared; that's what usb_hub_clear_tt_buffer() does. It isn't safe to send any more URBs to the same endpoint until the TT buffer is fully clear. Therefore the HCD needs to be told when the Clear-TT-Buffer request has finished. This patch adds a callback method to struct hc_driver for that purpose, and makes the hub driver invoke the callback at the proper time. The patch also changes a couple of names; "hub_tt_kevent" and "tt.kevent" now look rather antiquated. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

gspca - ov534: Fix ov772x

2009-09-09T03:33:58Z

The scan of the image packets of the sensor ov772x was broken when the sensor ov965x was added. [ Based on upstream c874f3aa, modified slightly for v2.6.30.5 ] Signed-off-by: Jim Paris Acked-by: Jean-Francois Moine Signed-off-by: Greg Kroah-Hartman

ACPI processor: force throttling state when BIOS returns incorrect value

2009-09-09T03:33:54Z

commit 2a908002c7b1b666616103e9df2419b38d7c6f1f upstream. If the BIOS reports an invalid throttling state (which seems to be fairly common after system boot), a reset is done to state T0. Because of a check in acpi_processor_get_throttling_ptc(), the reset never actually gets executed, which results in the error reoccurring on every access of for example /proc/acpi/processor/CPU0/throttling. Add a 'force' option to acpi_processor_set_throttling() to ensure the reset really takes effect. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13389 This patch, together with the next one, fixes a regression introduced in 2.6.30, listed on the regression list. They have been available for 2.5 months now in bugzilla, but have not been picked up, despite various reminders and without any reason given. Google shows that numerous people are hitting this issue. The issue is in itself relatively minor, but the bug in the code is clear. The patches have been in all my kernels and today testing has shown that throttling works correctly with the patches applied when the system overheats (http://bugzilla.kernel.org/show_bug.cgi?id=13918#c14). Signed-off-by: Frans Pop Acked-by: Zhang Rui Cc: Len Brown Cc: "Rafael J. Wysocki" Cc: Rusty Russell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

mpt2sas: fix config request and diag reset deadlock

2009-09-09T03:33:48Z

commit 388ce4beb7135722c584b0af18f215e3ec657adf upstream. Moving the setting and clearing of the mutex's to _config_request. There was a mutex deadlock when diag reset is called from inside _config_request, so diag reset was moved to outside the mutexs. Signed-off-by: James Bottomley Signed-off-by: Kashyap Desai Signed-off-by: Eric Moore Signed-off-by: Greg Kroah-Hartman

SCSI: mpt2sas: fix oops because drv data points to NULL on resume from hibernate

2009-09-09T03:33:48Z

commit fcfe6392d18283df3c561b5ef59c330d485ff8ca upstream. Fix another ocurring when the system resumes. This oops was due to driver setting the pci drvdata to NULL on the prior hibernation. Becuase it was set to NULL, upon resmume we assume the pci drvdata is non-zero, and we oops. To fix the ooops, we don't set pci drvdata to NULL at hibernation time. Signed-off-by: Kashyap Desai Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman

SCSI: mpt2sas: fix crash due to Watchdog is active while OS in standby mode

2009-09-09T03:33:44Z

commit e4750c989f732555fca86dd73d488c79972362db upstream. Fix oops ocurring at hibernation time. This oops was due to the firmware fault watchdog timer still running after we freed resources. To fix the issue we need to terminate the watchdog timer at hibernation time. Signed-off-by: Kashyap Desai Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman