- May 17, 2022
-
-
Mark Brown authored
-
Miaoqian Lin authored
of_find_node_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Fixes: 0fbeae70 ("regulator: add SCMI driver") Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Link: https://lore.kernel.org/r/20220516074433.32433-1-linmq006@gmail.com Signed-off-by:
Mark Brown <broonie@kernel.org>
-
- May 12, 2022
-
-
Miaoqian Lin authored
of_node_get() returns a node with refcount incremented. Calling of_node_put() to drop the reference when not needed anymore. Fixes: 3784b6d6 ("regulator: pfuze100: add pfuze100 regulator driver") Signed-off-by:
-
- May 10, 2022
-
-
Konrad Dybcio authored
Following changes have been made: - S5, L4, L18, L20 and L21 were removed (S5 is managed by SPMI, whereas the rest seems not to exist [or at least it's blocked by Sony Loire /MSM8956/ RPM firmware]) - Supply maps have were adjusted to reflect regulator changes. Fixes: e44adca5 ("regulator: qcom_smd: Add PM8950 regulators") Signed-off-by:
Konrad Dybcio <konrad.dybcio@somainline.org> Link: https://lore.kernel.org/r/20220430163753.609909-1-konrad.dybcio@somainline.org Signed-off-by:
-
- May 05, 2022
-
-
Zev Weiss authored
Since the introduction of regulator->enable_count, a driver that did an exclusive get on an already-enabled regulator would end up with enable_count initialized to 0 but rdev->use_count initialized to 1. With that starting point the regulator is effectively stuck enabled, because if the driver attempted to disable it it would fail the enable_count underflow check in _regulator_handle_consumer_disable(). The EXCLUSIVE_GET path in _regulator_get() now initializes enable_count along with rdev->use_count so that the regulator can be disabled without underflowing the former. Signed-off-by:
Zev Weiss <zev@bewilderbeest.net> Fixes: 5451781d ("regulator: core: Only count load for enabled consumers") Link: https://lore.kernel.org/r/20220505043152.12933-1-zev@bewilderbeest.net Signed-off-by:
-
Mark Brown authored
Merge series from Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>: Extend the RPMH regulator bindings with minor fixes and adding narrow supply matching.
-
- May 04, 2022
-
-
Zev Weiss authored
If a regulator provides a get_error_flags() operation, its sysfs attributes will now include an entry for each defined REGULATOR_ERROR_* flag. Signed-off-by:
-
Krzysztof Kozlowski authored
The PMR735A comes with vdd-l7-bob-supply supply which was previously not documented. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220426105501.73200-4-krzysztof.kozlowski@linaro.org Signed-off-by:
-
Krzysztof Kozlowski authored
The RPMH regulator binding covers several devices with different regulator supplies, so it uses patterns matching broad range of these supplies. This works fine but is not specific and might miss actual mistakes when a wrong supply property is used for given variant. Describe the supplies depending on the compatible, using a defs-allOf method. Signed-off-by:
-
Krzysztof Kozlowski authored
David Collins' email bounces ("Recipient address rejected: undeliverable address: No such user here"). Signed-off-by:Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220426105501.73200-2-krzysztof.kozlowski@linaro.org Signed-off-by:
-
Nícolas F. R. A. Prado authored
The MT6315 PMIC dt-binding should enforce that one of the valid regulator-compatible is set in each regulator node. However it was mistakenly matching against regulator-name instead. Fix the typo. This not only fixes the compatible verification, but also lifts the regulator-name restriction, so that more meaningful names can be set for each platform. Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20220429201325.2205799-1-nfraprado@collabora.com Signed-off-by:
-
- May 03, 2022
-
-
Rickard x Andersson authored
When DVS is enabled via the devicetree properties "nxp,dvs-run-voltage" and "nxp,dvs-standby-voltage" then also the bit that enables DVS control via PMIC_STBY_REQ pin should be set. Signed-off-by:
Rickard x Andersson <rickaran@axis.com> Link: https://lore.kernel.org/r/20220429072211.24957-5-rickaran@axis.com Signed-off-by:
-
Rickard x Andersson authored
The default configuration of the PMIC behavior makes the PMIC power cycle most regulators on WDOG_B assertion. This power cycling causes the memory contents of OCRAM to be lost. Some systems neeeds some memory that survives reset and reboot, therefore this patch is created. Signed-off-by:
-
Rickard x Andersson authored
Make it possible to do warm reset on WDOG_B assertion. Signed-off-by:
-
Per-Daniel Olsson authored
Make the I2C Level Translator included in PCA9450 configurable from devicetree. The reset state is off. By setting nxp,i2c-lt-enable, the I2C Level Translator will be enabled while in STANDBY or RUN state. Signed-off-by:
Per-Daniel Olsson <perdo@axis.com> Signed-off-by:
-
Per-Daniel Olsson authored
By setting nxp,i2c-lt-enable the I2C level translator is enabled. Signed-off-by:
-
- Apr 29, 2022
-
-
Markuss Broks authored
The correct file name is regulator.yaml, not regulators.yaml. Signed-off-by:
Markuss Broks <markuss.broks@gmail.com> Link: https://lore.kernel.org/r/20220429120914.9928-1-markuss.broks@gmail.com Signed-off-by:
-
- Apr 26, 2022
-
-
Markuss Broks authored
Regulators block of SM5703 controls several voltage regulators which are used to power various components. There are 3 LDO outputs ranging from 1.5 to 3.3V, a buck regulator ranging from 1V to 3V, two fixed voltage LDO regulators for powering the USB devices and one high-power fixed voltage LDO line (actually two lines) meant to power high-power USB devices. Signed-off-by:
-
Markuss Broks authored
This patch adds device-tree bindings for regulators on Silicon Mitus SM5703 MFD. Signed-off-by:
-
- Apr 25, 2022
-
-
Krzysztof Kozlowski authored
Having one enable-gpios property for all regulators is discouraged and instead, similarly to regulator core ena_gpiod feature, each GPIO should be present in each regulator node. Add support for parsing such GPIOs, keeping backwards compatibility. Signed-off-by:
ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/20220425072455.27356-3-krzysztof.kozlowski@linaro.org Signed-off-by:
-
Krzysztof Kozlowski authored
The binding and driver duplicated regulator core feature of controlling regulators with GPIOs (of_parse_cb + ena_gpiod) and created its own enable-gpios property with multiple GPIOs. This is a less preferred way, because enable-gpios should enable only one element, not multiple. It also duplicates existing solution. Deprecate the original 'enable-gpios' and add per-regulator property. Signed-off-by:
-
- Apr 22, 2022
-
-
ChiYuan Huang authored
Revise the rt5190a bucks and ldo property description. Signed-off-by:
-
- Apr 21, 2022
-
-
Brian Norris authored
These delays can be relatively large (e.g., hundreds of microseconds to several milliseconds on RK3399 Gru systems). Per Documentation/timers/timers-howto.rst, that should usually use a sleeping delay. Let's use the existing regulator delay helper to handle both large and small delays appropriately. This avoids burning a bunch of CPU time and hurting scheduling latencies when hitting regulators a lot (e.g., during cpufreq). The sleep vs. delay issue choice has been made differently over time -- early versions of RK3399 Gru PWM-regulator support used usleep_range() in pwm-regulator.c. More of this got moved into the regulator core, in commits like: 73e705bf regulator: core: Add set_voltage_time op At the same time, the sleep turned into a delay. It's OK to sleep in _regulator_do_set_voltage(), as we aren't in an atomic context. (All our callers grab various mutexes already.) I avoid using fsleep() because it uses a usleep_range() of [N to N*2], and usleep_range() very commonly biases to the high end of the range. We don't want to double the expected delay, especially for long delays. Signed-off-by:
Brian Norris <briannorris@chromium.org> Reviewed-by:
Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20220420141511.v2.2.If0fc61a894f537b052ca41572aff098cf8e7e673@changeid Signed-off-by:
-
Brian Norris authored
I want to use it in other contexts besides _regulator_do_enable(). Signed-off-by:
-
Wei Yongjun authored
KASAN report slab-out-of-bounds in __regmap_init as follows: BUG: KASAN: slab-out-of-bounds in __regmap_init drivers/base/regmap/regmap.c:841 Read of size 1 at addr ffff88803678cdf1 by task xrun/9137 CPU: 0 PID: 9137 Comm: xrun Tainted: G W 5.18.0-rc2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xe8/0x15a lib/dump_stack.c:88 print_report.cold+0xcd/0x69b mm/kasan/report.c:313 kasan_report+0x8e/0xc0 mm/kasan/report.c:491 __regmap_init+0x4540/0x4ba0 drivers/base/regmap/regmap.c:841 __devm_regmap_init+0x7a/0x100 drivers/base/regmap/regmap.c:1266 __devm_regmap_init_i2c+0x65/0x80 drivers/base/regmap/regmap-i2c.c:394 da9121_i2c_probe+0x386/0x6d1 drivers/regulator/da9121-regulator.c:1039 i2c_device_probe+0x959/0xac0 drivers/i2c/i2c-core-base.c:563 This happend when da9121 device is probe by da9121_i2c_id, but with invalid dts. Thus, chip->subvariant_id is set to -EINVAL, and later da9121_assign_chip_model() will access 'regmap' without init it. Fix it by return -EINVAL from da9121_assign_chip_model() if 'chip->subvariant_id' is invalid. Fixes: f3fbd556 ("regulator: da9121: Add device variants") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Adam Ward <Adam.Ward.Opensource@diasemi.com> Link: https://lore.kernel.org/r/20220421090335.1876149-1-weiyongjun1@huawei.com Signed-off-by:
-
- Apr 19, 2022
-
-
Minghao Chi authored
Using pm_runtime_resume_and_get is more appropriate for simplifing code Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Minghao Chi <chi.minghao@zte.com.cn> Link: https://lore.kernel.org/r/20220412071030.2532230-1-chi.minghao@zte.com.cn Signed-off-by:
-
- Apr 13, 2022
-
-
Krzysztof Kozlowski authored
Document used PMIC IDs: 'h' (sm8450-hdk, sm8450-qrd) and 'k' (sc7280-crd). Signed-off-by:
-
- Apr 08, 2022
-
-
Matti Vaittinen authored
The email backend used by ROHM keeps labeling patches as spam. Additionally, there have been reports of some emails been completely dropped. Finally also the email list (or shared inbox) linux-power@fi.rohmeurope.com inadvertly stopped working and has not been reviwed during the past few weeks. Remove no longer working list 'linux-power' list-entry and switch my email to use the personal gmail account instead of the company account. Signed-off-by:
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/Yk/zAHusOdf4+h06@dc73szyh141qn5ck3nwqy-3.rev.dnainternet.fi Signed-off-by:
-
Kunihiko Hayashi authored
This refers common bindings, so this is preferred for unevaluatedProperties instead of additionalProperties. Signed-off-by:
Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Acked-by:
-
Kunihiko Hayashi authored
Instead of "oneOf:" choices, use "allOf:" and "if:" to define clocks, resets, and their names that can be taken by the compatible string. The order of clock-names and reset-names doesn't change here. Signed-off-by:
-
- Apr 07, 2022
-
-
Mark Brown authored
Merge series from cy_huang <u0084500@gmail.com>: This patch series add Richtek RT5759 buck converter support.
-
- Apr 06, 2022
-
-
Andy Shevchenko authored
GPIO library does copy the of_node from the parent device of the GPIO chip, there is no need to repeat this in the individual drivers. Remove these assignment all at once. For the details one may look into the of_gpio_dev_init() implementation. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220325184508.45670-1-andriy.shevchenko@linux.intel.com Signed-off-by:
-
- Apr 05, 2022
-
-
Mark Brown authored
Merge series from Johnson Wang <johnson.wang@mediatek.com>: This patchset adds support for MediaTek PMIC MT6366. MT6366 is the primary PMIC for MT8186 and probably other SOCs.
-
Mark Brown authored
Merge series from Johnson Wang <johnson.wang@mediatek.com>: This patchset adds support for MediaTek PMIC MT6366. MT6366 is the primary PMIC for MT8186 and probably other SOCs.
-
- Apr 04, 2022
-
-
Johnson Wang authored
The MT6366 is a regulator found on boards based on MediaTek MT8186 and probably other SoCs. It is a so called pmic and connects as a slave to SoC using SPI, wrapped inside the pmic-wrapper. Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
Johnson Wang <johnson.wang@mediatek.com> Link: https://lore.kernel.org/r/20220401080212.27383-2-johnson.wang@mediatek.com Signed-off-by:
-
Johnson Wang authored
Add buck_vcore_sshub and ldo_vsram_others_sshub regulators to binding document for MT6358 and MT6366. Reviewed-by:
-
Axel Lin authored
Without active_discharge_on setting, the SWITCH1 discharge enable control is always disabled. Fix it. Fixes: 3b15ccac ("regulator: Add regulator driver for ATC260x PMICs") Signed-off-by:
Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20220403132235.123727-1-axel.lin@ingics.com Signed-off-by:
-
Mark Brown authored
While we currently assume that regulators with no control available are just uncontionally enabled this isn't always as clearly displayed to users as is desirable, for example the code for disabling unused regulators will log that it is about to disable them. Clean this up a bit by setting always_on during constraint evaluation if we have no available mechanism for controlling the regualtor so things that check the constraint will do the right thing. Signed-off-by:
-
Mark Brown authored
OOMs are very verbose, we don't need to print an additional error message when we fail to allocate. Signed-off-by:
-
Krzysztof Kozlowski authored
Correct grammar in 'enable-gpios' description and remove useless comment about regulator nodes, because these are obvious from patternProperties. Signed-off-by:
-
