Devm helpers for regulator get and enable
authorMark Brown <broonie@kernel.org>
Thu, 18 Aug 2022 14:01:21 +0000 (15:01 +0100)
committerMark Brown <broonie@kernel.org>
Thu, 18 Aug 2022 14:01:21 +0000 (15:01 +0100)
commitee94aff2628b18afdb0b6b175e568657bdaead59
tree4a5afd22b0ea32c673e0aaa1493ebddb867fef06
parent9b6744f60b6b47bc0757a1955adb4d2c3ab22e13
parentda279e6965b3838e99e5c0ab8f76b87bf86b31a5
Devm helpers for regulator get and enable

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.