linux-toradex.git/drivers/base, branch v3.3.5

regmap: prevent division by zero in rbtree_show

2012-04-13T16:13:55+00:00

commit c04c1b9ee8f30c7a3a25e20e406247003f634ebe upstream.

If there are no nodes in the cache, nodes will be 0, so calculating
"registers / nodes" will cause division by zero.

Signed-off-by: Stephen Warren 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

PM / Runtime: don't forget to wake up waitqueue on failure

2012-04-13T16:13:53+00:00

commit f2791d733a2f06997b573d1a3cfde21e6f529826 upstream.

This patch (as1535) fixes a bug in the runtime PM core.  When a
runtime suspend attempt completes, whether successfully or not, the
device's power.wait_queue is supposed to be signalled.  But this
doesn't happen in the failure pathway of rpm_suspend() when another
autosuspend attempt is rescheduled.  As a result, a task can get stuck
indefinitely on the wait queue (I have seen this happen in testing).

The patch fixes the problem by moving the wake_up_all() call up near
the start of the failure code.

Signed-off-by: Alan Stern 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

firmware_class: Do not warn that system is not ready from async loads

2012-04-13T16:13:53+00:00

commit 9b78c1da60b3c62ccdd1509f0902ad19ceaf776b upstream.

If firmware is requested asynchronously, by calling
request_firmware_nowait(), there is no reason to fail the request
(and warn the user) when the system is (presumably temporarily)
unready to handle it (because user space is not available yet or
frozen).  For this reason, introduce an alternative routine for
read-locking umhelper_sem, usermodehelper_read_lock_wait(), that
will wait for usermodehelper_disabled to be unset (possibly with
a timeout) and make request_firmware_work_func() use it instead of
usermodehelper_read_trylock().

Accordingly, modify request_firmware() so that it uses
usermodehelper_read_trylock() to acquire umhelper_sem and remove
the code related to that lock from _request_firmware().

Signed-off-by: Rafael J. Wysocki 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

firmware_class: Split _request_firmware() into three functions, v2

2012-04-13T16:13:53+00:00

commit 811fa4004485dec8977176bf605a5b0508ee206c upstream.

Split _request_firmware() into three functions,
_request_firmware_prepare() doing preparatory work that need not be
done under umhelper_sem, _request_firmware_cleanup() doing the
post-error cleanup and _request_firmware() carrying out the remaining
operations.

This change is requisite for moving the acquisition of umhelper_sem
from _request_firmware() to the callers, which is going to be done
subsequently.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Greg Kroah-Hartman 
Reviewed-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman

firmware_class: Rework usermodehelper check

2012-04-13T16:13:53+00:00

commit fe2e39d8782d885755139304d8dba0b3e5bfa878 upstream.

Instead of two functions, read_lock_usermodehelper() and
usermodehelper_is_disabled(), used in combination, introduce
usermodehelper_read_trylock() that will only return with umhelper_sem
held if usermodehelper_disabled is unset (and will return -EAGAIN
otherwise) and make _request_firmware() use it.

Rename read_unlock_usermodehelper() to
usermodehelper_read_unlock() to follow the naming convention of the
new function.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

PM / Domains: Introduce "always on" device flag

2012-04-02T17:32:10+00:00

This is a backport of mainline commit
1e78a0c7fc92aee076965d516cf54475c39e9894.

The TMU device on the Mackerel board belongs to the A4R power domain
and loses power when the domain is turned off.  Unfortunately, the
TMU driver is not prepared to cope with such situations and crashes
the system when that happens.  To work around this problem introduce
a new helper function, pm_genpd_dev_always_on(), allowing a device
driver to mark its device as "always on" in case it belongs to a PM
domain, which will make the generic PM domains core code avoid
powering off the domain containing the device, both at run time and
during system suspend.

Signed-off-by: Rafael J. Wysocki 
Tested-by: Simon Horman 
Acked-by: Paul Mundt 
Signed-off-by: Greg Kroah-Hartman

PM / Domains: Check domain status during hibernation restore of devices

2012-04-02T17:32:10+00:00

This is a backport of mainline commit
18dd2ece3cde14cfd42e95a89eb14016699a5f15.

Power domains that were off before hibernation shouldn't be turned on
during device restore, so prevent that from happening.

This change fixed up mainline commit
65533bbf63b4f37723fdfedc73d0653958973323

    PM / Domains: Fix hibernation restore of devices, v2

that didn't include it by mistake.

Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

PM / Domains: Fix hibernation restore of devices, v2

2012-04-02T17:32:09+00:00

This is a backport of mainline commit
65533bbf63b4f37723fdfedc73d0653958973323.

During resume from hibernation pm_genpd_restore_noirq() should only
power off domains whose suspend_power_off flags are set once and
not every time it is called for a device in the given domain.
Moreover, it shouldn't decrement genpd->suspended_count, because
that field is not touched during device freezing and therefore it is
always equal to 0 when pm_genpd_restore_noirq() runs for the first
device in the given domain.

This means pm_genpd_restore_noirq() may use genpd->suspended_count
to determine whether or not it it has been called for the domain in
question already in this cycle (it only needs to increment that
field every time it runs for this purpose) and whether or not it
should check if the domain needs to be powered off.  For that to
work, though, pm_genpd_prepare() has to clear genpd->suspended_count
when it runs for the first device in the given domain (in which case
that flag need not be cleared during domain initialization).

Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

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

2012-04-02T17:31:54+00:00

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

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap

2012-02-18T23:37:25+00:00

Fixes a bootstrapping issue for some registers when a less commonly used
method for register cache initialisation is used.  Only affects a fairly
small proportion of users that both don't use explicit register defaults
and do use the cache.

* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
  regmap: Fix cache defaults initialization from raw cache defaults