linux-kernel - Re: Question about regulator API

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]

Message-ID: <20161219110936.c3acatecdqdvzq7b@sirena.org.uk>
Date:   Mon, 19 Dec 2016 11:09:36 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Harald Geyer <harald@...ib.org>
Cc:     Liam Girdwood <lgirdwood@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: Question about regulator API

On Fri, Dec 16, 2016 at 11:00:35PM +0100, Harald Geyer wrote:
> Mark Brown writes:

> > > I was hoping, that I somehow could get the necessary coordination from
> > > the regulator framework. If the best I can get ATM is notifications, then
> > > I'll try it and see what kind of code falls out of this.

> Ok, tried that and it turns out there is no notification at
> regulator_enable() ATM. I guess you'd merge a patch that added this
> notification?

Probably.

> Sure, this is why regulator_force_disable() is the wrong tool for the job.
> I was more looking for something (call it regulator_shutdown()) that
> * blocked until the regulator is actually off
> * made all calls to regulator_enable() from other consumers block (or fail)
> * maybe sent notifications to consumers, so that they have a chance to
>   cooperate and call regulator_disable() at their earliest convenience.
> * was undone by a call to either regulator_disable() or regulator_enable()
>   from the consumer that initially called regulator_shutdown()

> I haven't explored this in detail - maybe there are good reasons not to
> have it.

That sounds like a complete mess from a user point of view - unless the
other devices are actually cooperating it's going to have the same
effect as doing nothing at all except it'll block the initiating
consumer and possibly others doing enables, and as far as I can see it
doesn't solve your problems with needing the regulator to be powered off
for a specific amount of time.  If it made enable calls block it'd be
very disruptive for other users as they would suddenly find operations
taking vastly longer than they were expecting which could end up being
visible all the way back up to userspace.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)