linux-kernel - Re: [RFC 1/3] regulator: core: Add over current changed event

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]

Date:   Sat, 29 Oct 2016 10:50:05 +0200
From:   Axel Haslam <ahaslam@...libre.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Kevin Hilman <khilman@...libre.com>,
        Sekhar Nori <nsekhar@...com>,
        David Lechner <david@...hnology.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC 1/3] regulator: core: Add over current changed event

Hi Mark,

On Fri, Oct 28, 2016 at 9:41 PM, Axel Haslam <ahaslam@...libre.com> wrote:
> Hi Mark,
>
> On Fri, Oct 28, 2016 at 8:22 PM, Mark Brown <broonie@...nel.org> wrote:
>> On Wed, Oct 26, 2016 at 09:00:52PM +0200, ahaslam@...libre.com wrote:
>>> From: Axel Haslam <ahaslam@...libre.com>
>>>
>>> Regulator consumers may be interested to know when the
>>> over current condition is over.
>>>
>>> Add an over currerent "changed" event. The registered useres
>>> for this event can then check the over current flag to know
>>> the status of the over current condition.
>>
>> Would a more general event for error conditions work as well?  Thinking
>> about this I'm unclear how interested consumers are going to be in the
>> specific error condition as opposed to the fact that the regulator ran
>> into trouble, and I can imagine that some regulators will report the
>> same root cause differently - another regulator might detect an
>> excessive current draw by seeing the output voltage collapse and the
>> regulator go out of regulation for example.
>

After some more thought,

I can change the logic a bit, and send an event named something like:

REGULATOR_EVENT_ERRORS_CLEARED

would that make more sense?

-Axel.


> Sorry if i misunderstood, but if we make the name generic,
> i think it might change a bit the definition of the flags,
> The flags will not represent events, but states.
>
> i think today each time an event occurs a notification is sent with the
> corresponding flag(s) set.
>
> if we use a generic name, It means that each time the regulator driver
> sends an event, it should check which "other" error conditons tied to the
> generic flag are present and set the corresponding bits too.
>
> illustrative example:
> today over current and over temp are two different events
> we send one notification for each with only the bits tied to the
> event that is happening set.
>
> if we add a generic error flag, it would mean that if over current happens
> and we set the generic error flag, we would also have to check
> if over temp is present to set or not that flag. similarly, when the over
> temp event happens the regulator driver would have to check if over
> current is present too.
>