linux-kernel - Re: Regulator: drivers that need to know their supply

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20160410231856.GE18319@sirena.org.uk>
Date:	Mon, 11 Apr 2016 00:18:56 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Martin Fuzzey <mfuzzey@...keon.com>
Cc:	Javier Martinez Canillas <javier@....samsung.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Regulator: drivers that need to know their supply

On Thu, Apr 07, 2016 at 08:17:25PM +0200, Martin Fuzzey wrote:
> On 07/04/16 19:02, Mark Brown wrote:

> >No, this is not sensible.  You should be telling the framework about the
> >slew rate and letting the framework work out how long it's going to take
> >to transition.  Your driver shouldn't be peering around inside other
> >regulators, it should be telling the framework what it does itself and
> >any handling of interrelationships should be in the framework.

> Ok, but I fail to see any way to do that (at least with the framework as
> is).

Then send patches for the framework.  One of the great things about
working on Linux is that the whole OS is free software so you don't have
to work around things in your driver!  I've not looked at the code for
this specific case.

> Or are you saying I should extend the framework to add a .get_ramp_delay
> driver callback and make the framework do the calculation itself?

Yes.

> While moving it to the framework will avoid the driver knowing about other
> regulators it won't fix the underlying issues I mentionned.

> For a regulator configured as always-on the framework doesn't lookup and
> enable the parent  regulators until regulator_register_resolve_supply()
> is caused right at the end of regulator_register().

> This means that, when the always-on register is enabled it has no supply
> assigned, even at the  framework level.

You might find this changing very shortly but in any case the answer is
still the same, change the framework if it needs changing.

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