linux-kernel - Re: [PATCH v6 0/8] power: add power sequence library

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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160824085335.GB27233@shlinux2>
Date:   Wed, 24 Aug 2016 16:53:35 +0800
From:   Peter Chen <hzpeterchen@...il.com>
To:     Vaibhav Hiremath <vaibhav.hiremath@...aro.org>, robh+dt@...nel.org
Cc:     Peter Chen <peter.chen@....com>, gregkh@...uxfoundation.org,
        stern@...land.harvard.edu, ulf.hansson@...aro.org,
        broonie@...nel.org, sre@...nel.org, robh+dt@...nel.org,
        shawnguo@...nel.org, dbaryshkov@...il.com, dwmw3@...radead.org,
        mark.rutland@....com, devicetree@...r.kernel.org,
        k.kozlowski@...sung.com, linux-usb@...r.kernel.org,
        oscar@...andei.net, pawel.moll@....com, arnd@...db.de,
        linux-pm@...r.kernel.org, festevam@...il.com,
        s.hauer@...gutronix.de, stephen.boyd@...aro.org,
        linux-kernel@...r.kernel.org, troy.kisky@...ndarydevices.com,
        stillcompiling@...il.com, p.zabel@...gutronix.de,
        mail@...iej.szmigiero.name, mka@...omium.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v6 0/8] power: add power sequence library

On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:
> 
> 
> On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
> >Hi all,
> >
> >This is a follow-up for my last power sequence framework patch set [1].
> >According to Rob Herring and Ulf Hansson's comments[2], I use a generic
> >power sequence library for parsing the power sequence elements on DT,
> >and implement generic power sequence on library. The host driver
> >can allocate power sequence instance, and calls pwrseq APIs accordingly.
> >
> >In future, if there are special power sequence requirements, the special
> >power sequence library can be created.
> >
> >This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> >two hot-plug devices to simulate this use case, the related binding
> >change is updated at patch [1/6], The udoo board changes were tested
> >using my last power sequence patch set.[3]
> >
> >Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> >need to power on itself before it can be found by ULPI bus.
> >
> >[1] http://www.spinics.net/lists/linux-usb/msg142755.html
> >[2] http://www.spinics.net/lists/linux-usb/msg143106.html
> >[3] http://www.spinics.net/lists/linux-usb/msg142815.html
> (Please ignore my response on V2)
> 
> Sorry being so late in the discussion...
> 
> If I am not missing anything, then I am afraid to say that the
> generic library
> implementation in this patch series is not going to solve many of
> the custom
> requirement of power on, off, etc...
> I know you mentioned about adding another library when we come
> across such platforms, but should we not keep provision (or easy
> hooks/path)
> to enable that ?
> 
> Let me bring in the use case I am dealing with,
> 
> 
>                               Host
>                                |
>                                V
>                            USB port
> ------------------------------------------------------------
>                                |
>                                V
>                       USB HUB device (May need custom on/off seq)
>                                |
>                                V
>               =============================
>              |                             |
>              V                             V
>          Device-1                       Device-2
> (Needs special power               (Needs special power
>  on/off sequence.                   on/off sequence.
>  Also may need custom               Also, may need custom
>  sequence for                       sequence for
>  suspend/resume)                    suspend/resume)
> 
> 
> Note: Both Devices are connected to HUB via HSIC and may differ
>           in terms of functionality, features they support.
> 
> In the above case, both Device-1 and Device-2, need separate
> power on/off sequence. So generic library currently we have in this
> patch series is not going to satisfy the need here.
> 
> I looked at all 6 revisions of this patch-series, went through the
> review comments, and looked at MMC power sequence code;
> what I can say here is, we need something similar to
> MMC power sequence here, where every device can have its own
> power sequence (if needed).
> 
> I know Rob is not in favor of creating platform device for
> this, and I understand his comment.
> If not platform device, but atleast we need mechanism to
> connect each device back to its of_node and its respective
> driver/library fns. For example, the Devices may support different
> boot modes, and platform driver needs to make sure that
> the right sequence is followed for booting.
> 
> Peter, My apologies for taking you back again on this series.
> I am OK, if you wish to address this in incremental addition,
> but my point is, we know that the current generic way is not
> enough for us, so I think we should try to fix it in initial phase only.
> 

Rob, it seems generic power sequence can't cover all cases.
Without information from DT, we can't know which power sequence
for which device.

-- 

Best Regards,
Peter Chen