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:	Fri, 25 Mar 2016 17:47:50 +0100
From:	Sebastian Reichel <sre@...nel.org>
To:	Mark Brown <broonie@...nel.org>
Cc:	Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>, tony@...mide.com,
	lgirdwood@...il.com, linux-omap@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] regulator: twl: Enable regulators over the powerbus as
 well

Hi,

On Fri, Mar 25, 2016 at 03:54:19PM +0000, Mark Brown wrote:
> On Fri, Mar 25, 2016 at 04:02:59PM +0100, Sebastian Reichel wrote:
> > On Fri, Mar 25, 2016 at 11:17:57AM +0000, Mark Brown wrote:
> > > On Wed, Mar 23, 2016 at 09:22:36PM +0200, Ivaylo Dimitrov wrote:
> 
> > > > Assigning a device group to a regulator does not change its state. To
> > > > change the state of a regulator a message over the powerbus is required.
> > > > Also, the check for the current state of a regulator should not count on
> > > > a device group being assigned, but on the current resource state.
> 
> > > How did this driver ever work then?  It sounds like there must be
> > > something else going on here.
> 
> > From my understanding of the twl4030 TRM assigning a device group
> > means "<device group> wants this regulator enabled". It does not
> > change the regulator mode (sleep vs normal or in regulator-framework
> > terms: REGULATOR_STATUS_NORMAL vs REGULATOR_STATUS_STANDBY).
> 
> > It usually works, since the default state is normal. If the system
> > is rebooted from a non-mainline kernel, which left the regulator in
> > sleep/standby, nothing in the kernel switches it to normal.
> 
> I really can't tell how anyone could get from the changelog to what
> you're saying about modes.  The explanation needs to be *much* clearer.
> 
> Part of the confusion is that if you're trying to do something to do
> with the mode support that really needs to use the mode APIs, enabling
> or disabling the regulator should not silently change the mode.

I just tried to describe what's going on, so that you can see the
whole picture. I don't agree with the patch and think that the mode
should be switched to normal at probe time. I assumed, that you
would suggest the correct solution if I describe the problem.

-- Sebastian

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ