talos-obmc-linux/drivers/base, branch v4.4.16

base: make module_create_drivers_dir race-free

2016-07-27T16:47:32+00:00

commit 7e1b1fc4dabd6ec8e28baa0708866e13fa93c9b3 upstream. Modules which register drivers via standard path (driver_register) in parallel can cause a warning: WARNING: CPU: 2 PID: 3492 at ../fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80 sysfs: cannot create duplicate filename '/module/saa7146/drivers' Modules linked in: hexium_gemini(+) mxb(+) ... ... Call Trace: ... [] sysfs_warn_dup+0x62/0x80 [] sysfs_create_dir_ns+0x77/0x90 [] kobject_add_internal+0xb4/0x340 [] kobject_add+0x68/0xb0 [] kobject_create_and_add+0x31/0x70 [] module_add_driver+0xc3/0xd0 [] bus_add_driver+0x154/0x280 [] driver_register+0x60/0xe0 [] __pci_register_driver+0x60/0x70 [] saa7146_register_extension+0x64/0x90 [saa7146] [] hexium_init_module+0x11/0x1000 [hexium_gemini] ... As can be (mostly) seen, driver_register causes this call sequence: -> bus_add_driver -> module_add_driver -> module_create_drivers_dir The last one creates "drivers" directory in /sys/module/<...>. When this is done in parallel, the directory is attempted to be created twice at the same time. This can be easily reproduced by loading mxb and hexium_gemini in parallel: while :; do modprobe mxb & modprobe hexium_gemini wait rmmod mxb hexium_gemini saa7146_vv saa7146 done saa7146 calls pci_register_driver for both mxb and hexium_gemini, which means /sys/module/saa7146/drivers is to be created for both of them. Fix this by a new mutex in module_create_drivers_dir which makes the test-and-create "drivers" dir atomic. I inverted the condition and removed 'return' to avoid multiple unlocks or a goto. Signed-off-by: Jiri Slaby Fixes: fe480a2675ed (Modules: only add drivers/ direcory if needed) Signed-off-by: Greg Kroah-Hartman

PM / sleep: Handle failures in device_suspend_late() consistently

2016-06-08T01:14:37+00:00

commit 3a17fb329da68cb00558721aff876a80bba2fdb9 upstream. Grygorii Strashko reports: The PM runtime will be left disabled for the device if its .suspend_late() callback fails and async suspend is not allowed for this device. In this case device will not be added in dpm_late_early_list and dpm_resume_early() will ignore this device, as result PM runtime will be disabled for it forever (side effect: after 8 subsequent failures for the same device the PM runtime will be reenabled due to disable_depth overflow). To fix this problem, add devices to dpm_late_early_list regardless of whether or not device_suspend_late() returns errors for them. That will ensure failures in there to be handled consistently for all devices regardless of their async suspend/resume status. Reported-by: Grygorii Strashko Tested-by: Grygorii Strashko Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

PM / Runtime: Fix error path in pm_runtime_force_resume()

2016-06-08T01:14:34+00:00

commit 0ae3aeefabbeef26294e7a349b51f1c761d46c9f upstream. As pm_runtime_set_active() may fail because the device's parent isn't active, we can end up executing the ->runtime_resume() callback for the device when it isn't allowed. Fix this by invoking pm_runtime_set_active() before running the callback and let's also deal with the error code. Fixes: 37f204164dfb (PM: Add pm_runtime_suspend|resume_force functions) Signed-off-by: Ulf Hansson Reviewed-by: Linus Walleij Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

regmap: spmi: Fix regmap_spmi_ext_read in multi-byte case

2016-05-19T00:06:48+00:00

commit dec8e8f6e6504aa3496c0f7cc10c756bb0e10f44 upstream. Specifically for the case of reads that use the Extended Register Read Long command, a multi-byte read operation is broken up into 8-byte chunks. However the call to spmi_ext_register_readl() is incorrectly passing 'val_size', which if greater than 8 will always fail. The argument should instead be 'len'. Fixes: c9afbb05a9ff ("regmap: spmi: support base and extended register spaces") Signed-off-by: Jack Pham Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

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