summaryrefslogtreecommitdiff
path: root/drivers/regulator
AgeCommit message (Collapse)Author
2022-08-23PM6125 regulator supportMark Brown
Merge series from Iskren Chernev <iskren.chernev@gmail.com>: This patch series adds SPMI and SMD regulator support for the PM6125 found on SM4250/SM6115 SoCs from QCom. This code has been tested on: * OnePlus Nord N100 (oneplus,billie2, SoC sm4250) * Redmi 9T (redmi,lemon, SoC sm6115) The main source used for this change is qpnp pm6125 support patch from caf [1]: [1]: https://source.codeaurora.org/quic/la/kernel/msm-5.4/commit/?h=kernel.lnx.5.4.r1-rel&id=d1220daeffaa440ffff0a8c47322eb0033bf54f5 v3: https://lkml.org/lkml/2022/7/31/303 v2: https://lkml.org/lkml/2022/7/26/885 v1: https://lkml.org/lkml/2021/8/28/144 Changes from v3: - fix compilation issue reported by kernel test robot - reorder HFSMPS/LDO+FTSMPS patches - add new slew-rate computation for HFSMPS - add proper pull-down support for new regs - name new regs/vals after HFSMPS instead of FTSMPS - address indentation/newline issues reported by Krzysztof - improve commit messages on SPMI/RPM related patches Changes from v2: - split spmi new regulator support in 2 patches - FTS and LDOs now have set_load and set_pull_down ops - add better commit messages on spmi patches - fix sob header order - fix tested device info (Redmi 9T, NOT Xiaomi 9T) - improve formatting in spmi binding docs - sort alphabetically in smd binding docs - sort alphabetically spmi pmics - sort alphabetically smd pmics Changes from v1: - add dt-bindings - split SPMI patch into new reg types and the new PMIC - add correct supply mapping Iskren Chernev (13): dt-bindings: regulator: qcom_spmi: Improve formatting of if-then blocks dt-bindings: regulator: qcom_spmi: Document PM6125 PMIC dt-bindings: regulator: qcom_smd: Sort compatibles alphabetically dt-bindings: regulator: qcom_smd: Document PM6125 PMIC regulator: qcom_spmi: Add support for HFSMPS regulator type regulator: qcom_spmi: Add support for LDO_510 and FTSMPS regulator: qcom_spmi: Sort pmics alphabetically (part 1) regulator: qcom_spmi: Sort pmics alphabetically (part 2) regulator: qcom_spmi: Add PM6125 PMIC support regulator: qcom_smd: Sort pmics alphabetically (part 1) regulator: qcom_smd: Sort pmics alphabetically (part 2) regulator: qcom_smd: Sort pmics alphabetically (part 3) regulator: qcom_smd: Add PM6125 RPM regulators .../regulator/qcom,smd-rpm-regulator.yaml | 26 +- .../regulator/qcom,spmi-regulator.yaml | 32 ++ drivers/regulator/qcom_smd-regulator.c | 400 ++++++++++-------- drivers/regulator/qcom_spmi-regulator.c | 378 ++++++++++++----- 4 files changed, 551 insertions(+), 285 deletions(-) -- 2.37.1
2022-08-23regulator: drivers: Add TI TPS65219 PMIC regulators supportJerome Neanne
The regulators set consists of 3 bucks DCDCs and 4 LDOs. The output voltages are configurable and are meant to supply power to the main processor and other components. Validation: Visual check: cat /sys/kernel/debug/regulator/regulator_summary Validation: userspace-consumer and virtual-regulator required to test further Enable/Disable: cat /sys/devices/platform/userspace-consumer-VDDSHV_SD_IO_PMIC/state echo disabled > /sys/devices/platform/ userspace-consumer-VDDSHV_SD_IO_PMIC/state echo enabled > /sys/devices/platform/ userspace-consumer-VDDSHV_SD_IO_PMIC/state Change voltage: cat /sys/devices/platform/regulator-virtual-ldo1/min_microvolts echo 1000000 > /sys/devices/platform/regulator-virtual-ldo1/ min_microvolts echo 3000000 > /sys/devices/platform/regulator-virtual-ldo1/ max_microvolts Signed-off-by: Jerome Neanne <jneanne@baylibre.com> Link: https://lore.kernel.org/r/20220805121852.21254-9-jneanne@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-23regulator: qcom_smd: Add PM6125 RPM regulatorsIskren Chernev
The ranges and types are taken from the relevant SPMI driver: - ftsmps_510: s1-s4, s8 - buck_510: s5-s7 - ldo_nX_510: l1-l4, l6-l8, l17-18 - ldo_mv_pX_510: l5, l15, l19-l24 - ldo_lv_pX_510: l9-l14, l16 Signed-off-by: Adam Skladowski <a39.skl@gmail.com> Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20220802221112.2280686-14-iskren.chernev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-23regulator: qcom_smd: Sort pmics alphabetically (part 3)Iskren Chernev
The sorting is split in multiple commits for easier reviewing. Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20220802221112.2280686-13-iskren.chernev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-23regulator: qcom_smd: Sort pmics alphabetically (part 2)Iskren Chernev
The sorting is split in multiple commits for easier reviewing. Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20220802221112.2280686-12-iskren.chernev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-23regulator: qcom_smd: Sort pmics alphabetically (part 1)Iskren Chernev
The sorting is split in multiple commits for easier reviewing. Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20220802221112.2280686-11-iskren.chernev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-23regulator: qcom_spmi: Add PM6125 PMIC supportIskren Chernev
Add support for PM6125 PMIC which is found on SM4250/6115 SoCs. S1, S2, S3, S4, S8 are FTS+FTSMPS_510, rev 2 - range is 0.3-1.372V by 4mV increments S5, S6, s7 are BUCK+HFSMPS_510, rev 4 - range is 0.32-2.04V by 8mV increment L1, L3, L7 are LDO+N600_510, rev 2 L2, L4, L8, L17, L18 are LDO+N300_510, rev 2 L6 is LDO+N1200_510, rev 2 - range is 0.32-1.304V by 8mV increment L5 is LDO+MV_P50_510, rev 2 L15, L19, L20 are LDO+MV_P150_510, rev 2 L21, L22, L23, L24 are LDO+MV_P600_510, rev 2 - range is 1.504-3.544V by 8mV increment L9, L11, L14 are LDO+LV_P600_510, rev 2 L10, L16 are LDO+LV_P150_510, rev 2 L12, L13 are LDO+LV_P300_510, rev 2 - range 1.504-2V by 8mV increment Signed-off-by: Adam Skladowski <a39.skl@gmail.com> Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20220802221112.2280686-10-iskren.chernev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-23regulator: qcom_spmi: Sort pmics alphabetically (part 2)Iskren Chernev
The sorting is split in multiple commits for easier reviewing. Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20220802221112.2280686-9-iskren.chernev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-23regulator: qcom_spmi: Sort pmics alphabetically (part 1)Iskren Chernev
The sorting is split in multiple commits for easier reviewing. Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20220802221112.2280686-8-iskren.chernev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-23regulator: qcom_spmi: Add support for LDO_510 and FTSMPSIskren Chernev
Add support for LDO_510 and FTSMPS3 regulators, all belonging to register layout HFSMPS. This is done in preparation for adding support for the PM6125 PMIC. For FTSMPS3 and LDO_510, only IDLE and NORMAL modes are selectable (no FAST). The inspiration for the magic constants was taken from [1] [1]: https://source.codeaurora.org/quic/la/kernel/msm-5.4/commit/?h=kernel.lnx.5.4.r1-rel&id=d1220daeffaa440ffff0a8c47322eb0033bf54f5 Signed-off-by: Adam Skladowski <a39.skl@gmail.com> Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20220802221112.2280686-7-iskren.chernev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-23regulator: qcom_spmi: Add support for HFSMPS regulator typeIskren Chernev
This is preparation for supporing PM6125. The HFSMPS is a BUCK type regulator with subtype 0x0a, same as the existing HFS430 regulator. Even though the HFSMPS and HFS430 share a type and subtype, the HFSMPS has an updated register map, including different mode values, moved pull down register, and different slew rate address and formula. In addition to NORMAL (NPM), FAST (AUTO_LPM) and IDLE (LPM), the regulator also supports RETENTION and AUTO_RM which are currently unselectable by the driver. The inspiration of this is taken from [1]. [1] https://source.codeaurora.org/quic/la/kernel/msm-5.4/commit/?h=kernel.lnx.5.4.r1-rel&id=d1220daeffaa440ffff0a8c47322eb0033bf54f5 Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20220802221112.2280686-6-iskren.chernev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-22regulator: core: Remove "ramp_delay not set" debug messageChristian Kohlschütter
This message shows up occasionally but in bursts (seen up to 30 times per second on my ODROID N2+). According to Matthias Kaehlcke's comment in 'regulator: core: silence warning: "VDD1: ramp_delay not set"', this message should have been removed after restructuring previous code that assumed that ramp_delay being zero in that function was an error. Link: https://lore.kernel.org/lkml/625675256c0d75805f088b4be17a3308dc1b7ea4.1477571498.git.hns@goldelico.com/T/ Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com> Link: https://lore.kernel.org/r/20220820131420.16608-1-christian@kohlschutter.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-22regulator: core: Clean up on enable failureAndrew Halaney
If regulator_enable() fails, enable_count is incremented still. A consumer, assuming no matching regulator_disable() is necessary on failure, will then get this error message upon regulator_put() since enable_count is non-zero: [ 1.277418] WARNING: CPU: 3 PID: 1 at drivers/regulator/core.c:2304 _regulator_put.part.0+0x168/0x170 The consumer could try to fix this in their driver by cleaning up on error from regulator_enable() (i.e. call regulator_disable()), but that results in the following since regulator_enable() failed and didn't increment user_count: [ 1.258112] unbalanced disables for vreg_l17c [ 1.262606] WARNING: CPU: 4 PID: 1 at drivers/regulator/core.c:2899 _regulator_disable+0xd4/0x190 Fix this by decrementing enable_count upon failure to enable. With this in place, just the reason for failure to enable is printed as expected and developers can focus on the root cause of their issue instead of thinking their usage of the regulator consumer api is incorrect. For example, in my case: [ 1.240426] vreg_l17c: invalid input voltage found Fixes: 5451781dadf8 ("regulator: core: Only count load for enabled consumers") Signed-off-by: Andrew Halaney <ahalaney@redhat.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Brian Masney <bmasney@redhat.com> Link: https://lore.kernel.org/r/20220819194336.382740-1-ahalaney@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-18regulator: core: Resolve supply name earlier to prevent double-initChristian Kohlschütter
Previously, an unresolved regulator supply reference upon calling regulator_register on an always-on or boot-on regulator caused set_machine_constraints to be called twice. This in turn may initialize the regulator twice, leading to voltage glitches that are timing-dependent. A simple, unrelated configuration change may be enough to hide this problem, only to be surfaced by chance. One such example is the SD-Card voltage regulator in a NanoPI R4S that would not initialize reliably unless the registration flow was just complex enough to allow the regulator to properly reset between calls. Fix this by re-arranging regulator_register, trying resolve the regulator's supply early enough that set_machine_constraints does not need to be called twice. Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com> Link: https://lore.kernel.org/r/20220818124646.6005-1-christian@kohlschutter.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-18Devm helpers for regulator get and enableMark Brown
Merge series from Matti Vaittinen <mazziesaccount@gmail.com>: A few* drivers seem to use pattern demonstrated by pseudocode: - devm_regulator_get() - regulator_enable() - devm_add_action_or_reset(regulator_disable()) Introducing devm helpers for this pattern would remove bunch of code from drivers. Typically following: - replace 3 calls (devm_regulator_get[_optional](), regulator_enable(), devm_add_action_or_reset()) with just one (devm_regulator_get_enable[_optional]()). - drop disable callback. - remove stored pointer to struct regulator - which can lead to problem when an devm action for regulator_disable is used. I believe this simplifies things by removing some dublicated code. The suggested managed 'get_enable' APIs do not return the pointer to regulators for user because any call to regulator_disable() (or regulator_enable()) may easily lead to regulator enable count imbalance upon device detach. (Eg, if someone calls regulator_disable() and the device is then detached before user has re-enabled the regulator). Not returning the pointer to obtained regulator to caller is a good hint that the enable/disable should not be manually handled when these APIs are used. OTOH, not returning the pointer reduces the use-cases by not allowing the consumers to perform other regulator actions. For example request the voltages. A few drivers which used the "get, enable, devm_action_to_disable" did also query the voltages. The API does not suit needs of such users.
2022-08-18regulator: Add devm helpers for get and enableMatti Vaittinen
A few regulator consumer drivers seem to be just getting a regulator, enabling it and registering a devm-action to disable the regulator at the driver detach and then forget about it. We can simplify this a bit by adding a devm-helper for this pattern. Add devm_regulator_get_enable() and devm_regulator_get_enable_optional() Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/ed7b8841193bb9749d426f3cb3b199c9460794cd.1660292316.git.mazziesaccount@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-17regulator/drivers/max8976: Switch to new of thermal APIDaniel Lezcano
The thermal OF code has a new API allowing to migrate the OF initialization to a simpler approach. The ops are no longer device tree specific and are the generic ones provided by the core code. Convert the ops to the thermal_zone_device_ops format and use the new API to register the thermal zone with these generic ops. Signed-off-by: Daniel Lezcano <daniel.lezcano@linexp.org> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220804224349.1926752-31-daniel.lezcano@linexp.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-08-16Merge tag 'regulator-fix-v6.0-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fixes from Mark Brown: "A couple of small fixes that came in since my pull request, nothing major here" * tag 'regulator-fix-v6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: core: Fix missing error return from regulator_bulk_get() regulator: pca9450: Remove restrictions for regulator-name
2022-08-16i2c: Make remove callback return voidUwe Kleine-König
The value returned by an i2c driver's remove function is mostly ignored. (Only an error message is printed if the value is non-zero that the error is ignored.) So change the prototype of the remove function to return no value. This way driver authors are not tempted to assume that passing an error to the upper layer is a good idea. All drivers are adapted accordingly. There is no intended change of behaviour, all callbacks were prepared to return 0 before. Reviewed-by: Peter Senna Tschudin <peter.senna@gmail.com> Reviewed-by: Jeremy Kerr <jk@codeconstruct.com.au> Reviewed-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Crt Mori <cmo@melexis.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Marek Behún <kabel@kernel.org> # for leds-turris-omnia Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Petr Machata <petrm@nvidia.com> # for mlxsw Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> # for surface3_power Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> # for bmc150-accel-i2c + kxcjk-1013 Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> # for media/* + staging/media/* Acked-by: Miguel Ojeda <ojeda@kernel.org> # for auxdisplay/ht16k33 + auxdisplay/lcd2s Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # for versaclock5 Reviewed-by: Ajay Gupta <ajayg@nvidia.com> # for ucsi_ccg Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # for iio Acked-by: Peter Rosin <peda@axentia.se> # for i2c-mux-*, max9860 Acked-by: Adrien Grassein <adrien.grassein@gmail.com> # for lontium-lt8912b Reviewed-by: Jean Delvare <jdelvare@suse.de> # for hwmon, i2c-core and i2c/muxes Acked-by: Corey Minyard <cminyard@mvista.com> # for IPMI Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> # for drivers/power Acked-by: Krzysztof Hałasa <khalasa@piap.pl> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-08-15regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()Douglas Anderson
Since we don't actually pass the load to the firmware, switch to using get_optimum_mode() instead of open-coding it. This is intended to have no effect other than cleanup. Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20220726102024.1.Icc838fe7bf0ef54a014ab2fee8af311654f5342a@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-15Merge remote-tracking branch 'regulator/for-5.20' into regulator-6.0Mark Brown
2022-08-10regulator: core: Fix missing error return from regulator_bulk_get()Douglas Anderson
In commit 6eabfc018e8d ("regulator: core: Allow specifying an initial load w/ the bulk API") I changed the error handling but had a subtle that caused us to always return no error even if there was an error. Fix it. Fixes: 6eabfc018e8d ("regulator: core: Allow specifying an initial load w/ the bulk API") Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20220809142738.1.I91625242f137c707bb345c51c80c5ecee02eeff3@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-04Merge tag 'tag-chrome-platform-for-v5.20' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux Pull chrome platform updates from Tzung-Bi Shih: "cros_ec_proto: - Leverage Kunit and add Kunit test cases - Clean-ups - Fix typo cros_ec_commands: - Fix typo - Fix compile errors cros_kbd_led_backlight: - Support OF match - Support EC PWM backend cros_ec: - Always expose the last resume result to fix sleep hang detection on ARM-based chromebooks wilco_ec: - Fix typo cros_ec_typec: - Clean-ups - Use Type-C framework utilities to manage altmode structs" * tag 'tag-chrome-platform-for-v5.20' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux: (59 commits) platform/chrome: cros_kunit_util: add default value for `msg->result` platform/chrome: merge Kunit utils and test cases platform/chrome: cros_kbd_led_backlight: fix build warning platform/chrome: cros_ec_proto: add Kunit test for cros_ec_cmd() platform/chrome: cros_ec_proto: add Kunit tests for get_sensor_count platform/chrome: cros_ec_proto: add Kunit tests for check_features platform/chrome: cros_ec_proto: add Kunit tests for get_host_event platform/chrome: cros_ec_proto: add Kunit tests for get_next_event platform/chrome: cros_ec_proto: add Kunit test for cros_ec_map_error() platform/chrome: cros_ec_proto: add Kunit tests for cmd_xfer_status platform/chrome: cros_ec_proto: return -EPROTO if empty payload platform/chrome: cros_ec_proto: add Kunit test for empty payload platform/chrome: cros_ec_proto: return -EAGAIN when retries timed out platform/chrome: cros_ec_proto: change Kunit expectation when timed out platform/chrome: cros_ec_proto: separate cros_ec_wait_until_complete() platform/chrome: cros_ec_proto: separate cros_ec_xfer_command() platform/chrome: cros_ec_proto: add Kunit tests for cros_ec_send_command() platform/chrome: cros_ec_proto: add Kunit tests for cros_ec_cmd_xfer() platform/chrome: cros_ec_proto: add "cros_ec_" prefix to send_command() platform/chrome: cros_ec_typec: Register port altmodes ...
2022-08-04Merge tag 'spdx-6.0-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx Pull SPDX updates from Greg KH: "Here is the set of SPDX comment updates for 6.0-rc1. Nothing huge here, just a number of updated SPDX license tags and cleanups based on the review of a number of common patterns in GPLv2 boilerplate text. Also included in here are a few other minor updates, two USB files, and one Documentation file update to get the SPDX lines correct. All of these have been in the linux-next tree for a very long time" * tag 'spdx-6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx: (28 commits) Documentation: samsung-s3c24xx: Add blank line after SPDX directive x86/crypto: Remove stray comment terminator treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_406.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_398.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_391.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_390.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_385.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_320.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_319.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_318.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_298.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_292.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_179.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_168.RULE (part 2) treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_168.RULE (part 1) treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_160.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_152.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_149.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_147.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_133.RULE ...
2022-07-28regulator: Consumer load management improvementsMark Brown
Merge series from Douglas Anderson <dianders@chromium.org>: The main goal of this series is to make a small dent in cleaning up the way we deal with regulator loads. The idea is to add some extra functionality to the regulator "bulk" API so that consumers can specify the load using that.
2022-07-27regulator: core: Allow drivers to define their init data as constDouglas Anderson
Drivers tend to want to define the names of their regulators somewhere in their source file as "static const". This means, inevitable, that every driver out there open codes something like this: static const char * const supply_names[] = { "vcc", "vccl", }; static int get_regulators(struct my_data *data) { int i; data->supplies = devm_kzalloc(...) if (!data->supplies) return -ENOMEM; for (i = 0; i < ARRAY_SIZE(supply_names); i++) data->supplies[i].supply = supply_names[i]; return devm_regulator_bulk_get(data->dev, ARRAY_SIZE(supply_names), data->supplies); } Let's make this more convenient by doing providing a helper that does the copy. I have chosen to have the "const" input structure here be the exact same structure as the normal one passed to devm_regulator_bulk_get(). This is slightly inefficent since the input data can't possibly have anything useful for "ret" or consumer and thus we waste 8 bytes per structure. This seems an OK tradeoff for not introducing an extra structure. Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20220726103631.v2.6.I38fc508a73135a5c1b873851f3553ff2a3a625f5@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-27regulator: core: Allow specifying an initial load w/ the bulk APIDouglas Anderson
There are a number of drivers that follow a pattern that looks like this: 1. Use the regulator bulk API to get a bunch of regulators. 2. Set the load on each of the regulators to use whenever the regulators are enabled. Let's make this easier by just allowing the drivers to pass the load in. As part of this change we need to move the error printing in regulator_bulk_get() around; let's switch to the new dev_err_probe() to simplify it. Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20220726103631.v2.4.Ie85f68215ada39f502a96dcb8a1f3ad977e3f68a@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-27regulator: mt6380: Fix unused array warningJean Delvare
With the following configuration options: CONFIG_OF is not set CONFIG_REGULATOR_MT6380=y we get the following build warning: CC drivers/regulator/mt6380-regulator.o drivers/regulator/mt6380-regulator.c:322:34: warning: ‘mt6380_of_match’ defined but not used [-Wunused-const-variable=] Fix this by annotating that array with __maybe_unused, as done in various regulator drivers. Signed-off-by: Jean Delvare <jdelvare@suse.de> Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/all/202207240252.ZY5hSCNB-lkp@intel.com/ Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Chenglin Xu <chenglin.xu@mediatek.com> Link: https://lore.kernel.org/r/20220727132637.76d6073f@endymion.delvare Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-19regulator: core: Fix off-on-delay-us for always-on/boot-on regulatorsChristian Kohlschütter
Regulators marked with "regulator-always-on" or "regulator-boot-on" as well as an "off-on-delay-us", may run into cycling issues that are hard to detect. This is caused by the "last_off" state not being initialized in this case. Fix the "last_off" initialization by setting it to the current kernel time upon initialization, regardless of always_on/boot_on state. Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com> Link: https://lore.kernel.org/r/FAFD5B39-E9C4-47C7-ACF1-2A04CD59758D@kohlschutter.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-15regulator: of: Fix refcount leak bug in of_get_regulation_constraints()Liang He
We should call the of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount. Fixes: 40e20d68bb3f ("regulator: of: Add support for parsing regulator_state for suspend state") Signed-off-by: Liang He <windhl@126.com> Link: https://lore.kernel.org/r/20220715111027.391032-1-windhl@126.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-14regulator: max597x: Don't return uninitialized variable in .probeAxel Lin
Remove the code checking and returning uninitialized variable. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20220714101212.502824-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-11regulator: qcom_spmi: add support for PMP8074 regulatorsRobert Marko
PMP8074 is a companion PMIC for the Qualcomm IPQ8074 WiSoC-s. It features 5 HF-SMPS and 13 LDO regulators. HF-SMPS regulators are Buck HFS430 regulators. L1, L2 and L3 are HT_N1200_ST subtype LDO regulators. L4 is HT_N300_ST subtype LDO regulator. L5 and L6 are HT_P600 subtype LDO regulators. L7, L11, L12 and L13 are HT_P150 subtype LDO regulators. L10 is HT_P50 subtype LDO regulator. This commit adds support for all of the buck regulators and LDO-s except for L10 as I dont have documentation on its output voltage range. S3 is the CPU cluster voltage supply, S4 supplies the UBI32 NPU cores and L11 is the SDIO/eMMC I/O voltage regulator required for high speeds. Signed-off-by: Robert Marko <robimarko@gmail.com> Link: https://lore.kernel.org/r/20220704212402.1715182-7-robimarko@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-11regulator: qcom_spmi: add support for HT_P600Robert Marko
HT_P600 is a LDO PMOS regulator based on LV P600 using HFS430 layout found in PMP8074 and PMS405 PMIC-s. Both PMP8074 and PMS405 define the programmable range as 1.704 to 1.896V but the actual MAX output voltage depends on the exact LDO in each of the PMIC-s. Their usual voltage that they are used is 1.8V. It has a max current of 600mA, voltage step of 8mV. Signed-off-by: Robert Marko <robimarko@gmail.com> Link: https://lore.kernel.org/r/20220704212402.1715182-5-robimarko@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-11regulator: qcom_spmi: add support for HT_P150Robert Marko
HT_P150 is a LDO PMOS regulator based on LV P150 using HFS430 layout found in PMP8074 and PMS405 PMIC-s. Both PMP8074 and PMS405 define the programmable range as 1.616V to 3.304V but the actual MAX output voltage depends on the exact LDO in each of the PMIC-s. It has a max current of 150mA, voltage step of 8mV. Signed-off-by: Robert Marko <robimarko@gmail.com> Link: https://lore.kernel.org/r/20220704212402.1715182-4-robimarko@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-11regulator: max597x: Remove unused including <linux/version.h>Jiapeng Chong
The patch makes sense but these are not compile warnings. They come from scripts/checkversion.pl, which can be called by 'make versioncheck', so I suppose that something in your build system is running 'make versioncheck'. Eliminate the follow versioncheck warning: ./drivers/regulator/max597x-regulator.c: 21 linux/version.h not needed. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Link: https://lore.kernel.org/r/20220711034011.46096-1-jiapeng.chong@linux.alibaba.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-07regulator: Fix MFD_MAX597X dependencyMark Brown
Drivers should depend on rather than select their MFDs. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220707111753.16581-1-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-05regulator: Fix parameter declaration and spelling mistake.Zhang Jiaming
Use Complete data type declaration of 'sel' in ti_abb_set_voltage_sel(). Fix spelling of 'are'nt' in comments. Signed-off-by: Zhang Jiaming <jiaming@nfschina.com> Link: https://lore.kernel.org/r/20220705071445.21124-1-jiaming@nfschina.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-05regulator: max597x: Add support for max597x regulatorPatrick Rudolph
max597x is hot swap controller. This regulator driver controls the same & also configures fault protection features supported by the chip. Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Marcello Sylvester Bauer <sylv@sylv.io> Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com> Link: https://lore.kernel.org/r/20220705122244.472894-4-Naresh.Solanki@9elements.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-30regulator: qcom_smd: Add PM8909 and fix pm8916_pldo rangeMark Brown
Merge series from Stephan Gerhold <stephan.gerhold@kernkonzept.com>: Fix the voltage range for the pm8916_pldo in the qcom_smd-regulator driver and add definitions for the regulators available in PM8909.
2022-06-30regulator: scmi: Add missing of_node_get()Liang He
In scmi_regulator_probe(), of_find_node_by_name() will decrease the refcount of its first argument and we need a of_node_get() to keep reference balance. Signed-off-by: Liang He <windhl@126.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20220622034816.4094043-1-windhl@126.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-29regulator: qcom_smd: Add PM8909 RPM regulatorsStephan Gerhold
The set of regulators available in the PM8909 PMIC is similar to PM8916 which is already supported by the driver. s3, s4 and l16 are missing. However, probing the SPMI hardware identification registers using the qcom_spmi-regulator driver reveals that the regulators in PM8909 are actually some kind of mixture between PM8916 and PM8226: - ult_lo_smps (= pm8916_buck_lvo_smps): s1 - ult_ho_smps (= pm8916_buck_hvo_smps): s2 - ult_nldo (= pm8916_nldo): l1, l2, l3, l10 - ult_pldo (= pm8916_pldo): l4, l8, l9, l12-l15, l17, l18 - pldo (= pm8226_pldo): l5, l6, l7, l11 Use this mapping to add the rpm_regulator_data for PM8909 by reusing the existing regulator definitions. Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com> Link: https://lore.kernel.org/r/20220623094614.1410180-4-stephan.gerhold@kernkonzept.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-29regulator: qcom_smd: Fix pm8916_pldo rangeStephan Gerhold
The PM8916 device specification [1] documents a programmable range of 1.75V to 3.337V with 12.5mV steps for the PMOS LDOs in PM8916. This range is also used when controlling the regulator directly using the qcom_spmi-regulator driver ("ult_pldo" there). However, for some reason the qcom_smd-regulator driver allows a much larger range for the same hardware component. This could be simply a typo, since the start of the range is essentially just missing a '1'. In practice this does not cause any major problems, since the driver just sends the actual voltage to the RPM firmware instead of making use of the incorrect voltage selector. Still, having the wrong range there is confusing and prevents the regulator core from validating requests correctly. [1]: https://developer.qualcomm.com/download/sd410/pm8916pm8916-1-power-management-ic-device-specification.pdf Fixes: 57d6567680ed ("regulator: qcom-smd: Add PM8916 support") Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com> Link: https://lore.kernel.org/r/20220623094614.1410180-2-stephan.gerhold@kernkonzept.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-29regulator: mt6370: Use the correct header for platform_device_idChiYuan Huang
'platform_device_id' struct is defined in 'mod_devicetable.h'. Even 'of.h' also includes this header usage. The 'of.h' cannot be removed due to 'of_match_ptr' function. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/1656466861-7737-2-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-29regulator: mt6370: Use 'fwnode_gpiod_get_index' to fix gpio parsingChiYuan Huang
From the common binding, 'enable-gpio' or 'enable-gpios' are all well for external 'enable' gpio. 'gpiod_get_from_of_node' only parse the 'enable' property, it need to add the gpio suffix. It's more convenient to use fwnode_gpiod_get_index. Although fwnode parsing is not preferred, but 'of_parse_cb' already can guarantee the callback will only be used by regulator of_node parsing. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1656466861-7737-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-23regulator: mt6370: Add mt6370 DisplayBias and VibLDO supportChiYuan Huang
Add mt6370 DisplayBias and VibLDO support. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/20220623115631.22209-10-peterwu.pub@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-23regulator: rt5120: Add PMIC regulator supportChiYuan Huang
Add RT5120 PMIC regulator support. It integrates 4 buck convertes, 1 LDO voltage regulator, 1 external enable signal to control the external power source. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1655892104-10874-4-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-13regulator: rpi-panel-attiny: Use backlight helperStephen Kitt
backlight_properties.fb_blank is deprecated. The states it represents are handled by other properties; but instead of accessing those properties directly, drivers should use the helpers provided by backlight.h. Instead of retrieving the backlight brightness in struct backlight_properties manually, and then checking whether the backlight should be on at all, use backlight_get_brightness() which does all this and insulates this from future changes. Signed-off-by: Stephen Kitt <steve@sk2.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220607185304.1128962-1-steve@sk2.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-10treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_320.RULEThomas Gleixner
Based on the normalized pattern: this program is free software you can redistribute it and/or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is distributed as is without any warranty of any kind whether express or implied without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference. Reviewed-by: Allison Randal <allison@lohutok.net> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-10treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_319.RULEThomas Gleixner
Based on the normalized pattern: this program is free software you can redistribute it and/or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is distributed as is without any warranty of any kind whether expressed or implied without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license version 2 for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference. Reviewed-by: Allison Randal <allison@lohutok.net> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-10treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_318.RULEThomas Gleixner
Based on the normalized pattern: this program is free software you can redistribute it and/or modify it under the terms of the gnu general public license as published by the free software foundation version 2 this program is distributed as is without any warranty of any kind whether express or implied without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 59 temple place suite 330 boston ma 02111-1307 usa extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference. Reviewed-by: Allison Randal <allison@lohutok.net> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-04 05:03:07 +0000