linux/drivers/base, branch v3.2.2

firmware: Fix an oops on reading fw_priv->fw in sysfs loading file

2012-01-12T19:29:17Z

commit eea915bb0d1358755f151eaefb8208a2d5f3e10c upstream. This oops was reported recently: firmware_loading_store+0xf9/0x17b dev_attr_store+0x20/0x22 sysfs_write_file+0x101/0x134 vfs_write+0xac/0xf3 sys_write+0x4a/0x6e system_call_fastpath+0x16/0x1b The complete backtrace was unfortunately not captured, but details can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=769920 The cause is fairly clear. Its caused by the fact that firmware_loading_store has a case 0 in its switch statement that reads and writes the fw_priv->fw poniter without the protection of the fw_lock mutex. since there is a window between the time that _request_firmware sets fw_priv->fw to NULL and the time the corresponding sysfs file is unregistered, its possible for a user space application to race in, and write a zero to the loading file, causing a NULL dereference in firmware_loading_store. Fix it by extending the protection of the fw_lock mutex to cover all of the firware_loading_store function. Signed-off-by: Neil Horman Signed-off-by: Greg Kroah-Hartman

PM / Driver core: leave runtime PM enabled during system shutdown

2011-12-07T21:26:56Z

Disabling all runtime PM during system shutdown turns out not to be a good idea, because some devices may need to be woken up from a low-power state at that time. The whole point of disabling runtime PM for system shutdown was to prevent untimely runtime-suspend method calls. This patch (as1504) accomplishes the same result by incrementing the usage count for each device and waiting for ongoing runtime-PM callbacks to finish. This is what we already do during system suspend and hibernation, which makes sense since the shutdown method is pretty much a legacy analog of the pm->poweroff method. This fixes a recent regression on some OMAP systems introduced by commit af8db1508f2c9f3b6e633e2d2d906c6557c617f9 (PM / driver core: disable device's runtime PM during shutdown). Reported-and-tested-by: NeilBrown Signed-off-by: Alan Stern Acked-by: Greg Kroah-Hartman Signed-off-by: Rafael J. Wysocki

Merge branch 'driver-core-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2011-11-22T04:36:26Z

* 'driver-core-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: drivers/base/node.c: fix compilation error with older versions of gcc uio: documentation fixups device.h: Fix struct member documentation

drivers/base/node.c: fix compilation error with older versions of gcc

2011-11-18T18:39:24Z

Patch to fix the error message "directives may not be used inside a macro argument" which appears when the kernel is compiled for the cris architecture. Signed-off-by: Claudio Scordino Acked-by: David Rientjes Cc: stable Signed-off-by: Greg Kroah-Hartman

PM Sleep: Do not extend wakeup paths to devices with ignore_children set

2011-11-17T20:39:33Z

Commit 4ca46ff3e0d8c234cb40ebb6457653b59584426c (PM / Sleep: Mark devices involved in wakeup signaling during suspend) introduced the power.wakeup_path field in struct dev_pm_info to mark devices whose children are enabled to wake up the system from sleep states, so that power domains containing the parents that provide their children with wakeup power and/or relay their wakeup signals are not turned off. Unfortunately, that introduced a PM regression on SH7372 whose power consumption in the system "memory sleep" state increased as a result of it, because it prevented the power domain containing the I2C controller from being turned off when some children of that controller were enabled to wake up the system, although the controller was not necessary for them to signal wakeup. To fix this issue use the observation that devices whose power.ignore_children flag is set for runtime PM should be treated analogously during system suspend. Namely, they shouldn't be included in wakeup paths going through their children. Since the SH7372 I2C controller's power.ignore_children flag is set, doing so will restore the previous behavior of that SOC. Signed-off-by: Rafael J. Wysocki Acked-by: Greg Kroah-Hartman

PM / driver core: disable device's runtime PM during shutdown

2011-11-15T20:52:29Z

There may be an issue when the user issue "reboot/shutdown" command, then the device has shut down its hardware, after that, this runtime-pm featured device's driver will probably be scheduled to do its suspend routine, and at its suspend routine, it may access hardware, but the device has already shutdown physically, then the system hang may be occurred. I ran out this issue using an auto-suspend supported USB devices, like 3G modem, keyboard. The usb runtime suspend routine may be scheduled after the usb controller has been shut down, and the usb runtime suspend routine will try to suspend its roothub(controller), it will access register, then the system hang occurs as the controller is shutdown. Signed-off-by: Peter Chen Acked-by: Ming Lei Acked-by: Greg Kroah-Hartman Cc: stable@kernel.org Signed-off-by: Rafael J. Wysocki

PM / QoS: Properly use the WARN() macro in dev_pm_qos_add_request()

2011-11-09T23:44:18Z

Make dev_pm_qos_add_request() use WARN() in a better way and do not hardcode the function's name into the message (use __func__ instead). Signed-off-by: Guennadi Liakhovetski Signed-off-by: Rafael J. Wysocki

PM / Clocks: Only disable enabled clocks in pm_clk_suspend()

2011-11-09T23:44:10Z

Refrain from running clk_disable() on clocks that have not been enabled. A typical case when this can happen is during Suspend-to-RAM for devices that have no driver associated with them. In such case the clock may be in default ACQUIRED state. Without this patch the sh7372 Mackerel board crashes in __clk_disable() during Suspend-to-RAM with: "Trying to disable clock 0xdeadbeef with 0 usecount" This happens for the CEU device which is added during boot. The test case has no CEU driver included in the kernel configuration. Needed for v3.2-rc1. Signed-off-by: Magnus Damm Signed-off-by: Rafael J. Wysocki

PM / OPP: Use ERR_CAST instead of ERR_PTR(PTR_ERR())

2011-11-08T21:34:00Z

Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)) [The semantic patch that makes this change is available in scripts/coccinelle/api/err_cast.cocci. More information about semantic patching is available at http://coccinelle.lip6.fr/] Signed-off-by: Thomas Meyer Signed-off-by: Rafael J. Wysocki

Merge branch 'modsplit-Oct31_2011' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux

2011-11-07T03:44:47Z

* 'modsplit-Oct31_2011' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux: (230 commits) Revert "tracing: Include module.h in define_trace.h" irq: don't put module.h into irq.h for tracking irqgen modules. bluetooth: macroize two small inlines to avoid module.h ip_vs.h: fix implicit use of module_get/module_put from module.h nf_conntrack.h: fix up fallout from implicit moduleparam.h presence include: replace linux/module.h with "struct module" wherever possible include: convert various register fcns to macros to avoid include chaining crypto.h: remove unused crypto_tfm_alg_modname() inline uwb.h: fix implicit use of asm/page.h for PAGE_SIZE pm_runtime.h: explicitly requires notifier.h linux/dmaengine.h: fix implicit use of bitmap.h and asm/page.h miscdevice.h: fix up implicit use of lists and types stop_machine.h: fix implicit use of smp.h for smp_processor_id of: fix implicit use of errno.h in include/linux/of.h of_platform.h: delete needless include acpi: remove module.h include from platform/aclinux.h miscdevice.h: delete unnecessary inclusion of module.h device_cgroup.h: delete needless include net: sch_generic remove redundant use of net: inet_timewait_sock doesnt need ... Fix up trivial conflicts (other header files, and removal of the ab3550 mfd driver) in - drivers/media/dvb/frontends/dibx000_common.c - drivers/media/video/{mt9m111.c,ov6650.c} - drivers/mfd/ab3550-core.c - include/linux/dmaengine.h