Re: [PATCH v1] regulator: core: Log forbidden DRMS operation

[Marc Gonzalez]

[ SMTP server blocked by spamcop -- trying a different one ]

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.