user/sven/linux.git/include/linux/regulator, branch v5.16.4

regulator: Update protection IRQ helper docs

2021-11-18T13:57:09Z

The documentation of IRQ notification helper had still references to first RFC implementation which called BUG() while trying to protect the hardware. Behaviour was improved as calling the BUG() was not a proper solution. Current implementation attempts to call poweroff if handling of potentially damaging error notification fails. Update the documentation to reflect the actual behaviour. Signed-off-by: Matti Vaittinen Link: https://lore.kernel.org/r/0c9cc4bcf20c3da66fd5a85c97ee4288e5727538.1637233864.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown

regulator: tps62360: replacing legacy gpio interface for gpiod

2021-10-21T13:18:42Z

Removing all linux/gpio.h and linux/of_gpio.h dependencies and replacing them with the gpiod interface. Signed-off-by: Maíra Canal Link: https://lore.kernel.org/r/YWxmL2baF5AdzyHv@fedora Signed-off-by: Mark Brown

regulator: lp872x: Remove lp872x_dvs_state

2021-10-21T13:17:49Z

After this driver was converted to gpiod, clang started warning: vers/regulator/lp872x.c:689:57: error: implicit conversion from enumeration type 'enum lp872x_dvs_state' to different enumeration type 'enum gpiod_flags' [-Werror,-Wenum-conversion] dvs->gpio = devm_gpiod_get_optional(lp->dev, "ti,dvs", pinstate); ~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~~~ 1 error generated. lp872x_dvs_state was updated to have values from gpiod_flags but this is not enough to avoid an implicit conversion warning from either GCC or clang (although GCC enables this warning under -Wextra instead of -Wall like clang so it is not seen under normal builds). Eliminate lp872x_dvs_state in favor of using gpiod_flags everywhere so that there is no more warning about an implicit conversion. Fixes: 72bf80cf09c4 ("regulator: lp872x: replacing legacy gpio interface for gpiod") Link: https://github.com/ClangBuiltLinux/linux/issues/1481 Signed-off-by: Nathan Chancellor Link: https://lore.kernel.org/r/20211019004335.193492-1-nathan@kernel.org Signed-off-by: Mark Brown

regulator: lp872x: replacing legacy gpio interface for gpiod

2021-10-16T17:23:55Z

Removing all linux/gpio.h and linux/of_gpio.h dependencies and replacing them with the gpiod interface Signed-off-by: Maíra Canal Message-Id: Signed-off-by: Mark Brown

regulator: Documentation fix for regulator error notification helper

2021-08-23T10:06:28Z

The helper to send IRQ notification for regulator errors had still old description mentioning calling BUG() as a last resort when error status reading has kept failing for more times than a given threshold. The impementation calling BUG() did never end-up in-tree but was replaced by hopefully more sophisticated handler trying to power-off the system. Fix the documentation to reflect actual behaviour. Signed-off-by: Matti Vaittinen Link: https://lore.kernel.org/r/20210823075651.GA3717293@localhost.localdomain Signed-off-by: Mark Brown

regulator: Minor regulator documentation fixes.

2021-08-18T12:57:03Z

The newly added regulator ramp-delay specifiers in regulator desc lacked the documentation. Add some. Also fix a typo. Signed-off-by: Matti Vaittinen Link: https://lore.kernel.org/r/20210818041513.GA2408290@dc7vkhyh15000m40t6jht-3.rev.dnainternet.fi Signed-off-by: Mark Brown

Merge series "regulator: devres: remove unused device-managed unregister APIs" from Alexandru Ardelean :

2021-07-12T10:30:35Z

These APIs aren't used anywhere and most-likely exist because of the general principle of C APIs, where if an API function does an allocation/registration, it must also have an equivalent deallocation/deregistration counterpart. For devm_ functions this isn't all that true (for all cases), as the idea of these function is to provide an auto-cleanup logic on drivers/system de-init. Removing these discourages any weird logic that could be created with such an API functions. Alexandru Ardelean (4): regulator: devres: remove devm_regulator_unregister_notifier() function regulator: devres: remove devm_regulator_unregister() function regulator: devres: remove devm_regulator_bulk_unregister_supply_alias() regulator: devres: unexport devm_regulator_unregister_supply_alias() drivers/regulator/devres.c | 105 +---------------------------- include/linux/regulator/consumer.h | 23 ------- include/linux/regulator/driver.h | 1 - 3 files changed, 2 insertions(+), 127 deletions(-) -- 2.31.1

regulator: machine.h: fix kernel-doc "bad line"

2021-07-11T22:50:40Z

Fix warning caused by a blank/empty line: ../include/linux/regulator/machine.h:115: warning: bad line: Signed-off-by: Randy Dunlap Link: https://lore.kernel.org/r/20210628015422.8845-1-rdunlap@infradead.org Signed-off-by: Mark Brown

regulator: devres: unexport devm_regulator_unregister_supply_alias()

2021-07-11T22:50:34Z

This API hook isn't used anywhere outside of the regulator devres code. This function is needed for the devm_regulator_bulk_register_supply_alias() function on the error path, to cleanup any previously registered supply aliases. This change makes the devm_regulator_unregister_supply_alias() local to the regulator core framework, to avoid it being used in any weird logic. It's also removing the doc-string for devm_regulator_unregister_supply_alias(), since it doesn't need to be documented anymore, as no other external consumer should use it. Signed-off-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210625122324.327585-5-aardelean@deviqon.com Signed-off-by: Mark Brown

regulator: devres: remove devm_regulator_bulk_unregister_supply_alias()

2021-07-11T22:50:33Z

This API hook isn't used anywhere and most-likely exists because of the general principle of C APIs, where if an API function does an allocation/registration, it must also have an equivalent deallocation/deregistration counterpart. For devm_ functions this isn't all that true (for all cases), as the idea of these function is to provide an auto-cleanup logic on drivers/system de-init. Removing this also discourages any weird logic that could be created with such an API function. Signed-off-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210625122324.327585-4-aardelean@deviqon.com Signed-off-by: Mark Brown