linux-toradex.git/drivers/regulator/da9063-regulator.c, branch v6.18 Linux kernel for Apalis and Colibri modules regulator: Few constifications of static data 2024-09-11T10:20:37+00:00 Mark Brown broonie@kernel.org 2024-09-11T10:20:37+00:00 5faf6daf659a83bd036190172eb17b1f9b3a0b01 Merge series from Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>: Few cleanups (safer code), built tested. Last two patches should probably be tested. 
Merge series from Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>:

Few cleanups (safer code), built tested.  Last two patches should
probably be tested.
regulator: da9063: Constify static data 2024-09-10T11:44:05+00:00 Krzysztof Kozlowski krzysztof.kozlowski@linaro.org 2024-09-09T13:51:14+00:00 0601c1e5c4a1162c909675233645889237b003a2 Driver does not modify static data with device variant description (struct da9063_dev_model), so make it const for code safety. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20240909-regulator-const-v1-3-8934704a5787@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> 
Driver does not modify static data with device variant description
(struct da9063_dev_model), so make it const for code safety.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20240909-regulator-const-v1-3-8934704a5787@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: Fix typos in the comment 2024-09-10T11:40:38+00:00 Yu Jiaoliang yujiaoliang@vivo.com 2024-09-10T06:46:30+00:00 886fee35251107e169128723215b1f779a668be5 Fixed some confusing typographical errors: comptabile->compatible, asignment->assignment, Verison->Version, meansurement->measurement, offets->offsets. Signed-off-by: Yu Jiaoliang <yujiaoliang@vivo.com> Link: https://patch.msgid.link/20240910064631.3223441-1-yujiaoliang@vivo.com Signed-off-by: Mark Brown <broonie@kernel.org> 
Fixed some confusing typographical errors:
comptabile->compatible,
asignment->assignment,
Verison->Version,
meansurement->measurement,
offets->offsets.

Signed-off-by: Yu Jiaoliang <yujiaoliang@vivo.com>
Link: https://patch.msgid.link/20240910064631.3223441-1-yujiaoliang@vivo.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: da9063: Annotate struct da9063_regulators with __counted_by 2023-10-10T21:10:10+00:00 Kees Cook keescook@chromium.org 2023-09-22T17:52:07+00:00 1096f9fa2be18a1340d1299b4c4329af211076e7 Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct da9063_regulators. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Support Opensource <support.opensource@diasemi.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: "Gustavo A. R. Silva" <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20230922175207.work.576-kees@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> 
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).

As found with Coccinelle[1], add __counted_by for struct da9063_regulators.

[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci

Cc: Support Opensource <support.opensource@diasemi.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230922175207.work.576-kees@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: da9063: better fix null deref with partial DT 2023-08-04T12:26:53+00:00 Martin Fuzzey martin.fuzzey@flowbird.group 2023-08-04T08:34:30+00:00 30c694fd4a99fbbc4115d180156ca01b60953371 Two versions of the original patch were sent but V1 was merged instead of V2 due to a mistake. So update to V2. The advantage of V2 is that it completely avoids dereferencing the pointer, even just to take the address, which may fix problems with some compilers. Both versions work on my gcc 9.4 but use the safer one. Fixes: 98e2dd5f7a8b ("regulator: da9063: fix null pointer deref with partial DT config") Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group> Tested-by: Benjamin Bara <benjamin.bara@skidata.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230804083514.1887124-1-martin.fuzzey@flowbird.group Signed-off-by: Mark Brown <broonie@kernel.org> 
Two versions of the original patch were sent but V1 was merged instead
of V2 due to a mistake.

So update to V2.

The advantage of V2 is that it completely avoids dereferencing the pointer,
even just to take the address, which may fix problems with some compilers.
Both versions work on my gcc 9.4 but use the safer one.

Fixes: 98e2dd5f7a8b ("regulator: da9063: fix null pointer deref with partial DT config")
Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
Tested-by: Benjamin Bara <benjamin.bara@skidata.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230804083514.1887124-1-martin.fuzzey@flowbird.group
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: da9063: fix null pointer deref with partial DT config 2023-07-17T05:15:18+00:00 Martin Fuzzey martin.fuzzey@flowbird.group 2023-06-16T14:36:28+00:00 98e2dd5f7a8be5cb2501a897e96910393a49f0ff When some of the da9063 regulators do not have corresponding DT nodes a null pointer dereference occurs on boot because such regulators have no init_data causing the pointers calculated in da9063_check_xvp_constraints() to be invalid. Do not dereference them in this case. Fixes: b8717a80e6ee ("regulator: da9063: implement setter for voltage monitoring") Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group> Link: https://lore.kernel.org/r/20230616143736.2946173-1-martin.fuzzey@flowbird.group Signed-off-by: Mark Brown <broonie@kernel.org> 
When some of the da9063 regulators do not have corresponding DT nodes
a null pointer dereference occurs on boot because such regulators have
no init_data causing the pointers calculated in
da9063_check_xvp_constraints() to be invalid.

Do not dereference them in this case.

Fixes: b8717a80e6ee ("regulator: da9063: implement setter for voltage monitoring")
Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
Link: https://lore.kernel.org/r/20230616143736.2946173-1-martin.fuzzey@flowbird.group
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: da9063: implement setter for voltage monitoring 2023-04-12T11:52:10+00:00 Benjamin Bara benjamin.bara@skidata.com 2023-04-05T17:14:35+00:00 b8717a80e6ee6500ae396d21aac2a00947bba993 Allow to en- and disable voltage monitoring from the device tree. Consider that the da9063 only monitors under- *and* over-voltage together, so both must be set to the same severity and value. Reviewed-by: Adam Ward <DLG-Adam.Ward.opensource@dm.renesas.com> Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com> Link: https://lore.kernel.org/r/20230403-da9063-disable-unused-v3-2-cc4dc698864c@skidata.com Signed-off-by: Mark Brown <broonie@kernel.org> 
Allow to en- and disable voltage monitoring from the device tree.
Consider that the da9063 only monitors under- *and* over-voltage
together, so both must be set to the same severity and value.

Reviewed-by: Adam Ward <DLG-Adam.Ward.opensource@dm.renesas.com>
Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>
Link: https://lore.kernel.org/r/20230403-da9063-disable-unused-v3-2-cc4dc698864c@skidata.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: da9063: add voltage monitoring registers 2023-04-12T11:52:09+00:00 Benjamin Bara benjamin.bara@skidata.com 2023-04-05T17:14:34+00:00 13186dae182ab1a2a52a53424672f49cf3e81f9b Add the definitions for the registers responsible for voltage monitoring. Add a voltage monitor enable bitfield per regulator. Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Adam Ward <DLG-Adam.Ward.opensource@dm.renesas.com> Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com> Link: https://lore.kernel.org/r/20230403-da9063-disable-unused-v3-1-cc4dc698864c@skidata.com Signed-off-by: Mark Brown <broonie@kernel.org> 
Add the definitions for the registers responsible for voltage
monitoring. Add a voltage monitor enable bitfield per regulator.

Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Adam Ward <DLG-Adam.Ward.opensource@dm.renesas.com>
Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>
Link: https://lore.kernel.org/r/20230403-da9063-disable-unused-v3-1-cc4dc698864c@skidata.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14 2023-03-20T13:11:25+00:00 Douglas Anderson dianders@chromium.org 2023-03-16T19:54:38+00:00 259b93b21a9ffe5117af4dfb5505437e463c6a5a Probing of regulators can be a slow operation and can contribute to slower boot times. This is especially true if a regulator is turned on at probe time (with regulator-boot-on or regulator-always-on) and the regulator requires delays (off-on-time, ramp time, etc). While the overall kernel is not ready to switch to async probe by default, as per the discussion on the mailing lists [1] it is believed that the regulator subsystem is in good shape and we can move regulator drivers over wholesale. There is no way to just magically opt in all regulators (regulators are just normal drivers like platform_driver), so we set PROBE_PREFER_ASYNCHRONOUS for all regulators found in 'drivers/regulator' individually. Given the number of drivers touched and the impossibility to test this ahead of time, it wouldn't be shocking at all if this caused a regression for someone. If there is a regression caused by this patch, it's likely to be one of the cases talked about in [1]. As a "quick fix", drivers involved in the regression could be fixed by changing them to PROBE_FORCE_SYNCHRONOUS. That being said, the correct fix would be to directly fix the problem that caused the issue with async probe. The approach here follows a similar approach that was used for the mmc subsystem several years ago [2]. In fact, I ran nearly the same python script to auto-generate the changes. The only thing I changed was to search for "i2c_driver", "spmi_driver", and "spi_driver" in addition to "platform_driver". [1] https://lore.kernel.org/r/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk [2] https://lore.kernel.org/r/20200903232441.2694866-1-dianders@chromium.org/ Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230316125351.1.I2a4677392a38db5758dee0788b2cea5872562a82@changeid Signed-off-by: Mark Brown <broonie@kernel.org> 
Probing of regulators can be a slow operation and can contribute to
slower boot times. This is especially true if a regulator is turned on
at probe time (with regulator-boot-on or regulator-always-on) and the
regulator requires delays (off-on-time, ramp time, etc).

While the overall kernel is not ready to switch to async probe by
default, as per the discussion on the mailing lists [1] it is believed
that the regulator subsystem is in good shape and we can move
regulator drivers over wholesale. There is no way to just magically
opt in all regulators (regulators are just normal drivers like
platform_driver), so we set PROBE_PREFER_ASYNCHRONOUS for all
regulators found in 'drivers/regulator' individually.

Given the number of drivers touched and the impossibility to test this
ahead of time, it wouldn't be shocking at all if this caused a
regression for someone. If there is a regression caused by this patch,
it's likely to be one of the cases talked about in [1]. As a "quick
fix", drivers involved in the regression could be fixed by changing
them to PROBE_FORCE_SYNCHRONOUS. That being said, the correct fix
would be to directly fix the problem that caused the issue with async
probe.

The approach here follows a similar approach that was used for the mmc
subsystem several years ago [2]. In fact, I ran nearly the same python
script to auto-generate the changes. The only thing I changed was to
search for "i2c_driver", "spmi_driver", and "spi_driver" in addition
to "platform_driver".

[1] https://lore.kernel.org/r/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk
[2] https://lore.kernel.org/r/20200903232441.2694866-1-dianders@chromium.org/

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20230316125351.1.I2a4677392a38db5758dee0788b2cea5872562a82@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator: da9063: Add support for full-current mode. 2021-07-15T16:24:50+00:00 Vincent Pelletier plr.vincent@gmail.com 2021-07-13T07:20:31+00:00 541ee8f640327f951e7039278057827322231ab0 In addition to the ability of merging some power outputs, this chip has an overdrive mode. BCORE1, BCORE2 and BPRO have this ability, in which case the legal current draw is increased from 2 amps to 2.5 amps (at the expense of a quiescent current increase), and the configurable current limits are doubled. If a current higher than maximum half-current mode is requested, enable overdrive, and scale the current limit down. Symmetrically, scale the current limit up when querying a overdrive-enabled regulator. Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com> Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Link: https://lore.kernel.org/r/824518e6391b783a12eba9ff0527f06607a34bfb.1626160826.git.plr.vincent@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> 
In addition to the ability of merging some power outputs, this chip has
an overdrive mode.
BCORE1, BCORE2 and BPRO have this ability, in which case the legal
current draw is increased from 2 amps to 2.5 amps (at the expense of
a quiescent current increase), and the configurable current limits
are doubled.
If a current higher than maximum half-current mode is requested, enable
overdrive, and scale the current limit down.
Symmetrically, scale the current limit up when querying a overdrive-enabled
regulator.

Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>
Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/824518e6391b783a12eba9ff0527f06607a34bfb.1626160826.git.plr.vincent@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>