user/sven/linux.git/include/linux/regulator/consumer.h, branch v5.3.11

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

2019-06-19T15:09:55Z

Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner Reviewed-by: Enrico Weigelt Reviewed-by: Kate Stewart Reviewed-by: Allison Randal Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman

regulator: add regulator_get_linear_step() stub helper

2019-03-21T14:59:38Z

The regulator header has empty inline functions for most interfaces, but not regulator_get_linear_step(), which has just grown a user that does not depend on regulators otherwise: drivers/clk/tegra/clk-tegra124-dfll-fcpu.c: In function 'get_alignment_from_regulator': drivers/clk/tegra/clk-tegra124-dfll-fcpu.c:555:19: error: implicit declaration of function 'regulator_get_linear_step'; did you mean 'regulator_get_drvdata'? [-Werror=implicit-function-declaration] align->step_uv = regulator_get_linear_step(reg); ^~~~~~~~~~~~~~~~~~~~~~~~~ regulator_get_drvdata cc1: all warnings being treated as errors scripts/Makefile.build:278: recipe for target 'drivers/clk/tegra/clk-tegra124-dfll-fcpu.o' failed Add the missing stub along the others. Fixes: b3cf8d069505 ("clk: tegra: dfll: CVB calculation alignment with the regulator") Signed-off-by: Arnd Bergmann Signed-off-by: Mark Brown

regulator: Fix return value of _set_load() stub

2018-11-20T15:22:46Z

The stub implementation of _set_load() returns a mode value which is within the bounds of valid return codes for success (the documentation just says that failures are negative error codes) but not sensible or what the actual implementation does. Fix it to just return 0. Reported-by: Cheng-Yi Chiang Signed-off-by: Mark Brown Reviewed-by: Douglas Anderson Signed-off-by: Mark Brown

regulator: Don't return or expect -errno from of_map_mode()

2018-04-20T11:45:36Z

In of_get_regulation_constraints() we were taking the result of of_map_mode() (an unsigned int) and assigning it to an int. We were then checking whether this value was -EINVAL. Some implementers of of_map_mode() were returning -EINVAL (even though the return type of their function needed to be unsigned int) because they needed to signal an error back to of_get_regulation_constraints(). In general in the regulator framework the mode is always referred to as an unsigned int. While we could fix this to be a signed int (the highest value we store in there right now is 0x8), it's actually pretty clean to just define the regulator mode 0x0 (the lack of any bits set) as an invalid mode. Let's do that. Fixes: 5e5e3a42c653 ("regulator: of: Add support for parsing initial and suspend modes") Suggested-by: Javier Martinez Canillas Signed-off-by: Douglas Anderson Reviewed-by: Javier Martinez Canillas Signed-off-by: Mark Brown

regulator: core: Add new notification for enabling of regulator

2017-03-24T19:13:42Z

This is useful for devices, which need some time to start up, to help the drivers track how long the supply has been up already. Ie whether it can safely talk to the HW or needs to wait. Signed-off-by: Harald Geyer Signed-off-by: Mark Brown

regulator: Fix regulator_get_error_flags() signature mismatch

2016-12-05T11:38:30Z

The function signature of does not match regulator_get_error_flags() when CONFIG_REGULATOR is not defined vs. when it is not defined. This makes both declarations match to prevent compiler errors. Signed-off-by: David Lechner Signed-off-by: Mark Brown

regulator: core: Add new API to poll for error conditions

2016-11-04T18:15:25Z

Regulator consumers can receive event notifications when errors are reported to the driver, but currently, there is no way for a regulator consumer to know when the error is over. To allow a regulator consumer to poll for error conditions add a new API: regulator_get_error_flags. Signed-off-by: Axel Haslam Signed-off-by: Mark Brown

regulator: Remove support for optional supplies in the bulk API

2016-08-16T19:00:44Z

The patch was based on my missinterpretation of the API and only accidentally worked for me. Let's clean it out to not confuse others. This reverts commit 3ff3f518a135fa4592fe2817e9ac2cce1fa23dc2. Signed-off-by: Bjorn Andersson Signed-off-by: Mark Brown

regulator: Remove regulator_can_change_voltage()

2016-06-09T10:40:34Z

There is little obvious use case for a regualtor driver to know if it is possible to vary voltages at all by itself. If a consumer needs to limit what voltages it tries to set based on the system configuration then it will need to enumerate the possible voltages, and without that even if it is possible to change voltages that doesn't mean that constraints or other consumers will allow whatever change the driver is trying to do at a given time. It doesn't even indicate if _set_voltage() calls will work as noop _set_voltage() calls return success. There were no users of this API that weren't abusing it and now they're all gone so remove the API. Signed-off-by: Mark Brown

regulator: Silence build warnings from regulator_can_change_voltage()

2016-05-17T17:06:18Z

Cut down on noise for mainstream users of the API and people doing build testing by dropping the deprecated flag from regulator_can_change_voltage() as it triggers even on the EXPORT_SYMBOL_GPL() which affects all builds rather than just the remaining drivers with calls to it (for which fixes are currently pending). The function remains deprecated and is expected to be removed entirely in v4.8. Signed-off-by: Mark Brown