linux-stable.git/drivers/base, branch v4.4.10

PM / Domains: Fix removal of a subdomain

2016-05-04T21:48:51+00:00

commit beda5fc1ff9b527059290a97b672d2ee0eb7b92f upstream.

Commit 30e7a65b3fdb (PM / Domains: Ensure subdomain is not in use
before removing) added a test to ensure that a subdomain is not a
master to another subdomain or if any devices are using the subdomain
before removing. This change incorrectly used the "slave_links" list to
determine if the subdomain is a master to another subdomain, where it
should have been using the "master_links" list instead. The
"slave_links" list will never be empty for a subdomain and so a
subdomain can never be removed. Fix this by testing if the
"master_links" list is empty instead.

Fixes: 30e7a65b3fdb (PM / Domains: Ensure subdomain is not in use before removing)
Signed-off-by: Jon Hunter 
Reviewed-by: Thierry Reding 
Acked-by: Ulf Hansson 
Acked-by: Kevin Hilman 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

PM / OPP: Initialize u_volt_min/max to a valid value

2016-05-04T21:48:51+00:00

commit c88c395f4a6485f23f81e385c79945d68bcd5c5d upstream.

We kept u_volt_min/max initialized to 0, when only the target voltage is
present in DT, instead of the target/min/max triplet.

This didn't go well with the regulator framework, as on few calls the
min voltage was set to target and max was set to 0 and so resulted in a
kernel crash like below:

kernel BUG at ../drivers/regulator/core.c:216!

[] (regulator_check_voltage) from [] (regulator_set_voltage_unlocked+0x58/0x230)
[] (regulator_set_voltage_unlocked) from [] (regulator_set_voltage+0x28/0x54)
[] (regulator_set_voltage) from [] (_set_opp_voltage+0x30/0x98)
[] (_set_opp_voltage) from [] (dev_pm_opp_set_rate+0xf0/0x28c)
[] (dev_pm_opp_set_rate) from [] (__cpufreq_driver_target+0x184/0x2b4)
[] (__cpufreq_driver_target) from [] (dbs_check_cpu+0x1b0/0x1f4)
[] (dbs_check_cpu) from [] (cpufreq_governor_dbs+0x324/0x5c4)
[] (cpufreq_governor_dbs) from [] (__cpufreq_governor+0xe4/0x1ec)
[] (__cpufreq_governor) from [] (cpufreq_init_policy+0x64/0x8c)
[] (cpufreq_init_policy) from [] (cpufreq_online+0x2fc/0x708)
[] (cpufreq_online) from [] (subsys_interface_register+0x94/0xd8)
[] (subsys_interface_register) from [] (cpufreq_register_driver+0x14c/0x19c)
[] (cpufreq_register_driver) from [] (dt_cpufreq_probe+0x70/0xec)
[] (dt_cpufreq_probe) from [] (platform_drv_probe+0x4c/0xb0)
[] (platform_drv_probe) from [] (driver_probe_device+0x214/0x2c0)
[] (driver_probe_device) from [] (__driver_attach+0x8c/0x90)
[] (__driver_attach) from [] (bus_for_each_dev+0x68/0x9c)
[] (bus_for_each_dev) from [] (bus_add_driver+0x1a0/0x218)
[] (bus_add_driver) from [] (driver_register+0x78/0xf8)
[] (driver_register) from [] (do_one_initcall+0x90/0x1d8)
[] (do_one_initcall) from [] (kernel_init_freeable+0x15c/0x1fc)
[] (kernel_init_freeable) from [] (kernel_init+0x8/0xf0)
[] (kernel_init) from [] (ret_from_fork+0x14/0x3c)
Code: e1550004 baffffeb e3a00000 e8bd8070 (e7f001f2)

Fix that by initializing u_volt_min/max to the target voltage in such cases.

Reported-and-tested-by: Krzysztof Kozlowski 
Fixes: 274659029c9d (PM / OPP: Add support to parse "operating-points-v2" bindings)
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

base/platform: Fix platform drivers with no probe callback

2016-02-17T20:30:55+00:00

commit 25cad69f21f5532d99e2ee73c8ab6512bcab614c upstream.

Since b8b2c7d845d5, platform_drv_probe() is called for all platform
devices. If drv->probe is NULL, and dev_pm_domain_attach() fails,
platform_drv_probe() will return the error code from dev_pm_domain_attach().

This causes real_probe() to enter the "probe_failed" path and set
dev->driver to NULL. Before b8b2c7d845d5, real_probe() would assume
success if both dev->bus->probe and drv->probe were missing. As a result,
a device and driver could be "bound" together just by matching their names;
this doesn't work any more after b8b2c7d845d5.

This may cause problems later for certain usage of platform_driver_register()
and platform_device_register_simple(). I observed a panic while loading
the tpm_tis driver with parameter "force=1" (i.e. registering tpm_tis as
a platform driver), because tpm_tis_init's assumption that the device
returned by platform_device_register_simple() was bound didn't hold any more
(tpmm_chip_alloc() dereferences chip->pdev->driver, causing panic).

This patch restores the previous (4.3.0 and earlier) behavior of
platform_drv_probe() in the case when the associated platform driver has
no "probe" function.

Fixes: b8b2c7d845d5 ("base/platform: assert that dev_pm_domain callbacks are called unconditionally")
Signed-off-by: Martin Wilck 
Cc: Martin Fuzzey 
Acked-by: Jarkko Sakkinen 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

Merge branches 'powercap', 'pm-cpufreq' and 'pm-domains'

2015-12-14T21:58:57+00:00

* powercap:
  powercap / RAPL: fix BIOS lock check

* pm-cpufreq:
  cpufreq: intel_pstate: Minor cleanup for FRAC_BITS
  cpufreq: tegra: add regulator dependency for T124

* pm-domains:
  PM / Domains: Allow runtime PM callbacks to be re-used during system PM

drivers/base/memory.c: prohibit offlining of memory blocks with missing sections

2015-12-12T18:15:34+00:00

Commit bdee237c0343 ("x86: mm: Use 2GB memory block size on large-memory
x86-64 systems") and 982792c782ef ("x86, mm: probe memory block size for
generic x86 64bit") introduced large block sizes for x86.  This made it
possible to have multiple sections per memory block where previously,
there was a only every one section per block.

Since blocks consist of contiguous ranges of section, there can be holes
in the blocks where sections are not present.  If one attempts to
offline such a block, a crash occurs since the code is not designed to
deal with this.

This patch is a quick fix to gaurd against the crash by not allowing
blocks with non-present sections to be offlined.

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=107781

Signed-off-by: Seth Jennings 
Reported-by: Andrew Banman 
Cc: Daniel J Blueman 
Cc: Yinghai Lu 
Cc: Greg KH 
Cc: Russ Anderson 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

PM / Domains: Allow runtime PM callbacks to be re-used during system PM

2015-12-10T00:37:34+00:00

A runtime PM centric subsystem/driver may typically use the runtime PM
helpers, pm_runtime_force_suspend|resume() in the system PM path. This
means the genpd's runtime PM callbacks might be invoked even when runtime
PM has been disabled for the device.

To properly cope with these and similar scenarios when these helper
functions are used, change genpd to skip validating and measuring the
device PM QOS latency.

This is needed because otherwise genpd may prevent the device to be put
into low power state. If this occurs during system PM, it causes the
sequence to be aborted as a device's system PM callback returns -EBUSY.

Fixes: ba2bbfbf6307 (PM / Domains: Remove intermediate states from the power off sequence)
Reported-by: Cao Minh Hiep 
Reported-by: Harunaga 
Signed-off-by: Ulf Hansson 
Cc: 4.3+  # 4.3+
Signed-off-by: Rafael J. Wysocki

Merge branches 'pm-domains' and 'pm-cpufreq'

2015-12-04T13:01:42+00:00

* pm-domains:
  PM / Domains: Fix bad of_node_put() in failure paths of genpd_dev_pm_attach()
  PM / Domains: Validate cases of a non-bound driver in genpd governor

* pm-cpufreq:
  cpufreq: use last policy after online for drivers with ->setpolicy

PM / Domains: Fix bad of_node_put() in failure paths of genpd_dev_pm_attach()

2015-12-04T00:21:17+00:00

It looks like these meant to be unreffing the
of_parse_phandle_with_args() node, since the error paths above it
don't do of_node_put.  That function returns a new ref in pd_args.np,
though, not a new ref on dev->of_node.  Also, it would have leaked the
ref in the success case.

Fixes "ERROR: Bad of_node_put()" on bcm2835 in the -EPROBE_DEFER case.

Fixes: aa42240ab254 (PM / Domains: Add generic OF-based PM domain look-up)
Signed-off-by: Eric Anholt 
Acked-by: Ulf Hansson 
Acked-by: Kevin Hilman 
Cc: 3.18+  # 3.18+
Signed-off-by: Rafael J. Wysocki

PM / Domains: Validate cases of a non-bound driver in genpd governor

2015-12-02T14:21:21+00:00

Recently genpd removed the requirement of a having a driver bound for its
attached devices to allow genpd to power off. That change should also have
removed a corresponding validation in the governor, let's correct that.

Fixes: 298cd0f08801 (PM / Domains: Remove dev->driver check for runtime)
Signed-off-by: Ulf Hansson 
Signed-off-by: Rafael J. Wysocki

Merge branch 'pm-sleep'

2015-11-20T00:22:33+00:00

* pm-sleep:
  PM / wakeirq: check that wake IRQ is valid before accepting it