On 15 June 2017 at 12:06, Peter Chen <hzpeterchen@xxxxxxxxx> wrote: > On Thu, Jun 15, 2017 at 11:35:20AM +0200, Ulf Hansson wrote: >> On 15 June 2017 at 11:11, Peter Chen <hzpeterchen@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
