kernel/linux.git/drivers/regulator/core.c, branch v4.19.16

regulator: fix crash caused by null driver data

2018-09-20T16:04:51+00:00

dev_set_drvdata() needs to be called before device_register() exposes device to userspace. Otherwise kernel crashes after it gets null pointer from dev_get_drvdata() when userspace tries to access sysfs entries. [Removed backtrace for length -- broonie] Signed-off-by: Yu Zhao Signed-off-by: Mark Brown Cc: stable@vger.kernel.org

regulator: Fix 'do-nothing' value for regulators without suspend state

2018-09-03T15:10:40+00:00

Some regulators don't have all states defined and in such cases regulator core should not assume anything. However in current implementation of of_get_regulation_constraints() DO_NOTHING_IN_SUSPEND enable value was set only for regulators which had suspend node defined, otherwise the default 0 value was used, what means DISABLE_IN_SUSPEND. This lead to broken system suspend/resume on boards, which had simple regulator constraints definition (without suspend state nodes). To avoid further mismatches between the default and uninitialized values of the suspend enabled/disabled states, change the values of the them, so default '0' means DO_NOTHING_IN_SUSPEND. Fixes: 72069f9957a1: regulator: leave one item to record whether regulator is enabled Signed-off-by: Marek Szyprowski Signed-off-by: Mark Brown Cc: stable@vger.kernel.org

regulator: core: Link consumer with regulator driver

2018-07-05T17:55:20+00:00

Add a device link between the consumer and the driver so that the consumer is not suspended before the driver. The goal is to avoid implementing suspend_late ops in regulator drivers. Signed-off-by: pascal paillet Signed-off-by: Mark Brown

regulator: core: Change suspend_late to suspend

2018-07-05T17:07:45+00:00

Change suspend_late ops to suspend normal ops. The goal is to avoid requesting all the regulator drivers to be operational in suspend late phase. Signed-off-by: pascal paillet Signed-off-by: Mark Brown

regulator: Revert coupled regulator support again

2018-05-30T14:20:28+00:00

Revert the last two commits of the voltage coupling mechanism patch set: 456e7cdf3b1a14e2606b8 regulator: core: Change voltage setting path 696861761a58d8c93605b regulator: core: Add voltage balancing mechanism as they broke boot on OMAP again. Reported-by: Tony Lindgren Signed-off-by: Mark Brown

regulator: core: Change voltage setting path

2018-05-17T07:05:51+00:00

regulator: core: Add voltage balancing mechanism

2018-05-17T07:05:50+00:00

On Odroid XU3/4 and other Exynos5422 based boards there is a case, that different devices on the board are supplied by different regulators with non-fixed voltages. If one of these devices temporarily requires higher voltage, there might occur a situation that the spread between two devices' voltages is so high, that there is a risk of changing 'high' and 'low' states on the interconnection between devices powered by those regulators. Introduce new function regulator_balance_voltage(), which keeps max_spread constraint fulfilled between a group of coupled regulators. It should be called if a regulator changes its voltage or after disabling or enabling. Disabled regulators should follow changes of the enabled ones, but their consumers' demands shouldn't be taken into account while calculating voltage of other coupled regulators. Find voltages, which are closest to suiting all the consumers' demands, while fulfilling max_spread constraint, keeping the following rules: - if one regulator is about to rise its voltage, rise others voltages in order to keep the max_spread - if a regulator, which has caused rising other regulators, is lowered, lower other regulators if possible - if one regulator is about to lower its voltage, but it hasn't caused rising other regulators, don't change its voltage if it breaks the max_spread Change regulators' voltages step by step, keeping max_spread constraint fulfilled all the time. Function regulator_get_optimal_voltage() should find the best possible change for the regulator, which doesn't break max_spread constraint. In function regulator_balance_voltage() optimize number of steps by finding highest voltage difference on each iteration. If a regulator, which is about to change its voltage, is not coupled, method regulator_get_optimal_voltage() should simply return the lowest voltage fulfilling consumers' demands. Coupling should be checked only if the system is in PM_SUSPEND_ON state. Signed-off-by: Maciej Purski Signed-off-by: Mark Brown

regulator: core: Resolve coupled regulators

2018-05-17T07:05:49+00:00

regulator: core: Make locks re-entrant

2018-05-17T07:05:03+00:00

Setting voltage, enabling/disabling regulators requires operations on all regulators related with the regulator being changed. Therefore, all of them should be locked for the whole operation. With the current locking implementation, adding additional dependency (regulators coupling) causes deadlocks in some cases. Introduce a possibility to attempt to lock a mutex multiple times by the same task without waiting on a mutex. This should handle all reasonable coupling-supplying combinations, especially when two coupled regulators share common supplies. The only situation that should be forbidden is simultaneous coupling and supplying between a pair of regulators. The idea is based on clk core. Signed-off-by: Maciej Purski Signed-off-by: Mark Brown

regulator: core: Allow for regulators that can't be read at bootup

2018-05-17T05:08:37+00:00

Regulators attached via RPMh on Qualcomm sdm845 apparently are write-only. Specifically you can send a request for a certain voltage but you can't read back to see what voltage you've requested. What this means is that at bootup we have absolutely no idea what voltage we could be at. As discussed in the patches to try to support the RPMh regulators [1], the fact that regulators are write-only means that its driver's get_voltage_sel() should return an error code if it's called before any calls to set_voltage_sel(). This causes problems in machine_constraints_voltage() when trying to apply the constraints. A proposed fix was to come up with an error code that could be returned by get_voltage_sel() which would cause the regulator framework to simply try setting the voltage with the current constraints. In this patch I propose the error code -ENOTRECOVERABLE. In errno.h this error is described as "State not recoverable". Though the error code was originally intended "for robust mutexes", the description of the error code seems to apply here because we can't read the state of the regulator. Also note that the only existing user of this error code in the regulator framework is tps65090-regulator.c which returns this error code from the enable() call (not get_voltage() or get_voltage_sel()), so there should be no existing regulators that might accidentally get the new behavior. (Side note is that tps65090 seems to interpret this error code to mean an error that you can't recover from rather than some data that can't be recovered). [1] https://patchwork.kernel.org/patch/10340897/ Signed-off-by: Douglas Anderson Signed-off-by: Mark Brown