linux-toradex.git/drivers/regulator/s5m8767.c, branch v7.2-rc5

regulator: Drop unused assignment of platform_device_id driver data

2026-06-02T15:09:23+00:00

Several drivers explicitly set the .driver_data member of struct
platform_device_id to zero without relying on that value. Drop these
unused assignments.

While touching these arrays unify spacing, usage of commas and use
named initializers for .name.

Signed-off-by: Uwe Kleine-König (The Capable Hub) 
Link: https://patch.msgid.link/613cd1bed263c2bf562ee714595f6d57f442804d.1779878004.git.u.kleine-koenig@baylibre.com
Signed-off-by: Mark Brown

regulator: s5m8767: Convert to GPIO descriptors

2025-04-07T11:53:34+00:00

Update the driver to fetch buck_gpio and buck_ds as GPIO descriptors.
Then drop the usage of 'of_gpio.h' which should be deprecated.
Based on commit 84618d5e31cf ("regulator: max8997:
Convert to GPIO descriptors") as a reference to make the changes.

With the quirk fix for s5m8767 in of_gpio_try_fixup_polarity,
the polarity will be active-high, even if exynos5250 spring DTS
wrongly use active-low polarity. So using GPIO descriptors,
it should work as before.

Signed-off-by: Peng Fan 
Acked-by: Mark Brown 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Linus Walleij 
Acked-by: Krzysztof Kozlowski 
Link: https://patch.msgid.link/20250327004945.563765-2-peng.fan@oss.nxp.com
Signed-off-by: Mark Brown

regulator: s5m8767: Use scoped device node handling to simplify error paths

2024-08-14T17:21:45+00:00

Obtain the device node reference with scoped/cleanup.h to reduce error
handling and make the code a bit simpler.

Signed-off-by: Krzysztof Kozlowski 
Link: https://patch.msgid.link/20240814-cleanup-h-of-node-put-regulator-v1-4-87151088b883@linaro.org
Signed-off-by: Mark Brown

regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14

2023-03-20T13:11:25+00:00

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
Link: https://lore.kernel.org/r/20230316125351.1.I2a4677392a38db5758dee0788b2cea5872562a82@changeid
Signed-off-by: Mark Brown

regulator: Use of_property_read_bool() for boolean properties

2023-03-11T12:13:42+00:00

It is preferred to use typed property access functions (i.e.
of_property_read_ functions) rather than low-level
of_get_property/of_find_property functions for reading properties.
Convert reading boolean properties to to of_property_read_bool().

Signed-off-by: Rob Herring 
Link: https://lore.kernel.org/r/20230310144722.1544843-1-robh@kernel.org
Signed-off-by: Mark Brown

regulator: s5m8767: Bounds check id indexing into arrays

2023-01-28T17:19:11+00:00

The compiler has no way to know if "id" is within the array bounds of
the regulators array. Add a check for this and a build-time check that
the regulators and reg_voltage_map arrays are sized the same. Seen with
GCC 13:

../drivers/regulator/s5m8767.c: In function 's5m8767_pmic_probe':
../drivers/regulator/s5m8767.c:936:35: warning: array subscript [0, 36] is outside array bounds of 'struct regulator_desc[37]' [-Warray-bounds=]
  936 |                         regulators[id].vsel_reg =
      |                         ~~~~~~~~~~^~~~

Cc: Krzysztof Kozlowski 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Kees Cook 
Reviewed-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20230128005358.never.313-kees@kernel.org
Signed-off-by: Mark Brown

regulator: s5m8767: do not use reset value as DVS voltage if GPIO DVS is disabled

2021-10-08T16:24:30+00:00

The driver and its bindings, before commit 04f9f068a619 ("regulator:
s5m8767: Modify parsing method of the voltage table of buck2/3/4") were
requiring to provide at least one safe/default voltage for DVS registers
if DVS GPIO is not being enabled.

IOW, if s5m8767,pmic-buck2-uses-gpio-dvs is missing, the
s5m8767,pmic-buck2-dvs-voltage should still be present and contain one
voltage.

This requirement was coming from driver behavior matching this condition
(none of DVS GPIO is enabled): it was always initializing the DVS
selector pins to 0 and keeping the DVS enable setting at reset value
(enabled).  Therefore if none of DVS GPIO is enabled in devicetree,
driver was configuring the first DVS voltage for buck[234].

Mentioned commit 04f9f068a619 ("regulator: s5m8767: Modify parsing
method of the voltage table of buck2/3/4") broke it because DVS voltage
won't be parsed from devicetree if DVS GPIO is not enabled.  After the
change, driver will configure bucks to use the register reset value as
voltage which might have unpleasant effects.

Fix this by relaxing the bindings constrain: if DVS GPIO is not enabled
in devicetree (therefore DVS voltage is also not parsed), explicitly
disable it.

Cc: 
Fixes: 04f9f068a619 ("regulator: s5m8767: Modify parsing method of the voltage table of buck2/3/4")
Signed-off-by: Krzysztof Kozlowski 
Acked-by: Rob Herring 
Message-Id: <20211008113723.134648-2-krzysztof.kozlowski@canonical.com>
Signed-off-by: Mark Brown

regulator: s5m8767: Drop regulators OF node reference

2021-01-21T18:14:49+00:00

The device node reference obtained with of_get_child_by_name() should be
dropped on error paths.

Fixes: 26aec009f6b6 ("regulator: add device tree support for s5m8767")
Signed-off-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20210121155914.48034-1-krzk@kernel.org
Signed-off-by: Mark Brown

regulator: s5m8767: Fix reference count leak

2021-01-21T18:14:21+00:00

Call of_node_put() to drop references of regulators_np and reg_np before
returning error code.

Fixes: 9ae5cc75ceaa ("regulator: s5m8767: Pass descriptor instead of GPIO number")
Signed-off-by: Pan Bian 
Reviewed-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20210121032756.49501-1-bianpan2016@163.com
Signed-off-by: Mark Brown

regulator: s5m8767: initialize driver via module_platform_driver

2020-09-21T23:45:16+00:00

The driver was using subsys_initcall() because in old times deferred
probe was not supported everywhere and specific ordering was needed.
Since probe deferral works fine and specific ordering is discouraged
(hides dependencies between drivers and couples their boot order), the
driver can be converted to regular module_platform_driver.

Signed-off-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20200921203616.19623-1-krzk@kernel.org
Signed-off-by: Mark Brown