[PATCH v2 1/6] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Joshua Clayton]

On 07/13/2016 01:42 AM, Peter Chen wrote:
> On Wed, Jul 13, 2016 at 09:27:31AM +0200, Philipp Zabel wrote:
>> Am Mittwoch, den 13.07.2016, 10:06 +0800 schrieb Peter Chen:
>>> Add binding doc for generic power sequence library.
>>>
>>> Signed-off-by: Peter Chen <peter.chen at nxp.com>
>>> ---
>>>  .../bindings/power/pwrseq/pwrseq-generic.txt       | 53 ++++++++++++++++++++++
>>>  1 file changed, 53 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
>>> new file mode 100644
>>> index 0000000..186c58c
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
>>> @@ -0,0 +1,53 @@
>>> +The generic power sequence library
>>> +
>>> +Some hard-wired USB/MMC devices need to do power sequence to let the
>>> +device work normally,
>> I would replace "to let the device work normally" with "before the
>> device can be enumerated [on the bus]" here.
>>
> Ok.
>
>>>  the typical power sequence like: enable USB
>>> +PHY clock, toggle reset pin, etc. But current Linux USB driver
>>> +lacks of such code to do it, it may cause some hard-wired USB devices
>>> +works abnormal or can't be recognized by controller at all. The
>>> +power sequence will be done before this device can be found at USB
>>> +bus.
>>> +
>>> +The power sequence properties is under the device node.
>>> +
>>> +Required properties:
>>> +- power-sequence: this device needs to do power sequence before enumeration
>> As Joshua pointed out, is this even needed at all?
>>
> If no, how we decide whether allocates pwrseq instance through pwrseq
> library or not?
>
The pwrseq driver is Linux specific. The dts is supposed to be OS agnostic.
It seems to me that If a driver supports pwrseq and the dts elements
are there, it should use them, e.g. if there is a clock, enable the clock.
if there is a reset gpio then take the device into and out of reset during probe.

Can you see a  problem with that approach?