kernel/linux.git/drivers/base, branch v4.5.3

PM / Domains: Fix removal of a subdomain

2016-05-04T21:49:11+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:49:11+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

device property: fwnode->secondary may contain ERR_PTR(-ENODEV)

2016-03-09T00:07:43+00:00

This fixes BUG triggered when fwnode->secondary is not NULL, but has ERR_PTR(-ENODEV) instead. BUG: unable to handle kernel paging request at ffffffffffffffed IP: [] __fwnode_property_read_string+0x26/0x160 PGD 200e067 PUD 2010067 PMD 0 Oops: 0000 [#1] SMP KASAN Modules linked in: dwc3_pci(+) dwc3 CPU: 0 PID: 1138 Comm: modprobe Not tainted 4.5.0-rc5+ #61 task: ffff88015aaf5b00 ti: ffff88007b958000 task.ti: ffff88007b958000 RIP: 0010:[] [] __fwnode_property_read_string+0x26/0x160 RSP: 0018:ffff88007b95eff8 EFLAGS: 00010246 RAX: fffffbfffffffffd RBX: ffffffffffffffed RCX: ffff88015999cd37 RDX: dffffc0000000000 RSI: ffffffff81e11bc0 RDI: ffffffffffffffed RBP: ffff88007b95f020 R08: 0000000000000000 R09: 0000000000000000 R10: ffff88007b90f7cf R11: 0000000000000000 R12: ffff88007b95f0a0 R13: 00000000fffffffa R14: ffffffff81e11bc0 R15: ffff880159ea37a0 FS: 00007ff35f46c700(0000) GS:ffff88015b800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffffffffffffffed CR3: 000000007b8be000 CR4: 00000000001006f0 Stack: ffff88015999cd20 ffffffff81e11bc0 ffff88007b95f0a0 ffff88007b383dd8 ffff880159ea37a0 ffff88007b95f048 ffffffff81677d03 ffff88007b952460 ffffffff81e11bc0 ffff88007b95f0a0 ffff88007b95f070 ffffffff81677d40 Call Trace: [] fwnode_property_read_string+0x43/0x50 [] device_property_read_string+0x30/0x40 ... Fixes: 362c0b30249e (device property: Fallback to secondary fwnode if primary misses the property) Signed-off-by: Heikki Krogerus Signed-off-by: Rafael J. Wysocki

Merge branch 'component' of git://ftp.arm.linux.org.uk/~rmk/linux-arm

2016-02-14T18:40:21+00:00

Pull component helper fixes from Russell King: "A few fixes for problems people have encountered with the recent update to the component helpers" * 'component' of git://ftp.arm.linux.org.uk/~rmk/linux-arm: component: remove device from master match list on failed add component: Detach components when deleting master struct component: fix crash on x86_64 with hda audio drivers

component: remove device from master match list on failed add

2016-02-11T09:42:09+00:00

Calling component_add() may result in the completion of a set of devices, which will try to bring up a master. In bringing the master up, we populate its match array with the current set of children. If binding any of the devices fails, component_add() itself will fail, free the struct component entry, and return to the caller. The now-freed entry is never removed from the master's match array, and will later be used in a futile attempt to bind to freed memory. Bring component_add's behaviour on failure to bring up a master into line with component_del by removing the (to-be-freed) component from the master's match array. The specific case which broke was: - rockchip_drm_drv adds a component master - dwhdmi_rockchip adds a child component in probe (master incomplete) - rockchip_drm_vop adds two children in probe, which completes the set - inside component_add, we try to bring up the master, having populated the master's match array, and fail with EPROBE_DEFER from dwhdmi_rockchip; we delete the putative component - rockchip_drm_vop's probe fails and returns EPROBE_DEFER - we later re-probe rockchip_drm_vop and add the component; the master is complete, so we attempt to bring it up again - walking the match array, we find the previous child, whose master pointer doesn't match (as it has been freed in the meantime) - rockchip_drm_vop probe fails, and will never be attempted again Fixes: ffc30b74fd6d01588bd3fdebc3b1acc0857e6fc8 Signed-off-by: Daniel Stone Cc: Russell King Cc: Thierry Reding Cc: Laurent Pinchart Signed-off-by: Russell King

Merge tag 'regmap-fix-v4.5-big-endian' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap

2016-02-08T18:20:06+00:00

Pull regmap fix from Mark Brown: "A single revert back to v4.4 endianness handling. Commit 29bb45f25ff3 ("regmap-mmio: Use native endianness for read/write") attempted to fix some long standing bugs in the MMIO implementation for big endian systems caused by duplicate byte swapping in both regmap and readl()/writel(). Sadly the fix makes things worse rather than better, so revert it for now" * tag 'regmap-fix-v4.5-big-endian' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regmap: mmio: Revert to v4.4 endianness handling

Merge branches 'pm-core' and 'pm-domains'

2016-02-05T23:34:01+00:00

* pm-core: PM: Avoid false-positive warnings in dev_pm_domain_set() ACPI / LPSS: set PM domain via helper setter * pm-domains: PM / Domains: Silence compiler warning for an unused function

regmap: mmio: Revert to v4.4 endianness handling

2016-02-05T11:22:04+00:00

Commit 29bb45f25ff3 (regmap-mmio: Use native endianness for read/write) attempted to fix some long standing bugs in the MMIO implementation for big endian systems caused by duplicate byte swapping in both regmap and readl()/writel() which affected MIPS systems as when they are in big endian mode they flip the endianness of all registers in the system, not just the CPU. MIPS systems had worked around this by declaring regmap using IPs as little endian which is inaccurate, unfortunately the issue had not been reported. Sadly the fix makes things worse rather than better. By changing the behaviour to match the documentation it caused behaviour changes for other IPs which broke them and by using the __raw I/O accessors to avoid the endianness swapping in readl()/writel() it removed some memory ordering guarantees and could potentially generate unvirtualisable instructions on some architectures. Unfortunately sorting out all this mess in any half way sensible fashion was far too invasive to go in during an -rc cycle so instead let's go back to the old broken behaviour for v4.5, the better fixes are already queued for v4.6. This does mean that we keep the broken MIPS DTs for another release but that seems the least bad way of handling the situation. Reported-by: Johannes Berg Signed-off-by: Mark Brown

PM: Avoid false-positive warnings in dev_pm_domain_set()

2016-02-03T18:10:37+00:00

There is a WARN_ON() in dev_pm_domain_set() that triggers on attempts to set the pm_domain pointer for devices with a driver bound. However, that WARN_ON() triggers on attempts to clear the pointer too and the test it uses is based on checking the device's p->knode_driver pointer which still is set when the device bus type's/driver's ->remove callback has been executed. This leads to false-positive warnings when bus type code calls dev_pm_domain_set() to clear the pm_domain pointer after invoking the driver's ->remove() callback. To avoid those false-positives, make dev_pm_domain_set() check if the pointer passed to it is NULL and skip the warning in that case. Fixes: 989561de9b51 (PM / Domains: add setter for dev.pm_domain) Signed-off-by: Rafael J. Wysocki Tested-by: Andy Shevchenko Tested-by: Sinan Kaya Tested-by: Steven Rostedt Acked-by: Ulf Hansson

PM / Domains: Silence compiler warning for an unused function

2016-02-03T00:24:36+00:00

The only remaining caller of genpd_poweron() is conditionally compiled based on CONFIG_PM_GENERIC_DOMAINS_OF, so we get a warning when that is unset. By moving the locking/unlocking of the genpd outside genpd_poweron(), thus to the caller, genpd_poweron() becomes redundant. Within this context let's then rename the wrapper function, __genpd_poweron(), to genpd_poweron() as it will then be consistent with its friend genpd_poweroff(). This change silence the warning about the unused function. Reported-by: Arnd Bergmann Fixes: ea823c7cbffa "PM / Domains: Remove pm_genpd_poweron() API" Signed-off-by: Ulf Hansson Acked-by: Arnd Bergmann Cc: 4.4+ # 4.4+ Signed-off-by: Rafael J. Wysocki