summaryrefslogtreecommitdiff
path: root/drivers/regulator
AgeCommit message (Collapse)AuthorFilesLines
2022-12-02regulator: twl6030: re-add TWL6032_SUBCLASSAndreas Kemnade1-0/+2
[ Upstream commit 3d6c982b26db94cc21bc9f7784f63e8286b7be62 ] In former times, info->feature was populated via the parent driver by pdata/regulator_init_data->driver_data for all regulators when USB_PRODUCT_ID_LSB indicates a TWL6032. Today, the information is not set, so re-add it at the regulator definitions. Fixes: 25d82337705e2 ("regulator: twl: make driver DT only") Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Link: https://lore.kernel.org/r/20221120221208.3093727-2-andreas@kemnade.info Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-02regulator: core: fix UAF in destroy_regulator()Yang Yingliang1-1/+1
[ Upstream commit 1f386d6894d0f1b7de8ef640c41622ddd698e7ab ] I got a UAF report as following: ================================================================== BUG: KASAN: use-after-free in __lock_acquire+0x935/0x2060 Read of size 8 at addr ffff88810e838220 by task python3/268 Call Trace: <TASK> dump_stack_lvl+0x67/0x83 print_report+0x178/0x4b0 kasan_report+0x90/0x190 __lock_acquire+0x935/0x2060 lock_acquire+0x156/0x400 _raw_spin_lock+0x2a/0x40 lockref_get+0x11/0x30 simple_recursive_removal+0x41/0x440 debugfs_remove.part.12+0x32/0x50 debugfs_remove+0x29/0x30 _regulator_put.cold.54+0x3e/0x27f regulator_put+0x1f/0x30 release_nodes+0x6a/0xa0 devres_release_all+0xf8/0x150 Allocated by task 37: kasan_save_stack+0x1c/0x40 kasan_set_track+0x21/0x30 __kasan_slab_alloc+0x5d/0x70 slab_post_alloc_hook+0x62/0x510 kmem_cache_alloc_lru+0x222/0x5a0 __d_alloc+0x31/0x440 d_alloc+0x30/0xf0 d_alloc_parallel+0xc4/0xd20 __lookup_slow+0x15e/0x2f0 lookup_one_len+0x13a/0x150 start_creating+0xea/0x190 debugfs_create_dir+0x1e/0x210 create_regulator+0x254/0x4e0 _regulator_get+0x2a1/0x467 _devm_regulator_get+0x5a/0xb0 regulator_virtual_probe+0xb9/0x1a0 Freed by task 30: kasan_save_stack+0x1c/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x50 __kasan_slab_free+0x102/0x190 kmem_cache_free+0xf6/0x600 rcu_core+0x54c/0x12b0 __do_softirq+0xf2/0x5e3 Last potentially related work creation: kasan_save_stack+0x1c/0x40 __kasan_record_aux_stack+0x98/0xb0 call_rcu+0x42/0x700 dentry_free+0x6c/0xd0 __dentry_kill+0x23b/0x2d0 dput.part.31+0x431/0x780 simple_recursive_removal+0xa9/0x440 debugfs_remove.part.12+0x32/0x50 debugfs_remove+0x29/0x30 regulator_unregister+0xe3/0x230 release_nodes+0x6a/0xa0 ================================================================== Here is how happened: processor A processor B regulator_register() rdev_init_debugfs() rdev->debugfs = debugfs_create_dir() devm_regulator_get() rdev = regulator_dev_lookup() create_regulator(rdev) // using rdev->debugfs as parent debugfs_create_dir(rdev->debugfs) mfd_remove_devices_fn() release_nodes() regulator_unregister() // free rdev->debugfs debugfs_remove_recursive(rdev->debugfs) release_nodes() destroy_regulator() debugfs_remove_recursive() <- causes UAF In devm_regulator_get(), after getting rdev, the refcount is get, so fix this by moving debugfs_remove_recursive() to regulator_dev_release(), then it can be proctected by the refcount, the 'rdev->debugfs' can not be freed until the refcount is 0. Fixes: 5de705194e98 ("regulator: Add basic per consumer debugfs") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20221116033706.3595812-1-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-02regulator: rt5759: fix OOB in validate_desc()Yang Yingliang1-0/+1
[ Upstream commit 7920e0fbced429ab18ad4402e3914146a6a0921b ] I got the following OOB report: BUG: KASAN: slab-out-of-bounds in validate_desc+0xba/0x109 Read of size 8 at addr ffff888107db8ff0 by task python3/253 Call Trace: <TASK> dump_stack_lvl+0x67/0x83 print_report+0x178/0x4b0 kasan_report+0x90/0x190 validate_desc+0xba/0x109 gpiod_set_value_cansleep+0x40/0x5a regulator_ena_gpio_ctrl+0x93/0xfc _regulator_do_enable.cold.61+0x89/0x163 set_machine_constraints+0x140a/0x159c regulator_register.cold.73+0x762/0x10cd devm_regulator_register+0x57/0xb0 rt5759_probe+0x3a0/0x4ac [rt5759_regulator] The desc used in validate_desc() is passed from 'reg_cfg.ena_gpiod', which is not initialized. Fix this by initializing 'reg_cfg' to 0. Fixes: 7b36ddb208bd ("regulator: rt5759: Add support for Richtek RT5759 DCDC converter") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20221116092943.1668326-1-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-02regulator: core: fix kobject release warning and memory leak in ↵Zeng Heng1-1/+5
regulator_register() [ Upstream commit 5f4b204b6b8153923d5be8002c5f7082985d153f ] Here is a warning report about lack of registered release() from kobject lib: Device '(null)' does not have a release() function, it is broken and must be fixed. WARNING: CPU: 0 PID: 48430 at drivers/base/core.c:2332 device_release+0x104/0x120 Call Trace: kobject_put+0xdc/0x180 put_device+0x1b/0x30 regulator_register+0x651/0x1170 devm_regulator_register+0x4f/0xb0 When regulator_register() returns fail and directly goto `clean` symbol, rdev->dev has not registered release() function yet (which is registered by regulator_class in the following), so rdev needs to be freed manually. If rdev->dev.of_node is not NULL, which means the of_node has gotten by regulator_of_get_init_data(), it needs to call of_node_put() to avoid refcount leak. Otherwise, only calling put_device() would lead memory leak of rdev in further: unreferenced object 0xffff88810d0b1000 (size 2048): comm "107-i2c-rtq6752", pid 48430, jiffies 4342258431 (age 1341.780s) backtrace: kmalloc_trace+0x22/0x110 regulator_register+0x184/0x1170 devm_regulator_register+0x4f/0xb0 When regulator_register() returns fail and goto `wash` symbol, rdev->dev has registered release() function, so directly call put_device() to cleanup everything. Fixes: d3c731564e09 ("regulator: plug of_node leak in regulator_register()'s error path") Signed-off-by: Zeng Heng <zengheng4@huawei.com> Link: https://lore.kernel.org/r/20221116074339.1024240-1-zengheng4@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-21regulator: core: Prevent integer underflowPatrick Rudolph1-1/+1
[ Upstream commit 8d8e16592022c9650df8aedfe6552ed478d7135b ] By using a ratio of delay to poll_enabled_time that is not integer time_remaining underflows and does not exit the loop as expected. As delay could be derived from DT and poll_enabled_time is defined in the driver this can easily happen. Use a signed iterator to make sure that the loop exits once the remaining time is negative. Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Link: https://lore.kernel.org/r/20220909125954.577669-1-patrick.rudolph@9elements.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-21regulator: qcom_rpm: Fix circular deferral regressionLinus Walleij1-12/+12
commit 8478ed5844588703a1a4c96a004b1525fbdbdd5e upstream. On recent kernels, the PM8058 L16 (or any other PM8058 LDO-regulator) does not come up if they are supplied by an SMPS-regulator. This is not very strange since the regulators are registered in a long array and the L-regulators are registered before the S-regulators, and if an L-regulator defers, it will never get around to registering the S-regulator that it needs. See arch/arm/boot/dts/qcom-apq8060-dragonboard.dts: pm8058-regulators { (...) vdd_l13_l16-supply = <&pm8058_s4>; (...) Ooops. Fix this by moving the PM8058 S-regulators first in the array. Do the same for the PM8901 S-regulators (though this is currently not causing any problems with out device trees) so that the pattern of registration order is the same on all PMnnnn chips. Fixes: 087a1b5cdd55 ("regulator: qcom: Rework to single platform device") Cc: stable@vger.kernel.org Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <andersson@kernel.org> Cc: Konrad Dybcio <konrad.dybcio@somainline.org> Cc: linux-arm-msm@vger.kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20220909112529.239143-1-linus.walleij@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-08Merge tag 'regulator-fix-v6.0-rc4' of ↵Linus Torvalds2-3/+8
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fixes from Mark Brown: "One core fix here improving the error handling on enable failure, plus smaller fixes for the pfuze100 drive and the SPMI DT bindings" * tag 'regulator-fix-v6.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: Fix qcom,spmi-regulator schema regulator: pfuze100: Fix the global-out-of-bounds access in pfuze100_regulator_probe() regulator: core: Clean up on enable failure
2022-08-25regulator: pfuze100: Fix the global-out-of-bounds access in ↵Xiaolei Wang1-1/+1
pfuze100_regulator_probe() The pfuze_chip::regulator_descs is an array of size PFUZE100_MAX_REGULATOR, the pfuze_chip::pfuze_regulators is the pointer to the real regulators of a specific device. The number of real regulator is supposed to be less than the PFUZE100_MAX_REGULATOR, so we should use the size of 'regulator_num * sizeof(struct pfuze_regulator)' in memcpy(). This fixes the out of bounds access bug reported by KASAN. Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com> Link: https://lore.kernel.org/r/20220825111922.1368055-1-xiaolei.wang@windriver.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-22regulator: core: Clean up on enable failureAndrew Halaney1-2/+7
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-16Merge tag 'regulator-fix-v6.0-rc1' of ↵Linus Torvalds1-1/+1
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-10regulator: core: Fix missing error return from regulator_bulk_get()Douglas Anderson1-1/+1
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-05Merge tag 'tag-chrome-platform-for-v5.20' of ↵Linus Torvalds1-33/+3
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 Torvalds13-132/+13
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 Brown2-8/+40
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 Anderson1-0/+28
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 Anderson1-8/+12
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 Delvare1-1/+1
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ütter1-2/+3
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 He1-1/+5
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 Lin1-3/+0
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 Marko1-0/+23
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 Marko1-0/+7
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 Marko1-0/+7
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 Chong1-1/+0
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 Brown1-1/+1
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 Jiaming1-2/+2
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 Rudolph3-0/+517
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 Brown1-6/+30
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 He1-0/+1
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 Gerhold1-0/+24
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 Gerhold1-2/+2
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 Huang1-0/+1
'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 Huang1-1/+2
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 Huang3-0/+397
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 Huang3-0/+431
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 Kitt1-5/+1
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 Gleixner1-9/+1
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 Gleixner4-36/+4
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 Gleixner3-42/+3
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>
2022-06-10treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_30.RULE ↵Thomas Gleixner5-45/+5
(part 2) 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 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-08platform/chrome: cros_ec_proto: Rename cros_ec_command functionPrashant Malani1-12/+12
cros_ec_command() is the name of a function as well as a struct, as such it can confuse indexing tools (like ctags). Avoid this by renaming it to cros_ec_cmd(). Update all the callsites to use the new name. This patch is a find-and-replace, so should not introduce any functional changes. Suggested-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Prashant Malani <pmalani@chromium.org> Acked-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220606201825.763788-3-pmalani@chromium.org
2022-06-08regulator: cros-ec: Use common cros_ec_command()Prashant Malani1-42/+12
Reduce code duplication by using the common cros_ec_command() function instead of the locally defined variant. Cc: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220606201825.763788-2-pmalani@chromium.org
2022-06-07regulator: qcom_smd: add get_voltage to MP5496Robert Marko1-0/+1
Add the get_voltage OP to MP5496 ops using the generic rpm_reg_get_voltage. Signed-off-by: Robert Marko <robimarko@gmail.com> Link: https://lore.kernel.org/r/20220604193300.125758-1-robimarko@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-07regulator: qcom_smd: correct MP5496 rangesRobert Marko1-4/+4
Currently set MP5496 Buck and LDO ranges dont match its datasheet[1]. According to the datasheet: Buck range is 0.6-2.1875V with a 12.5mV step LDO range is 0.8-3.975V with a 25mV step. So, correct the ranges according to the datasheet[1]. [1] https://www.monolithicpower.com/en/documentview/productdocument/index/version/2/document_type/Datasheet/lang/en/sku/MP5496GR/document_id/6906/ Signed-off-by: Robert Marko <robimarko@gmail.com> Link: https://lore.kernel.org/r/20220604193300.125758-2-robimarko@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-07regulator: mp5416: remove kernel.h includeRobert Marko1-1/+0
Driver does not seem to utilize anything from the kernel.h, compiles and works fine for me without it. So remove kernel.h include as it pulls in a lot of unused stuff. Signed-off-by: Robert Marko <robimarko@gmail.com> Cc: christophe.jaillet@wanadoo.fr Link: https://lore.kernel.org/r/20220607124759.775133-1-robimarko@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-06regulator: rt5190a: check if init_data is NULL, bypass rt5190a_of_parse_cbChiYuan Huang1-0/+3
If the node for the match name cannot be found, 'of_regulator_match' will returns init_data as NULL for this regulator. Add the check for the init_data. If it's NULL, make 'rt5190a_of_parse_cb' function directly return. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1654148646-12182-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-06regulator: mp5416: add support for MP5496Robert Marko1-0/+13
MP5496 is the updated version of MP5416 with the only difference being that now all Buck regulators have the same 0.6-2.1875V range with a 12.5mV step. Signed-off-by: Robert Marko <robimarko@gmail.com> Acked-by: Saravanan Sekar <sravanhome@gmail.com> Link: https://lore.kernel.org/r/20220604145816.47576-4-robimarko@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-06regulator: mp5416: use OF match dataRobert Marko1-2/+8
In preparation for adding support for MP5496 which slightly differs from MP5416 convert the driver to use OF match data instead of always using the MP5416 regulator_desc for regulator registration. Signed-off-by: Robert Marko <robimarko@gmail.com> Acked-by: Saravanan Sekar <sravanhome@gmail.com> Link: https://lore.kernel.org/r/20220604145816.47576-3-robimarko@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-06regulator: mp5416: alphabetically sort header includesRobert Marko1-3/+3
Sort the header include list alphabetically. Signed-off-by: Robert Marko <robimarko@gmail.com> Link: https://lore.kernel.org/r/20220604145816.47576-2-robimarko@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-05-25Merge back reboot/poweroff notifiers rework for 5.19-rc1.Rafael J. Wysocki1-25/+17
generated by cgit v1.2.3 (git 2.39.0) at 2026-01-23 11:46:20 +0300