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]
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ