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] [day] [month] [year] [list]

Date:   Tue, 1 Nov 2016 16:47:33 +0100
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 Mon, Oct 31, 2016 at 5:22 PM, Mark Brown <broonie@...nel.org> wrote:
> On Sun, Oct 30, 2016 at 01:02:21PM +0100, Axel Haslam wrote:
>
>> The event  REGULATOR_EVENT_OVER_CURRENT allready exists.
>> what is missing and what i would need form the usb driver, is a way for
>> the consumer to know that the over current condition is over.
>> since i cannot do this with get mode, and get status is not exported,
>
>> We can do this adding a more generic event flag:
>> REGULATOR_EVENT_ERRORS_CLEARED
>
>> that would be sent by the supply when all errors are over, and the
>> regulator is back to  normal operation.
>
> That's a different thing and definitely not what you were saying in the
> changelog.  I don't think this is something that it makes sense to do
> with events as it's not something that devices will tend to generate
> interrupts for, anything that is going to rely on events for that is
> going to be broken.  Hardware is mostly designed with the idea that
> errors are catastrophic.
>
> If you really care about things clearing then you need to add a sensible
> interface for exposting all the possible error conditions that users can
> poll.  The reason get_mode() got rejected was that error statuses and
> modes are completely different things, get_status() is not going to work
> for you since it is very common for multiple errors to happen at the
> same time.

Ok, sorry if i was unclear in the change log.
ill add a new interface and lets see if it makes more sense in v2.

Regards
Axel.