linux/drivers/base, branch v3.2.38

regmap: debugfs: Avoid overflows for very small reads

2013-01-03T03:33:32Z

commit db04328c167ff8e7c57f4a3532214aeada3a82fd upstream. If count is less than the size of a register then we may hit integer wraparound when trying to move backwards to check if we're still in the buffer. Instead move the position forwards to check if it's still in the buffer, we are unlikely to be able to allocate a buffer sufficiently big to overflow here. Signed-off-by: Mark Brown [bwh: Backported to 3.2: formatted length is tot_len] Signed-off-by: Ben Hutchings

PM / Runtime: Clear power.deferred_resume on success in rpm_suspend()

2012-09-12T02:37:08Z

commit 58a34de7b1a920d287d17d2ca08bc9aaf7e6d35b upstream. The power.deferred_resume can only be set if the runtime PM status of device is RPM_SUSPENDING and it should be cleared after its status has been changed, regardless of whether or not the runtime suspend has been successful. However, it only is cleared on suspend failure, while it may remain set on successful suspend and is happily leaked to rpm_resume() executed in that case. That shouldn't happen, so if power.deferred_resume is set in rpm_suspend() after the status has been changed to RPM_SUSPENDED, clear it before calling rpm_resume(). Then, it doesn't need to be cleared before changing the status to RPM_SUSPENDING any more, because it's always cleared after the status has been changed to either RPM_SUSPENDED (on success) or RPM_ACTIVE (on failure). Signed-off-by: Rafael J. Wysocki Acked-by: Alan Stern Signed-off-by: Ben Hutchings

PM / Runtime: Fix rpm_resume() return value for power.no_callbacks set

2012-09-12T02:37:08Z

commit 7f321c26c04807834fef4c524d2b21573423fc74 upstream. For devices whose power.no_callbacks flag is set, rpm_resume() should return 1 if the device's parent is already active, so that the callers of pm_runtime_get() don't think that they have to wait for the device to resume (asynchronously) in that case (the core won't queue up an asynchronous resume in that case, so there's nothing to wait for anyway). Modify the code accordingly (and make sure that an idle notification will be queued up on success, even if 1 is to be returned). Signed-off-by: Rafael J. Wysocki Acked-by: Alan Stern 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

PM / Domains: Fix handling of wakeup devices during system resume

2012-04-02T16:52:37Z

commit cc85b20780562d404e18a47b9b55b4a5102ae53e upstream. During system suspend pm_genpd_suspend_noirq() checks if the given device is in a wakeup path (i.e. it appears to be needed for one or more wakeup devices to work or is a wakeup device itself) and if it needs to be "active" for wakeup to work. If that is the case, the function returns 0 without incrementing the device domain's counter of suspended devices and without executing genpd_stop_dev() for the device. In consequence, the device is not stopped (e.g. its clock isn't disabled) and power is always supplied to its domain in the resulting system sleep state. However, pm_genpd_resume_noirq() doesn't repeat that check and it runs genpd_start_dev() and decrements the domain's counter of suspended devices even for the wakeup device that weren't stopped by pm_genpd_suspend_noirq(). As a result, the start callback may be run unnecessarily for them and their domains' counters of suspended devices may become negative. Both outcomes aren't desirable, so fix pm_genpd_resume_noirq() to look for wakeup devices that might not be stopped by during system suspend. Signed-off-by: Rafael J. Wysocki Tested-by: Simon Horman Signed-off-by: Greg Kroah-Hartman

regmap: Fix cache defaults initialization from raw cache defaults

2012-03-01T00:30:52Z

commit 61cddc57dc14a5dffa0921d9a24fd68edbb374ac upstream. Currently registers with a value of 0 are ignored when initializing the register defaults from raw defaults. This worked in the past, because registers without a explicit default were assumed to have a default value of 0. This was changed in commit b03622a8 ("regmap: Ensure rbtree syncs registers set to zero properly"). As a result registers, which have a raw default value of 0 are now assumed to have no default. This again can result in unnecessary writes when syncing the cache. It will also result in unnecessary reads for e.g. the first update operation. In the case where readback is not possible this will even let the update operation fail, if the register has not been written to before. So this patch removes the check. Instead it adds a check to ignore raw defaults for registers which are volatile, since those registers are not cached. Signed-off-by: Lars-Peter Clausen Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

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