Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753650AbdFSIKC (ORCPT ); Mon, 19 Jun 2017 04:10:02 -0400 Received: from mail-qk0-f177.google.com ([209.85.220.177]:33259 "EHLO mail-qk0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753545AbdFSIJ7 (ORCPT ); Mon, 19 Jun 2017 04:09:59 -0400 MIME-Version: 1.0 In-Reply-To: <20170615100604.GC24157@b29397-desktop> References: <1497319166-17287-1-git-send-email-peter.chen@nxp.com> <1497319166-17287-3-git-send-email-peter.chen@nxp.com> <20170614015338.GA4635@b29397-desktop> <20170615065854.GA24157@b29397-desktop> <20170615091131.GB24157@b29397-desktop> <20170615100604.GC24157@b29397-desktop> From: Ulf Hansson Date: Mon, 19 Jun 2017 10:09:58 +0200 Message-ID: Subject: Re: [PATCH v15 2/7] power: add power sequence library To: Peter Chen Cc: Peter Chen , Mark Rutland , Heiko Stuebner , Stephen Boyd , frank.li@nxp.com, "linux-kernel@vger.kernel.org" , Gary Bisson , Fabio Estevam , Joshua Clayton , Arnd Bergmann , Dmitry Eremin-Solenikov , Vaibhav Hiremath , Krzysztof Kozlowski , mka@chromium.org, Alan Stern , "devicetree@vger.kernel.org" , "Maciej S. Szmigiero" , Pawel Moll , "linux-pm@vger.kernel.org" , Sascha Hauer , troy.kisky@boundarydevices.com, Rob Herring , "linux-arm-kernel@lists.infradead.org" , hverkuil@xs4all.nl, oscar@naiandei.net, Greg Kroah-Hartman , Linux USB List , "Rafael J. Wysocki" , Sebastian Reichel , Mark Brown , Philipp Zabel , Shawn Guo , jun.li@nxp.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4589 Lines: 104 On 15 June 2017 at 12:06, Peter Chen wrote: > On Thu, Jun 15, 2017 at 11:35:20AM +0200, Ulf Hansson wrote: >> On 15 June 2017 at 11:11, Peter Chen wrote: >> > On Thu, Jun 15, 2017 at 10:11:45AM +0200, Ulf Hansson wrote: >> >> > Yes, you are right. This is the limitation for this power sequence >> >> > library, the registration for the 1st power sequence instance must >> >> > be finished before device driver uses it. I am appreciated that >> >> > you can supply some suggestions for it. >> >> >> >> In general this kind of problems is solved by first parsing the DTB, >> >> which means you will find out whether there is a resource (a pwrseq) >> >> required for the device. Then you try to fetch that resource, and if >> >> that fails, it means the resource is not yet available, and hence you >> >> want to retry later and should return -EPROBE_DEFER. >> >> >> >> In this case, of_pwrseq_on() needs to be converted to start looking >> >> for a pwrseq compatible in it's child node - I guess. Then if that is >> >> found, you try to fetch the instance of the corresponding library. >> >> Failing to fetch the library instance should then cause a return >> >> -EPROBE_DEFER. >> > >> > The most difficulty for this is we can't know whether the requested >> > pwrseq instance will be registered or not, the kernel configuration >> > for this pwrseq library may not be chosen at all. >> >> In such case it is still correct to return -EPROBE_DEFER, because the >> driver that tries to probe its device will fail unless it can run the >> needed pwrseq. Right? >> > > Unlike the MMC design, there is no dts entry to indicate whether this > device needs pwrseq or not at this design, it will only carry out power > on sequence after matching. So, return -EPROBE_DEFER may not work since > this device may never need pwrseq. Then, how will you really be able to fetch the correct pwrseq library instance for the device node? Suppose their is a *list* of pwrseq library instances available. In pwrseq_find_available_instance() you call of_match_node(table, np). The "table" there corresponds to the compatible for the pwrseq library and the np is the device node provided by the caller of of_pwrseq_on(). Why is this match done? Why can't the match be done before trying to fetch a library instance and then in a second step, really try to fetch the instance? If only the second step fails, returning -EPROBE_DEFER can be done, no? BTW, I didn't compatible for the generic pwrseq library being documented in this series. > >> > >> >> >> >> > >> >> >> Moreover, I have found yet another severe problem but reviewing the code: >> >> >> In the struct pwrseq, you have a "bool used", which you are setting to >> >> >> "true" once the pwrseq has been hooked up with the device, when a >> >> >> driver calls of_pwrseq_on(). Setting that variable to true, will also >> >> >> prevent another driver from using the same instance of the pwrseq for >> >> >> its device. So, to cope with multiple users, you register a new >> >> >> instance of the same pwrseq library that got hooked up, once the >> >> >> ->get() callback is about to complete. >> >> >> >> >> >> The problem the occurs, when there is another driver calling >> >> >> of_pwrseq_on() in between, meaning that the new instance has not yet >> >> >> been registered. This will simply fail, won't it? >> >> > >> >> > Yes, you are right, thanks for pointing that, I will add mutex_lock for >> >> > of_pwrseq_on. >> >> >> >> Another option is to entirely skip to two step approach. >> >> >> >> In other words, make the library to cope with multiple users via the >> >> same registered library instance. >> >> >> > >> > No, the pwrseq instance stores dtb information (clock, gpio, etc), it >> > needs to be per device. >> >> I think you misunderstood my suggestion here. Of course you need to >> allocate one pwrseq data per device. >> >> However, my point is that you shouldn't need more than one instance of >> the library functions to be registered in the list of available pwrseq >> libraries. >> > > This additional instance is used to store compatible information for > this pwrseq library, it is used for the next matching between device > and pwrseq library, it just likes we need the first pwrseq instance > registered at boot stage. Why can't the compatible information be a static table, known by the pwrseq core library? Then when of_pwrseq_on() is called, that static table is parsed and matched, then a corresponding pwrseq library instance tries to be fetched. Kind regards Uffe