linux/drivers, branch v3.2.22

acpi_pad: fix power_saving thread deadlock

2012-07-04T04:44:32Z

commit 5f1601261050251a5ca293378b492a69d590dacb upstream. The acpi_pad driver can get stuck in destroy_power_saving_task() waiting for kthread_stop() to stop a power_saving thread. The problem is that the isolated_cpus_lock mutex is owned when destroy_power_saving_task() calls kthread_stop(), which waits for a power_saving thread to end, and the power_saving thread tries to acquire the isolated_cpus_lock when it calls round_robin_cpu(). This patch fixes the issue by making round_robin_cpu() use its own mutex. https://bugzilla.kernel.org/show_bug.cgi?id=42981 Signed-off-by: Stuart Hayes Signed-off-by: Len Brown Signed-off-by: Ben Hutchings

can: flexcan: use be32_to_cpup to handle the value of dt entry

2012-07-04T04:44:32Z

commit 85f2f834e85517307f13e30e630a5fc86f757cb5 upstream. The freescale arm i.MX series platform can support this driver, and usually the arm cpu works in the little endian mode by default, while device tree entry value is stored in big endian format, we should use be32_to_cpup() to handle them, after modification, it can work well both on the le cpu and be cpu. Cc: Shawn Guo Signed-off-by: Hui Wang Signed-off-by: Marc Kleine-Budde Signed-off-by: Ben Hutchings

xen/netfront: teardown the device before unregistering it.

2012-07-04T04:44:31Z

commit 6bc96d047fe32d76ef79f3195c52a542edf7c705 upstream. Fixes: [ 15.470311] WARNING: at /local/scratch/ianc/devel/kernels/linux/fs/sysfs/file.c:498 sysfs_attr_ns+0x95/0xa0() [ 15.470326] sysfs: kobject eth0 without dirent [ 15.470333] Modules linked in: [ 15.470342] Pid: 12, comm: xenwatch Not tainted 3.4.0-x86_32p-xenU #93 and [ 9.150554] BUG: unable to handle kernel paging request at 2b359000 [ 9.150577] IP: [] linkwatch_do_dev+0x81/0xc0 [ 9.150592] *pdpt = 000000002c3c9027 *pde = 0000000000000000 [ 9.150604] Oops: 0002 [#1] SMP [ 9.150613] Modules linked in: This is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675190 Reported-by: George Shuklin Signed-off-by: Ian Campbell Tested-by: William Dauchy Cc: 675190@bugs.debian.org Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings

USB: CP210x Add 10 Device IDs

2012-07-04T04:44:31Z

commit 3fcc8f96829776cf181918461923d1e3bbb831a2 upstream. This patch adds 10 device IDs for CP210x based devices from the following manufacturers: Timewave Clipsal Festo Link Instruments Signed-off-by: Craig Shelley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings

USB: option: Add USB ID for Novatel Ovation MC551

2012-07-04T04:44:30Z

commit 065b07e7a14676f4138ce4619d229c0be5a74230 upstream. This device is also known as the Verizon USB551L. Signed-off-by: Forest Bond Acked-by: Dan Williams Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings

x86, cpufeature: Rename X86_FEATURE_DTS to X86_FEATURE_DTHERM

2012-07-04T04:44:28Z

commit 4ad33411308596f2f918603509729922a1ec4411 upstream. It makes sense to label "Digital Thermal Sensor" as "DTS", but unfortunately the string "dts" was already used for "Debug Store", and /proc/cpuinfo is a user space ABI. Therefore, rename this to "dtherm". This conflict went into mainline via the hwmon tree without any x86 maintainer ack, and without any kind of hint in the subject. a4659053 x86/hwmon: fix initialization of coretemp Reported-by: Jean Delvare Link: http://lkml.kernel.org/r/4FE34BCB.5050305@linux.intel.com Cc: Jan Beulich Signed-off-by: H. Peter Anvin [bwh: Backported to 3.2: drop the coretemp device table change] Signed-off-by: Ben Hutchings

PM / Sleep: Prevent waiting forever on asynchronous suspend after abort

2012-07-04T04:44:27Z

commit 1f758b23177d588a71b96ad02990e715949bb82f upstream. __device_suspend() must always send a completion. Otherwise, parent devices will wait forever. Commit 1e2ef05b, "PM: Limit race conditions between runtime PM and system sleep (v2)", introduced a regression by short-circuiting the complete_all() for certain error cases. This patch fixes the bug by always signalling a completion. Addresses http://crosbug.com/31972 Tested by injecting an abort. Signed-off-by: Mandeep Singh Baines Signed-off-by: Rafael J. Wysocki Signed-off-by: Ben Hutchings

drm/i915: Fix eDP blank screen after S3 resume on HP desktops

2012-07-04T04:44:27Z

commit 6db65cbb941f9d433659bdad02b307f6d94465df upstream. This patch fixes the problem on some HP desktop machines with eDP which give blank screens after S3 resume. It turned out that BLC_PWM_CPU_CTL must be written after BLC_PWM_CPU_CTL2. Otherwise it doesn't take effect on these SNB machines. Tested with 3.5-rc3 kernel. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49233 Signed-off-by: Takashi Iwai Signed-off-by: Daniel Vetter Signed-off-by: Ben Hutchings

drm/i915: rip out the PM_IIR WARN

2012-07-04T04:44:26Z

commit 58bf8062d0b293b8e1028e5b0342082002886bd4 upstream. After banging my head against this for the past few months, I still don't see how this could possible race under the premise that once an irq bit is masked in PM_IMR and reset in PM_IIR it won't show up again until we unmask it in PM_IMR. Still, we have reports of this being seen in the wild. Now Bspec has this little bit of lovely language in the PMIIR register: Public SNB Docs, Vol3Part2, 2.5.14 "PMIIR": "For each bit, the IIR can store a second pending interrupt if two or more of the same interrupt conditions occur before the first condition is cleared. Upon clearing the interrupt, the IIR bit will momentarily go low, then return high to indicate there is another interrupt pending." Now if we presume that PMIMR only prevent new interrupts from being queued, we could easily end up masking an interrupt and clearing it, but the 2nd pending interrupt setting the bit in PMIIR right away again. Which leads, the next time the irq handler runs, to hitting the WARN. Also, no bad side effects of this have ever been reported. And we've tracked down our issues with the gpu turbo getting stuck to bogus interrupt generation limits in th RPLIMIT register. So let's just rip out this WARN as bogus and call it a day. The only shallow thing here is that this 2-deep irq queue in the hw makes you wonder how racy the windows irq handler is ... Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42907 Acked-by: Chris Wilson Signed-Off-by: Daniel Vetter Signed-off-by: Ben Hutchings

drm/i915: Refactor the deferred PM_IIR handling into a single function

2012-07-04T04:44:26Z

commit fc6826d1dcd65f3d1e9a5377678882e4e08f02be upstream. This function, along with the registers and deferred work hander, are all shared with SandyBridge, IvyBridge and their variants. So remove the duplicate code into a single function. Signed-off-by: Chris Wilson Reviewed-by: Ben Widawsky Signed-Off-by: Daniel Vetter [bwh: Backported to 3.2: adjust context; drop changes for Valley View] Signed-off-by: Ben Hutchings