- 04 Jan, 2024 2 commits
-
-
Naresh Solanki authored
Previously, the sequence number in the regulator event subsystem was updated without atomic operations, potentially leading to race conditions. This commit addresses the issue by making the sequence number atomic. Signed-off-by:
Naresh Solanki <naresh.solanki@9elements.com> Link: https://msgid.link/r/20240104141314.3337037-1-naresh.solanki@9elements.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
Naresh Solanki authored
Fix minor typo. Signed-off-by:
-
- 19 Dec, 2023 2 commits
-
-
Andy Shevchenko authored
REGULATOR_LINEAR_RANGE() repeats what LINEAR_RANGE() provides. Deduplicate the former by using the latter. No functional change intended. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://msgid.link/r/20231219154012.2478688-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Johan Hovold authored
Devicetree node names should be generic; fix up the qcom,usb-vbus-regulator binding example accordingly. While at it, drop an unnecessary label and add a newline separator before the child node to improve readability. Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Link: https://msgid.link/r/20231219075749.25308-1-johan+linaro@kernel.orgSigned-off-by:
-
- 18 Dec, 2023 1 commit
-
-
Varadarajan Narayanan authored
Add support for LDO5 regulator. This is used by IPQ9574 USB. Signed-off-by:
Varadarajan Narayanan <quic_varada@quicinc.com> Rule: <add> Link: https://lore.kernel.org/stable/20231214104052.3267039-1-quic_varada%40quicinc.com Link: https://msgid.link/r/20231214104052.3267039-1-quic_varada@quicinc.comSigned-off-by:
-
- 14 Dec, 2023 4 commits
-
-
Mark Brown authored
Merge series from Fenglin Wu <quic_fenglinw@quicinc.com>: There are 2 PM8010 PMICs present in sm8550-mtp/sm8550-qrd boards and each of them exposes 7 LDOs. Add RPMH regulator support for them. Signed-off-by:
Fenglin Wu <quic_fenglinw@quicinc.com> --- Changes in v2: - Updated subject prefix in the dt-binding commit and fixed the typo. - Separate the DTS commit with board name prefixes. - Link to v1: https://lore.kernel.org/r/20231211-pm8010-regulator-v1-0-571e05fb4ecc@quicinc.com --- Fenglin Wu (5): regulator: qcom-rpmh: extend to support multiple linear voltage ranges regulator: dt-bindings: qcom,rpmh: add compatible for pm8010 regulator: qcom-rpmh: add support for pm8010 regulators arm64: dts: qcom: sm8550-mtp: Add pm8010 regulators arm64: dts: qcom: sm8550-qrd: add PM8010 regulators .../bindings/regulator/qcom,rpmh-regulator.yaml | 14 ++ arch/arm64/boot/dts/qcom/sm8550-mtp.dts | 120 ++++++++++++++ arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 120 ++++++++++++++ drivers/regulator/qcom-rpmh-regulator.c | 177 ++++++++++++++++++--- 4 files changed, 405 insertions(+), 26 deletions(-) --- base-commit: 753e4d5c change-id: 20231205-pm8010-regulator-0348cb19087a Best regards, -- Fenglin Wu <quic_fenglinw@quicinc.com>
-
Fenglin Wu authored
Add RPMH regulators exposed by Qualcomm Technologies, Inc. PM8010 PMIC. It has 7 LDOs with 3 different types, LDO1 - LDO2 are L502 NMOS LDOs, LDO5 and LDO7 are L502 PMOS LDOs, LDO3/LDO4/LDO6 are L502 PMOS LDO for low noise applications. Also, LDO3 - LDO7 don't support LPM. Suggested-by:
David Collins <quic_collinsd@quicinc.com> Reviewed-by:
-
Fenglin Wu authored
Add compatible for PM8010 RPMH regulators present on sm8550-qrd and sm8550-mtp boards. Suggested-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Fenglin Wu authored
Update rpmh_vreg_hw_data to support multiple linear voltage ranges for potential regulators which have discrete voltage program ranges. Suggested-by:
-
- 11 Dec, 2023 9 commits
-
-
Mark Brown authored
Merge series from Uwe Kleine-König <u.kleine-koenig@pengutronix.de>: Hello, this series converts all drivers below drivers/regulator to struct platform_driver::remove_new(). See commit 5c5a7680 ("platform: Provide a remove callback that returns no value") for an extended explanation and the eventual goal. All conversations are trivial, because all .remove() callbacks returned zero unconditionally. There are no interdependencies between these patches, so they could be picked up individually. However I'd expect them to go in all together via Mark's regulator tree. Best regards Uwe Uwe Kleine-König (8): regulator: arizona-ldo1: Convert to platform remove callback returning void regulator: bd9571mwv: Convert to platform remove callback returning void regulator: db8500-prcmu: Convert to platform remove callback returning void regulator: stm32-vrefbuf: Convert to platform remove callback returning void regulator: uniphier: Convert to platform remove callback returning void regulator: userspace-consumer: Convert to platform remove callback returning void regulator: virtual: Convert to platform remove callback returning void regulator: wm8350: Convert to platform remove callback returning void drivers/regulator/arizona-ldo1.c | 8 +++----- drivers/regulator/bd9571mwv-regulator.c | 5 ++--- drivers/regulator/db8500-prcmu.c | 6 ++---- drivers/regulator/stm32-vrefbuf.c | 6 ++---- drivers/regulator/uniphier-regulator.c | 6 ++---- drivers/regulator/userspace-consumer.c | 6 ++---- drivers/regulator/virtual.c | 6 ++---- drivers/regulator/wm8350-regulator.c | 6 ++---- 8 files changed, 17 insertions(+), 32 deletions(-) base-commit: 0f5f12ac05f36f117e793656c3f560625e927f1b -- 2.42.0
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://msgid.link/r/1f7bbc545829a1cc3df40be0424fe46d7449fb72.1701778038.git.u.kleine-koenig@pengutronix.deAcked-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
- 06 Dec, 2023 2 commits
-
-
Naresh Solanki authored
This commit introduces netlink event support to the regulator subsystem. Changes: - Introduce event.c and regnl.h for netlink event handling. - Implement reg_generate_netlink_event to broadcast regulator events. - Update Makefile to include the new event.c file. Signed-off-by:
-
Naresh Solanki authored
This commit introduces netlink event support to the regulator subsystem. Changes: - Introduce event.c and regnl.h for netlink event handling. - Implement reg_generate_netlink_event to broadcast regulator events. - Update Makefile to include the new event.c file. Signed-off-by:
-
- 13 Nov, 2023 16 commits
-
-
Mark Brown authored
Merge series from Oleksij Rempel <o.rempel@pengutronix.de>: This series add under-voltage and emergency shutdown for system critical regulators
-
Mark Brown authored
Merge series from Dang Huynh <danct12@riseup.net>: PM8937 is a power management IC. It is used in various boards with MSM8917, MSM8937, MSM8940 and APQ variants.
-
Jiapeng Chong authored
No functional modification involved. drivers/regulator/stpmic1_regulator.c:31: warning: expecting prototype for struct stpmic1. Prototype was for struct stpmic1_regulator_cfg instead. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7206Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Link: https://lore.kernel.org/r/20231109073925.98783-1-jiapeng.chong@linux.alibaba.comSigned-off-by:
-
Colin Ian King authored
Pointer pdata is being initialized with a value that is never read. It is being re-assigned later on with the return from a devm_kzalloc call. Remove the redundant initialization, cleans up clang scan build warning: drivers/regulator/palmas-regulator.c:1597:36: warning: Value stored to 'pdata' during its initialization is never read [deadcode.DeadStores] Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20231111195330.338324-1-colin.i.king@gmail.comSigned-off-by:
-
Rui Zhang authored
The use_count of a regulator should only be incremented when the enable_count changes from 0 to 1. Similarly, the use_count should only be decremented when the enable_count changes from 1 to 0. In the previous implementation, use_count was sometimes decremented to 0 when some consumer called unbalanced disable, leading to unexpected disable even the regulator is enabled by other consumers. With this change, the use_count accurately reflects the number of users which the regulator is enabled. This should make things more robust in the case where a consumer does leak references. Signed-off-by:
Rui Zhang <zr.zhang@vivo.com> Link: https://lore.kernel.org/r/20231103074231.8031-1-zr.zhang@vivo.comSigned-off-by:
-
Javier Martinez Canillas authored
This may be useful for debugging and develompent purposes, when there are drivers that depend on regulators to be enabled but do not request them. It is inspired from the clk_ignore_unused and pd_ignore_unused parameters, that are used to keep firmware-enabled clocks and power domains on even if these are not used by drivers. The parameter is not expected to be used in normal cases and should not be needed on a platform with proper driver support. Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Brian Masney <bmasney@redhat.com> Acked-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20231107190926.1185326-1-javierm@redhat.comSigned-off-by:
-
Oleksij Rempel authored
Add 'uv_survival_time' field to regulation_constraints for specifying survival time post critical under-voltage event. Update the regulator notifier call chain and Device Tree property parsing to use this new field, allowing a configurable timeout before emergency shutdown. Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20231026144824.4065145-6-o.rempel@pengutronix.deSigned-off-by:
-
Oleksij Rempel authored
Introduces a new devicetree property to specifies the time window (in milliseconds) following a critical under-voltage (UV) event during which less critical actions can be safely carried out by the system. Less Critical Actions: - Logging the under-voltage event for later analysis. - Saving less critical data that may be useful for diagnosing issues or for audit purposes. More Critical Actions (post the less critical window): - Initiating procedures to properly shutdown hardware to prevent damage. The 'regulator-uv-less-critical-window-ms' property is crucial for conveying board-specific hardware characteristics, not for enforcing a certain policy. The time window represented by this property is derived from the physical attributes of the hardware like the capacity of on-board capacitors, the power consumption of the components, and the time needed to safely shut down hardware to prevent damage. These attributes can significantly vary between different boards, making it a board-specific property rather than a policy directive. By providing a precise representation of the time available for less critical actions post an under-voltage event, this property enables the kernel to make informed decisions on action prioritization, ensuring that essential preventative measures are taken to avoid hardware damage while also allowing for data capture and analysis. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231026144824.4065145-5-o.rempel@pengutronix.deSigned-off-by:
-
Oleksij Rempel authored
In certain projects, the main system regulator, composed of simple components including an under-voltage detector and capacitors, can be aptly described as a fixed regulator in the device tree. To cater to such use cases, this patch extends the fixed regulator binding to support the 'system-critical-regulator' property. This property signifies that the fixed-regulator is vital for system stability. Signed-off-by:
-
Oleksij Rempel authored
Handle under-voltage events for crucial regulators to maintain system stability and avoid issues during power drops. Signed-off-by:
-
Oleksij Rempel authored
Introduce a new Device Tree property 'system-critical-regulator' for marking a regulator as crucial for system stability or functionality. This helps in distinguishing regulators that are vital for system operations and may require special handling in under-voltage scenarios. Signed-off-by:
-
Dang Huynh authored
Document the pm8937 compatible string and available regulators in the QCOM SMD RPM regulator documentation. Signed-off-by:
Dang Huynh <danct12@riseup.net> Reviewed-by:
-
Dang Huynh authored
The PM8937 is found on boards with MSM8917, MSM8937, MSM8940 SoCs and APQ variants. It provides 6 SMPS (two are controlled by SPMI) and 23 LDO regulators. Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20231106-pm8937-v1-5-ec51d9eeec53@riseup.netSigned-off-by:
-
Dang Huynh authored
Add support for qcom,pm8937-regulators compatible string and add relevant supplies in QCOM's SPMI regulator documentation. Signed-off-by:
-
Dang Huynh authored
The PM8937 has 4 HFSMPS, 2 FTSMPS2.5 (for controlling APC voltage) and 23 LDO regulators. Add the configuration for this chip. Signed-off-by:
-
Linus Torvalds authored
-
- 12 Nov, 2023 4 commits
-
-
Miri Korenblit authored
The commands should be sorted inside the group definition. Fix the ordering so we won't get following warning: WARN_ON(iwl_cmd_groups_verify_sorted(trans_cfg)) Link: https://lore.kernel.org/regressions/2fa930bb-54dd-4942-a88d-05a47c8e9731@gmail.com/ Link: https://lore.kernel.org/linux-wireless/CAHk-=wix6kqQ5vHZXjOPpZBfM7mMm9bBZxi2Jh7XnaKCqVf94w@mail.gmail.com/ Fixes: b6e3d1ba ("wifi: iwlwifi: mvm: implement new firmware API for statistics") Tested-by:
Niklāvs Koļesņikovs <pinkflames.linux@gmail.com> Tested-by:
Damian Tometzki <damian@riscv-rocks.de> Acked-by:
Kalle Valo <kvalo@kernel.org> Signed-off-by:
Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
Merge tag 'parisc-for-6.7-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc architecture fixes from Helge Deller: - Include the upper 5 address bits when inserting TLB entries on a 64-bit kernel. On physical machines those are ignored, but in qemu it's nice to have them included and to be correct. - Stop the 64-bit kernel and show a warning if someone tries to boot on a machine with a 32-bit CPU - Fix a "no previous prototype" warning in parport-gsc * tag 'parisc-for-6.7-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Prevent booting 64-bit kernels on PA1.x machines parport: gsc: mark init function static parisc/pgtable: Do not drop upper 5 address bits of physical address
-
Linus Torvalds authored
Merge tag 'loongarch-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson Pull LoongArch updates from Huacai Chen: - support PREEMPT_DYNAMIC with static keys - relax memory ordering for atomic operations - support BPF CPU v4 instructions for LoongArch - some build and runtime warning fixes * tag 'loongarch-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson: selftests/bpf: Enable cpu v4 tests for LoongArch LoongArch: BPF: Support signed mod instructions LoongArch: BPF: Support signed div instructions LoongArch: BPF: Support 32-bit offset jmp instructions LoongArch: BPF: Support unconditional bswap instructions LoongArch: BPF: Support sign-extension mov instructions LoongArch: BPF: Support sign-extension load instructions LoongArch: Add more instruction opcodes and emit_* helpers LoongArch/smp: Call rcutree_report_cpu_starting() earlier LoongArch: Relax memory ordering for atomic operations LoongArch: Mark __percpu functions as always inline LoongArch: Disable module from accessing external data directly LoongArch: Support PREEMPT_DYNAMIC with static keys
-
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linuxLinus Torvalds authored
Pull powerpc fixes from Michael Ellerman: - Finish a refactor of pgprot_framebuffer() which dependend on some changes that were merged via the drm tree - Fix some kernel-doc warnings to quieten the bots Thanks to Nathan Lynch and Thomas Zimmermann. * tag 'powerpc-6.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/rtas: Fix ppc_rtas_rmo_buf_show() kernel-doc powerpc/pseries/rtas-work-area: Fix rtas_work_area_reserve_arena() kernel-doc powerpc/fb: Call internal __phys_mem_access_prot() in fbdev code powerpc: Remove file parameter from phys_mem_access_prot() powerpc/machdep: Remove trailing whitespaces
-
