On Sat, May 28, 2016 at 11:36:13AM +0800, Peter Chen wrote:

On Tue, May 10, 2016 at 01:02:08PM +0200, Ulf Hansson wrote:

quoted

+ Arnd

[...]

quoted

quoted

quoted

quoted

Solution
========
This is very similar to the MMC pwrseq behavior so the idea is to:
1. Move MMC pwrseq drivers to generic place,

You can do that, but I'm going to NAK any use of pwrseq bindings outside
of MMC. I think it is the wrong way to do things. The DT should describe

Huh, I didn't know that was your view of the mmc pwrseq bindings. Why
didn't you NAK them before?

Unfortunately, either I missed it or it was a time I couldn't spend much
time on reviews.

Okay, I guess it's common issue among maintainers. The problem with DT
is that it gets really hard to be fixed up later. :-)

quoted

quoted

quoted

the devices. If they happen to be "simple" then the core can walk the
tree and do any setup. For example, look for "reset-gpios" and toggle
that GPIO. There is no need for a special node.

quoted

2. Extend the pwrseq-simple with regulator toggling,
3. Add support to USB hub and port core for pwrseq,

We discussed this for USB already[1] and is why we defined how to add
USB child devices. The idea is not to add pwrseq to that.

I am not familiar with the USB discussion.

Still, let me give you some more background to the mmc pwrseq. The
idea from the mmc pwrseq bindings comes from the power-domain DT
bindings, as I thought these things were a bit related.
In both cases they are not directly a property of the device, but more
describing a HW dependency to allow the device to work.

I could see this as a board level power domain. However the difference
is we are not generally exposing internal SOC details the same way as
board level components. Perhaps we could extend power domains to board
level, but that is not what was done here.

quoted

One could probably use a child node instead of a phandle, but that
wasn't chosen back then. Of course you are the DT expert, but could
you perhaps tell me why a child node is better for cases like this?

If there is a control path hierarchy, then we try to model that in DT
with child nodes. In cases of SDIO and USB, there is a clear hierarchy.
Ignoring the discovery ordering problem, we already have defined ways to
describe GPIO connections, regulators, etc. to devices. Describing those
things separately from the device to solve a particular issue that is
really a kernel limitation is what I don't like.

Okay, I see.

To move forward in trying to make mmc pwrseq a generic pwrseq, could
we perhaps allow both cases?

In the mmc case, there are already deployed bindings so we need to
cope with these by using the phandle option, but for USB etc we could
force the child node option.
As long as we agree that we keep using a compatible string for the
child node as well, both options should be able to co-exist and we
should probably be able to managed them both from a common pwrseq
driver framework.

Although, I do remember from an older conversations around some of
mine submission for the mmc pwrseq code, that some people (maybe
Arnd?) wasn't keen on adding a new framework for this. Perhaps that
has changed?

All, how we move on for this?

1. Using a generic driver to manage both mmc and USB (and further
subsystem), USB and further subsystem do not use pwrseq node in dts.
2. USB creates the similar driver under drivers/usb for its own use. 

Which one do you prefer, thanks.

Hi Krzysztof Kozlowski,

I think option 1 may be better according to Rob and Ulf's comment.
Would you like going on your patch set? You can work on generic pwrseq
driver, I will do USB stuffs based on generic pwrseq driver?

-- 

Best Regards,
Peter Chen