linux-kernel - Re: [PATCH v4 4/4] ARM: mvebu: Armada 385 GP: Add regulators to the SATA port

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]

Message-ID: <20150116153451.GA3856@sirena.org.uk>
Date:	Fri, 16 Jan 2015 15:34:51 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Gregory CLEMENT <gregory.clement@...e-electrons.com>
Cc:	Hans de Goede <hdegoede@...hat.com>, Tejun Heo <tj@...nel.org>,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org,
	Antoine Ténart 
	<antoine.tenart@...e-electrons.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	Ezequiel Garcia <ezequiel.garcia@...e-electrons.com>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Boris BREZILLON <boris.brezillon@...e-electrons.com>,
	Jason Cooper <jason@...edaemon.net>,
	Andrew Lunn <andrew@...n.ch>,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	linux-arm-kernel@...ts.infradead.org,
	Lior Amsalem <alior@...vell.com>,
	Tawfik Bayouk <tawfik@...vell.com>,
	Nadav Haklai <nadavh@...vell.com>,
	Mark Rutland <mark.rutland@....com>, devicetree@...r.kernel.org
Subject: Re: [PATCH v4 4/4] ARM: mvebu: Armada 385 GP: Add regulators to the
 SATA port

On Fri, Jan 16, 2015 at 03:27:00PM +0100, Gregory CLEMENT wrote:
> On 16/01/2015 13:37, Mark Brown wrote:

> > regulator-always-on is a bit fuzzy for suspend, if the regulator has
> > suspend control it'll kick in - it's really about the Linux refcounting
> > while it's running.  What's more concerning here is that the quick
> > sample of the regulators flagged as always on like the above that I
> > looked at in the patch don't seem to have any enable control in the DT
> > so this will have absolutely no effect.

> Actually the reg_sata[0-4] are controlled by gpio, so there is a mean
> to enable/disable them. For the reg_5v_sata[0-4] and reg_12v_sata[0-4]
> they depend on their respective reg_sata and I just propagated the
> regulator-always-on, this was maybe a mistake.

It certainly makes everything confusing if you have control related
stuff on regulators that are not directly controllable.

> >> It is probably a good idea to use regulator-boot-on and
> >> then test things this way, and if that works use
> >> regulator-boot-on.

> > No, it's unlikely that boot-on makes sense here - it's there for cases
> > where we can't read back the hardware state at power on.  Generally
> > drivers should work regardless of the initial state of the regulator
> > (and modular drivers will actually break if they try to rely on boot-on
> > since we clean up unused regulators at boot).

> As pointed by Hans my concern here was be sure that during boot the disk
> are not power off. In this case which property would be accurate?

None, the core won't do anything with the regulator until the end of
init anyway.

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