summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-05-19Merge tag 'icc-5.19-rc1' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/djakov/icc into char-misc-next Georgi writes: interconnect changes for 5.19 These are the interconnect changes for the 5.19-rc1 merge window consisting of driver updates. Driver changes: - New driver for SC8280XP - New driver for SDX65 - SC8180X driver fixes - Constify various data structures in that are never modified - Fix clock rate caching in RPM drivers. - Misc fixes and clean-ups Signed-off-by: Georgi Djakov <djakov@kernel.org> * tag 'icc-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/djakov/icc: dt-bindings: interconnect: Remove sc7180/sdx55 ipa compatibles interconnect: qcom: sc8180x: Reformat node and bcm definitions interconnect: qcom: sc8180x: Mark some BCMs keepalive interconnect: qcom: sc8180x: Fix QUP0 nodes interconnect: qcom: sc8180x: Modernize sc8180x probe dt-bindings: interconnect: Add SC8180X QUP0 virt provider interconnect: qcom: icc-rpm: Cache every clock rate interconnect: qcom: icc-rpm: Fix for cached clock rate interconnect: qcom: sc8280xp: constify qcom_icc_bcm pointers interconnect: qcom: sc8280xp: constify icc_node pointers interconnect: qcom: sc8280xp: constify qcom_icc_desc interconnect: qcom: Add SDX65 interconnect provider driver dt-bindings: interconnect: Add Qualcomm SDX65 DT bindings interconnect: qcom: constify qcom_icc_bcm pointers interconnect: qcom: constify icc_node pointers interconnect: qcom: constify qcom_icc_desc interconnect: qcom: Add SC8280XP interconnect provider dt-bindings: interconnect: qcom: Add sc8280xp binding
2022-05-19driver core: fix deadlock in __device_attachZhang Wensheng
In __device_attach function, The lock holding logic is as follows: ... __device_attach device_lock(dev) // get lock dev async_schedule_dev(__device_attach_async_helper, dev); // func async_schedule_node async_schedule_node_domain(func) entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC); /* when fail or work limit, sync to execute func, but __device_attach_async_helper will get lock dev as well, which will lead to A-A deadlock. */ if (!entry || atomic_read(&entry_count) > MAX_WORK) { func; else queue_work_node(node, system_unbound_wq, &entry->work) device_unlock(dev) As shown above, when it is allowed to do async probes, because of out of memory or work limit, async work is not allowed, to do sync execute instead. it will lead to A-A deadlock because of __device_attach_async_helper getting lock dev. To fix the deadlock, move the async_schedule_dev outside device_lock, as we can see, in async_schedule_node_domain, the parameter of queue_work_node is system_unbound_wq, so it can accept concurrent operations. which will also not change the code logic, and will not lead to deadlock. Fixes: 765230b5f084 ("driver-core: add asynchronous probing support for drivers") Signed-off-by: Zhang Wensheng <zhangwensheng5@huawei.com> Link: https://lore.kernel.org/r/20220518074516.1225580-1-zhangwensheng5@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19kernfs: Separate kernfs_pr_cont_buf and rename_lock.Hao Luo
Previously the protection of kernfs_pr_cont_buf was piggy backed by rename_lock, which means that pr_cont() needs to be protected under rename_lock. This can cause potential circular lock dependencies. If there is an OOM, we have the following call hierarchy: -> cpuset_print_current_mems_allowed() -> pr_cont_cgroup_name() -> pr_cont_kernfs_name() pr_cont_kernfs_name() will grab rename_lock and call printk. So we have the following lock dependencies: kernfs_rename_lock -> console_sem Sometimes, printk does a wakeup before releasing console_sem, which has the dependence chain: console_sem -> p->pi_lock -> rq->lock Now, imagine one wants to read cgroup_name under rq->lock, for example, printing cgroup_name in a tracepoint in the scheduler code. They will be holding rq->lock and take rename_lock: rq->lock -> kernfs_rename_lock Now they will deadlock. A prevention to this circular lock dependency is to separate the protection of pr_cont_buf from rename_lock. In principle, rename_lock is to protect the integrity of cgroup name when copying to buf. Once pr_cont_buf has got its content, rename_lock can be dropped. So it's safe to drop rename_lock after kernfs_name_locked (and kernfs_path_from_node_locked) and rely on a dedicated pr_cont_lock to protect pr_cont_buf. Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Hao Luo <haoluo@google.com> Link: https://lore.kernel.org/r/20220516190951.3144144-1-haoluo@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19cpuidle: riscv-sbi: Fix code to allow a genpd governor to be usedUlf Hansson
The intent is to use a genpd governor when there are some states that needs to be managed. Although, the current code ends up to never assign a governor, let's fix this. Fixes: 6abf32f1d9c50 ("cpuidle: Add RISC-V SBI CPU idle driver") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Anup Patel <anup@brainfault.org> Tested-by: Anup Patel <anup@brainfault.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19cpuidle: psci: Fix regression leading to no genpd governorUlf Hansson
While factoring out the PM domain related code from PSCI domain driver into a set of library functions, a regression when initializing the genpds got introduced. More precisely, we fail to assign a genpd governor, so let's fix this. Fixes: 9d976d6721df ("cpuidle: Factor-out power domain related code from PSCI domain driver") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19staging: r8188eu: prevent ->Ssid overflow in rtw_wx_set_scan()Denis Efremov
This code has a check to prevent read overflow but it needs another check to prevent writing beyond the end of the ->Ssid[] array. Fixes: 2b42bd58b321 ("staging: r8188eu: introduce new os_dep dir for RTL8188eu driver") Cc: stable <stable@vger.kernel.org> Signed-off-by: Denis Efremov <denis.e.efremov@oracle.com> Link: https://lore.kernel.org/r/20220518070052.108287-1-denis.e.efremov@oracle.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19topology: Remove unused cpu_cluster_mask()Dietmar Eggemann
default_topology[] uses cpu_clustergroup_mask() for the CLS level (guarded by CONFIG_SCHED_CLUSTER) which is currently provided by x86 (arch/x86/kernel/smpboot.c) and arm64 (drivers/base/arch_topology.c). Fixes: 778c558f49a2 ("sched: Add cluster scheduler level in core and related Kconfig for ARM64") Acked-by: Barry Song <baohua@kernel.org> Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com> Link: https://lore.kernel.org/r/20220513093433.425163-1-dietmar.eggemann@arm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19driver core: Extend deferred probe timeout on driver registrationSaravana Kannan
The deferred probe timer that's used for this currently starts at late_initcall and runs for driver_deferred_probe_timeout seconds. The assumption being that all available drivers would be loaded and registered before the timer expires. This means, the driver_deferred_probe_timeout has to be pretty large for it to cover the worst case. But if we set the default value for it to cover the worst case, it would significantly slow down the average case. For this reason, the default value is set to 0. Also, with CONFIG_MODULES=y and the current default values of driver_deferred_probe_timeout=0 and fw_devlink=on, devices with missing drivers will cause their consumer devices to always defer their probes. This is because device links created by fw_devlink defer the probe even before the consumer driver's probe() is called. Instead of a fixed timeout, if we extend an unexpired deferred probe timer on every successful driver registration, with the expectation more modules would be loaded in the near future, then the default value of driver_deferred_probe_timeout only needs to be as long as the worst case time difference between two consecutive module loads. So let's implement that and set the default value to 10 seconds when CONFIG_MODULES=y. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Rob Herring <robh@kernel.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Will Deacon <will@kernel.org> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Kevin Hilman <khilman@kernel.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Mark Brown <broonie@kernel.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Cc: linux-gpio@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: iommu@lists.linux-foundation.org Reviewed-by: Mark Brown <broonie@kernel.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20220429220933.1350374-1-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19PM / devfreq: passive: Return non-error when not-supported event is requiredChanwoo Choi
Each devfreq governor specifies the supported governor event such as GOV_START and GOV_STOP. When not-supported event is required, just return non-error. But, commit ce9a0d88d97a ("PM / devfreq: Add cpu based scaling support to passive governor") returned the error value. So that return non-error value when not-supported event is required. Fixes: ce9a0d88d97a ("PM / devfreq: Add cpu based scaling support to passive governor") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19kernel/reboot: Add devm_register_restart_handler()Dmitry Osipenko
Add devm_register_restart_handler() helper that registers sys-off handler using restart mode and with a default priority. Most drivers will want to register restart handler with a default priority, so this helper will reduce the boilerplate code and make code easier to read and follow. Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19kernel/reboot: Add devm_register_power_off_handler()Dmitry Osipenko
Add devm_register_power_off_handler() helper that registers sys-off handler using power-off mode and with a default priority. Most drivers will want to register power-off handler with a default priority, so this helper will reduce the boilerplate code and make code easier to read and follow. Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19soc/tegra: pmc: Use sys-off handler API to power off Nexus 7 properlyDmitry Osipenko
Nexus 7 Android tablet can be turned off using a special bootloader command which is conveyed to bootloader by putting magic value into the special scratch register and then rebooting normally. This power-off method should be invoked if USB cable is connected. Bootloader then will display battery status and power off the device. This behaviour is borrowed from downstream kernel and matches user expectations, otherwise it looks like device got hung during power-off and it may wake up on USB disconnect. Switch PMC driver to sys-off handler API, which provides drivers with chained power-off callbacks functionality that is required for powering-off devices properly. It also brings resource-managed API for the restart handler registration that makes PMC driver code cleaner. Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19reboot: Remove pm_power_off_prepare()Dmitry Osipenko
All pm_power_off_prepare() users were converted to sys-off handler API. Remove the obsolete global callback variable. Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19regulator: pfuze100: Use devm_register_sys_off_handler()Dmitry Osipenko
Use devm_register_sys_off_handler() that replaces global pm_power_off_prepare variable and allows to register multiple power-off handlers. Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19ACPI: power: Switch to sys-off handler APIDmitry Osipenko
Switch to sys-off API that replaces legacy pm_power_off callbacks, allowing us to remove global pm_* variables and support chaining of all restart and power-off modes consistently. Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19memory: emif: Use kernel_can_power_off()Dmitry Osipenko
Replace legacy pm_power_off with kernel_can_power_off() helper that is aware about chained power-off handlers. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19mips: Use do_kernel_power_off()Dmitry Osipenko
Kernel now supports chained power-off handlers. Use do_kernel_power_off() that invokes chained power-off handlers. It also invokes legacy pm_power_off() for now, which will be removed once all drivers will be converted to the new sys-off API. Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19ia64: Use do_kernel_power_off()Dmitry Osipenko
Kernel now supports chained power-off handlers. Use do_kernel_power_off() that invokes chained power-off handlers. It also invokes legacy pm_power_off() for now, which will be removed once all drivers will be converted to the new sys-off API. Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19x86: Use do_kernel_power_off()Dmitry Osipenko
Kernel now supports chained power-off handlers. Use do_kernel_power_off() that invokes chained power-off handlers. It also invokes legacy pm_power_off() for now, which will be removed once all drivers will be converted to the new sys-off API. Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19sh: Use do_kernel_power_off()Dmitry Osipenko
Kernel now supports chained power-off handlers. Use do_kernel_power_off() that invokes chained power-off handlers. It also invokes legacy pm_power_off() for now, which will be removed once all drivers will be converted to the new sys-off API. Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19m68k: Switch to new sys-off handler APIDmitry Osipenko
Kernel now supports chained power-off handlers. Use register_power_off_handler() that registers power-off handlers and do_kernel_power_off() that invokes chained power-off handlers. Legacy pm_power_off() will be removed once all drivers will be converted to the new sys-off API. Normally arch code should adopt only the do_kernel_power_off() at first, but m68k is a special case because it uses pm_power_off() "inside out", i.e. pm_power_off() invokes machine_power_off() [in fact it does nothing], while it's machine_power_off() that should invoke the pm_power_off(), and thus, we can't convert platforms to the new API separately. There are only two platforms changed here, so it's not a big deal. Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19powerpc: Use do_kernel_power_off()Dmitry Osipenko
Kernel now supports chained power-off handlers. Use do_kernel_power_off() that invokes chained power-off handlers. It also invokes legacy pm_power_off() for now, which will be removed once all drivers will be converted to the new sys-off API. Acked-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19xen/x86: Use do_kernel_power_off()Dmitry Osipenko
Kernel now supports chained power-off handlers. Use do_kernel_power_off() that invokes chained power-off handlers. It also invokes legacy pm_power_off() for now, which will be removed once all drivers will be converted to the new sys-off API. Acked-by: Juergen Gross <jgross@suse.com> Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19parisc: Use do_kernel_power_off()Dmitry Osipenko
Kernel now supports chained power-off handlers. Use do_kernel_power_off() that invokes chained power-off handlers. It also invokes legacy pm_power_off() for now, which will be removed once all drivers will be converted to the new sys-off API. Acked-by: Helge Deller <deller@gmx.de> # parisc Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19arm64: Use do_kernel_power_off()Dmitry Osipenko
Kernel now supports chained power-off handlers. Use do_kernel_power_off() that invokes chained power-off handlers. It also invokes legacy pm_power_off() for now, which will be removed once all drivers will be converted to the new sys-off API. Acked-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19riscv: Use do_kernel_power_off()Dmitry Osipenko
Kernel now supports chained power-off handlers. Use do_kernel_power_off() that invokes chained power-off handlers. It also invokes legacy pm_power_off() for now, which will be removed once all drivers will be converted to the new sys-off API. Acked-by: Palmer Dabbelt <palmer@dabbelt.com> Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19csky: Use do_kernel_power_off()Dmitry Osipenko
Kernel now supports chained power-off handlers. Use do_kernel_power_off() that invokes chained power-off handlers. It also invokes legacy pm_power_off() for now, which will be removed once all drivers will be converted to the new sys-off API. Acked-by: Guo Ren <guoren@kernel.org> Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19ARM: Use do_kernel_power_off()Dmitry Osipenko
Kernel now supports chained power-off handlers. Use do_kernel_power_off() that invokes chained power-off handlers. It also invokes legacy pm_power_off() for now, which will be removed once all drivers will be converted to the new sys-off API. Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19kernel/reboot: Add register_platform_power_off()Dmitry Osipenko
Add platform-level registration helpers that will ease transition of the arch/platform power-off callbacks to the new sys-off based API, allowing us to remove the global pm_power_off variable in the future. Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19kernel/reboot: Add kernel_can_power_off()Dmitry Osipenko
Add kernel_can_power_off() helper that replaces open-coded checks of the global pm_power_off variable. This is a necessary step towards supporting chained power-off handlers. Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19kernel/reboot: Add stub for pm_power_offDmitry Osipenko
Add weak stub for the global pm_power_off callback variable. This will allow us to remove pm_power_off definitions from arch/ code and transition to the new sys-off based API that will replace the global variable. Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19kernel/reboot: Add do_kernel_power_off()Dmitry Osipenko
Add do_kernel_power_off() helper that will remove open-coded pm_power_off invocations from the architecture code. This is the first step on the way to remove the global pm_power_off variable, which will allow us to implement consistent power-off chaining support. Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19kernel/reboot: Wrap legacy power-off callbacks into sys-off handlersDmitry Osipenko
Wrap legacy power-off callbacks into sys-off handlers in order to support co-existence of both legacy and new callbacks while we're in process of upgrading legacy callbacks to the new API. Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19kernel/reboot: Introduce sys-off handler APIDmitry Osipenko
In order to support power-off chaining we need to get rid of the global pm_* variables, replacing them with the new kernel API functions that support chaining. Introduce new generic sys-off handler API that brings the following features: 1. Power-off and restart handlers are registered using same API function that supports chaining, hence all power-off and restart modes will support chaining using this unified function. 2. Prevents notifier priority collisions by disallowing registration of multiple handlers at the non-default priority level. 3. Supports passing opaque user argument to callback, which allows us to remove global variables from drivers. This patch adds support of the following sys-off modes: - SYS_OFF_MODE_POWER_OFF_PREPARE that replaces global pm_power_off_prepare variable and provides chaining support for power-off-prepare handlers. - SYS_OFF_MODE_POWER_OFF that replaces global pm_power_off variable and provides chaining support for power-off handlers. - SYS_OFF_MODE_RESTART that provides a better restart API, removing a need from drivers to have a global scratch variable by utilizing the opaque callback argument. Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19notifier: Add blocking/atomic_notifier_chain_register_unique_prio()Dmitry Osipenko
Add variant of blocking/atomic_notifier_chain_register() functions that allow registration of a notifier only if it has unique priority, otherwise -EBUSY error code is returned by the new functions. Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19MAINTAINERS: add Russ Weight as a firmware loader maintainerLuis Chamberlain
Russ has done extensive rework on the usermode helper interface for the firmware loader. He's also exressed recent interest with maintenance and has kindly agreed to help review generic patches for the firmware loader. So add him as a new maintainer! Signed-off-by: Luis Chamberlain <mcgrof@kernel.org> Signed-off-by: Russ Weight <russell.h.weight@intel.com> Link: https://lore.kernel.org/r/20220512185529.3138310-1-mcgrof@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19driver: base: fix UAF when driver_attach failedSchspa Shi
When driver_attach(drv); failed, the driver_private will be freed. But it has been added to the bus, which caused a UAF. To fix it, we need to delete it from the bus when failed. Fixes: 190888ac01d0 ("driver core: fix possible missing of device probe") Signed-off-by: Schspa Shi <schspa@gmail.com> Link: https://lore.kernel.org/r/20220513112444.45112-1-schspa@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19test_firmware: fix end of loop test in upload_read_show()Dan Carpenter
If a list_for_each_entry() loop exits without hitting a break statement then the iterator points to invalid memory. So in this code the "tst->name" dereference is an out bounds read. It's an offset from the &test_upload_list pointer and it will likely work fine most of the time but it's not correct. One alternative is to fix this this by changing the test to: if (list_entry_is_head(tst, &test_upload_list, node)) { But the simpler, trendy new way is just create a new variable and test for NULL. Fixes: a31ad463b72d ("test_firmware: Add test support for firmware upload") Reviewed-by: Russ Weight <russell.h.weight@intel.com> Acked-by: Luis Chamberlain <mcgrof@kernel.org> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/YnTGU3UJOIA09I7e@kili Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19driver core: location: Add "back" as a possible output for panelWon Chung
Add "back" as a possible panel output when _PLD output from ACPI indicates back panel. Fixes: 6423d2951087 ("driver core: Add sysfs support for physical location of a device") Signed-off-by: Won Chung <wonchung@google.com> Link: https://lore.kernel.org/r/20220509214930.3573518-1-wonchung@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19driver core: location: Free struct acpi_pld_info *pldWon Chung
After struct acpi_pld_info *pld is used to fill in physical location values, it should be freed to prevent memleak. Suggested-by: Yu Watanabe <watanabe.yu@gmail.com> Signed-off-by: Won Chung <wonchung@google.com> Link: https://lore.kernel.org/r/20220509173135.3515126-1-wonchung@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19driver core: Add "*" wildcard support to driver_async_probe cmdline paramSaravana Kannan
There's currently no way to use driver_async_probe kernel cmdline param to enable default async probe for all drivers. So, add support for "*" to match with all driver names. When "*" is used, all other drivers listed in driver_async_probe are drivers that will NOT match the "*". For example: * driver_async_probe=drvA,drvB,drvC drvA, drvB and drvC do asynchronous probing. * driver_async_probe=* All drivers do asynchronous probing except those that have set PROBE_FORCE_SYNCHRONOUS flag. * driver_async_probe=*,drvA,drvB,drvC All drivers do asynchronous probing except drvA, drvB, drvC and those that have set PROBE_FORCE_SYNCHRONOUS flag. Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Feng Tang <feng.tang@intel.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20220504005344.117803-1-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-19dmaengine: ti: deprecate '#dma-channels'Krzysztof Kozlowski
The generic property, used in most of the drivers and defined in generic dma-common DT bindings, is 'dma-channels'. Switch to new property while keeping backward compatibility. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20220427161126.647073-4-krzysztof.kozlowski@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19notifier: Add atomic_notifier_call_chain_is_empty()Dmitry Osipenko
Add atomic_notifier_call_chain_is_empty() that returns true if given atomic call chain is empty. The first user of this new notifier API function will be the kernel power-off core code that will support power-off call chains. The core code will need to check whether there is a power-off handler registered at all in order to decide whether to halt machine or power it off. Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19dmaengine: mmp: deprecate '#dma-channels'Krzysztof Kozlowski
The generic property, used in most of the drivers and defined in generic dma-common DT bindings, is 'dma-channels'. Switch to new property while keeping backward compatibility. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220503065407.52188-4-krzysztof.kozlowski@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19dmaengine: pxa: deprecate '#dma-channels' and '#dma-requests'Krzysztof Kozlowski
The generic properties, used in most of the drivers and defined in generic dma-common DT bindings, are 'dma-channels' and 'dma-requests'. Switch to new properties while keeping backward compatibility. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220503065407.52188-3-krzysztof.kozlowski@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19dt-bindings: dmaengine: mmp: deprecate '#dma-channels' and '#dma-requests'Krzysztof Kozlowski
The generic properties, used in most of the drivers and defined in generic dma-common DT bindings, are 'dma-channels' and 'dma-requests'. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220503065407.52188-2-krzysztof.kozlowski@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19dmaengine: tegra: Fix build error without IOMMU_APIYueHaibing
drivers/dma/tegra186-gpc-dma.c: In function ‘tegra_dma_probe’: drivers/dma/tegra186-gpc-dma.c:1364:24: error: ‘struct iommu_fwspec’ has no member named ‘ids’ stream_id = iommu_spec->ids[0] & 0xffff; ^~ Make TEGRA186_GPC_DMA depends on IOMMU_API to fix this. Fixes: ee17028009d4 ("dmaengine: tegra: Add tegra gpcdma driver") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20220505093236.15076-1-yuehaibing@huawei.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19Merge tag 'thermal-v5.19-rc1' of ↵Rafael J. Wysocki
git://git.kernel.org/pub/scm/linux/kernel/git/thermal/linux Pull thermal control material for 5.19-rc1 from Daniel Lezcano: - Add the new k3 j72xx bangdap driver and the corresponding bindings (Keerthy) - Fix the missing of_node_put() in the SC iMX driver at probe timer (Miaoqian Lin) - Fix memory leak in __thermal_cooling_device_register() when device_register() fails by calling thermal_cooling_device_destroy_sysfs() (Yang Yingliang) - Add sc8180x and sc8280xp compatible string in the DT bindings and lMH support for QCom tsens driver (Bjorn Andersson) - Fix OTP Calibration Register values conforming to the documentation on RZ/G2L and bindings documentation for RZ/G2UL (Biju Das) - Fix type in kerneldoc description for __thermal_bind_params (Corentin Labbe) - Remove unneeded semi colon in libthermal and tools thermal as reported by cocci (Jiapeng Chong) - Fix potential NULL dereference in sr_thermal_probe() on Broadcom platform (Zheng Yongjun) - Add thermal library and thermal tools to encapsulate the netlink into event based callbacks (Daniel Lezcano) - Add change mode ops for the thermal-of sensor (Manaf Meethalavalappu Pallikunhi) - Fix non negative value support by preventing the value to be clamp to zero (Stefan Wahren) - Add compatible string and DT bindings for MSM8960 tsens driver (Dmitry Baryshkov) - Add hwmon support for K3 driver (Massimiliano Minella) - Refactor and add multiple generations support for QCom ADC driver (Jishnu Prakash) - Use platform_get_irq_optional() to get the interrupt on RCar driver and document Document RZ/V2L bindings (Lad Prabhakar) * tag 'thermal-v5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thermal/linux: (28 commits) thermal: k3_j72xx_bandgap: Add the bandgap driver support dt-bindings: thermal: k3-j72xx: Add VTM bindings documentation thermal/drivers/imx_sc_thermal: Fix refcount leak in imx_sc_thermal_probe thermal/core: Fix memory leak in __thermal_cooling_device_register() dt-bindings: thermal: tsens: Add sc8280xp compatible dt-bindings: thermal: lmh: Add Qualcomm sc8180x compatible thermal/drivers/qcom/lmh: Add sc8180x compatible thermal/drivers/rz2gl: Fix OTP Calibration Register values dt-bindings: thermal: rzg2l-thermal: Document RZ/G2UL bindings thermal: thermal_of: fix typo on __thermal_bind_params tools/thermal: remove unneeded semicolon tools/lib/thermal: remove unneeded semicolon thermal/drivers/broadcom: Fix potential NULL dereference in sr_thermal_probe tools/thermal: Add thermal daemon skeleton tools/thermal: Add a temperature capture tool tools/thermal: Add util library tools/lib/thermal: Add a thermal library thermal/drivers/thermal_of: Add change_mode ops support for thermal_of sensor thermal/drivers/bcm2711: Don't clamp temperature at zero thermal/drivers/tsens: Add compat string for the qcom,msm8960 ...
2022-05-19dmaengine: dw: Add RZN1 compatibleMiquel Raynal
The Renesas RZN1 DMA IP is very close to the original DW DMA IP, a DMA router has been introduced to handle the wiring options that have been added. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-By: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20220427095653.91804-8-miquel.raynal@bootlin.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19clk: renesas: r9a06g032: Probe possible childrenMiquel Raynal
The clock controller device on r9a06g032 takes all the memory range that is described as being a system controller. This range contains many different (unrelated?) registers besides the ones belonging to the clock controller, that can necessitate to be accessed from other peripherals. For instance, the dmamux registers are there. The dmamux "device" will be described as a child node of the clock/system controller node, which means we need the top device driver (the clock controller driver in this case) to populate its children manually. In case of error when populating the children, we do not fail the probe on purpose to keep the clk driver up and running. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Stephen Boyd <sboyd@kernel.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20220427095653.91804-7-miquel.raynal@bootlin.com Signed-off-by: Vinod Koul <vkoul@kernel.org>