On Fri, Jan 16, 2015 at 03:27:00PM +0100, Gregory CLEMENT wrote:

On 16/01/2015 13:37, Mark Brown wrote:

quoted

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.

quoted

quoted

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.

quoted

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150116/291ff5cd/attachment.sig>