On 19/02/2019 17:39, Mark Brown wrote:
> On Tue, Feb 19, 2019 at 05:02:46PM +0100, Marc Gonzalez wrote:
>
>> When REGULATOR_CHANGE_DRMS is not set, drms_uA_update is a no-op.
>> It used to print a debug message, which was dropped in commit
>> 8a34e979f684 ("regulator: refactor valid_ops_mask checking code")
>>
>> Let's bring the debug message back as KERN_INFO, because it is very
>> useful to diagnose missing regulator-allow-set-load properties.
>
> No, it's perfectly normal for machine constraints to stop drivers from
> doing things so we shouldn't warn on this - it would get incredibly
> noisy if we started printing every time constraints didn't let us do
> something at info level. Debug level might be viable, or definitely
> vdbg or trace points.
I had a look at the various REGULATOR_CHANGE_* flags.
#define REGULATOR_CHANGE_VOLTAGE 0x1
#define REGULATOR_CHANGE_CURRENT 0x2
#define REGULATOR_CHANGE_MODE 0x4
#define REGULATOR_CHANGE_STATUS 0x8
#define REGULATOR_CHANGE_DRMS 0x10
#define REGULATOR_CHANGE_BYPASS 0x20
Several functions return an error (and log a KERN_ERR message) if their
corresponding flag is not set:
regulator_check_voltage() REGULATOR_CHANGE_VOLTAGE
regulator_check_current_limit() REGULATOR_CHANGE_CURRENT
regulator_mode_constrain() REGULATOR_CHANGE_MODE
Others succeed silently even if their corresponding flag is not set:
drms_uA_update() REGULATOR_CHANGE_DRMS
regulator_allow_bypass() REGULATOR_CHANGE_BYPASS
Why is setting the voltage handled differently than setting the load?
Regards.
