BMC/Intel-BMC/linux.git/drivers/regulator/core.c, branch dev-4.10

regulator: Fix regulator_summary for deviceless consumers

2017-03-12T05:44:09+00:00

commit e42a46b6f52473661ad192f76a128a68fe301df4 upstream. It is allowed to call regulator_get with a NULL dev argument (_regulator_get explicitly checks for it) but this causes an error later when printing /sys/kernel/debug/regulator_summary. Fix this by explicitly handling "deviceless" consumers in the debugfs code. Signed-off-by: Leonard Crestez Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

Merge remote-tracking branches 'regulator/topic/arizona', 'regulator/topic/bypass', 'regulator/topic/error' and 'regulator/topic/fixed' into regulator-next

2016-12-12T12:17:24+00:00

Merge remote-tracking branch 'regulator/topic/core' into regulator-next

2016-12-12T12:17:23+00:00

regulator: core: add newline in debug message

2016-12-05T11:31:30+00:00

This adds a trailing newline to a debug message. Signed-off-by: David Lechner Signed-off-by: Mark Brown

regulator: core: Correct type of mode in regulator_mode_constrain

2016-11-30T17:44:16+00:00

Every function handling the mode within the regulator core uses an unsigned int for mode, except for regulator_mode_constrain. This patch changes the type of mode within regulator_mode_constrain which fixes several instances where we are passing pointers to unsigned ints then treating them as an int within this function. Signed-off-by: Charles Keepax Signed-off-by: Mark Brown

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

2016-11-04T18:15:25+00:00

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: core: silence warning: "VDD1: ramp_delay not set"

2016-10-28T17:22:40+00:00

commit 73e705bf81ce ("regulator: core: Add set_voltage_time op") introduced a new rdev_warn() if the ramp_delay is 0. Apparently, on omap3/twl4030 platforms with dynamic voltage management this results in non-ending spurious messages like [ 511.143066] VDD1: ramp_delay not set [ 511.662322] VDD1: ramp_delay not set [ 513.903625] VDD1: ramp_delay not set [ 514.222198] VDD1: ramp_delay not set [ 517.062835] VDD1: ramp_delay not set [ 517.382568] VDD1: ramp_delay not set [ 520.142791] VDD1: ramp_delay not set [ 520.502593] VDD1: ramp_delay not set [ 523.062896] VDD1: ramp_delay not set [ 523.362701] VDD1: ramp_delay not set [ 526.143035] VDD1: ramp_delay not set I have observed this on GTA04 while it is reported to occur on N900 as well: https://bugzilla.kernel.org/show_bug.cgi?id=178371 This patch makes the warning appear only in debugging mode. Signed-off-by: H. Nikolaus Schaller Signed-off-by: Mark Brown

Merge remote-tracking branches 'regulator/topic/of', 'regulator/topic/pv88080', 'regulator/topic/rk808', 'regulator/topic/set-voltage' and 'regulator/topic/tps65218' into regulator-next

2016-09-30T16:13:58+00:00

Merge remote-tracking branches 'regulator/topic/bulk', 'regulator/topic/dbx500', 'regulator/topic/hi6421', 'regulator/topic/load' and 'regulator/topic/ltc3676' into regulator-next

2016-09-30T16:13:55+00:00

regulator: core: don't return error with inadequate reason

2016-09-24T18:36:41+00:00

drms_uA_update() always returns failure when it cannot find regulator's input voltage. But if hardware supports load configuration with ops->set_load() and the input regulator isn't specified with valid reason such as the input regulator is battery, not finding input voltage is normal so such case should not return with an error. Avoid such inadequate error return by checking input/output voltages only when drms_uA_update() is about to configure load with enum based ops->set_mode(). Cc: Liam Girdwood Cc: Mark Brown Cc: Bjorn Andersson Cc: linux-kernel@vger.kernel.org Signed-off-by: Joonwoo Park Signed-off-by: Mark Brown