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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aac7535e-b27f-60be-ed9d-408ed6f869b5@free.fr>
Date:   Thu, 21 Feb 2019 10:37:55 +0100
From:   Marc Gonzalez <marc.w.gonzalez@...e.fr>
To:     Mark Brown <broonie@...nel.org>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        MSM <linux-arm-msm@...r.kernel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Jeffrey Hugo <jhugo@...eaurora.org>,
        Evan Green <evgreen@...omium.org>,
        Douglas Anderson <dianders@...omium.org>
Subject: Re: [PATCH v1] regulator: core: Log forbidden DRMS operation

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.