On Wed, Nov 09, 2016 at 10:36:54AM +0100, Andrzej Hajda wrote: > On 09.11.2016 07:45, Greg Kroah-Hartman wrote: > > On Tue, Nov 08, 2016 at 09:58:24PM +0100, Luis R. Rodriguez wrote: > >>>> Furthermore -- how does this framework compare to Andrzej's resource > >>>> tracking > >>>> solution? I confess I have not had a chance yet to review yet but in > >>>> light of > >>>> this question it would be good to know if Andrzej's framework also > >>>> requires > >>>> deferred probe as similar concerns would exist there as well. > >>> I have no idea what "framework" you are talking about here, do you have > >>> a pointer to patches? > >> I'm surprised given Andrzej did both Cc you on his patches [2] *and* chimed > >> in on Rafael's patches to indicate that we likely can integrate PM concerns > >> into his own "framework" [3]. There was no resolution to this discussion, > >> however > >> its not IMHO sufficient to brush off Andrzej's points in particular because > >> Andrzej *is* indicating that his framework: > > Dude, those patches were from 2014! I can't remember patches people > > sent to me a month ago... > > > >> - Eliminates deferred probe and resulting late_initcall(), consumer > >> registers > >> callbacks informing when given resources (clock, regulator, etc) becomes > >> available > >> - Properly handle resource disappearance (driver unbind, hotplug) > >> - Track resources which are not vital to the device, but can influence > >> behavior > >> - Offers simplified resource allocation > >> - Can be easily expanded to help with power management > >> > >> Granted I have not reviewed this yet but it at least was on my radar, and > >> I do believe its worth reviewing this further given the generally expressed > >> interest to see if we can have a common framework to address both ordering > >> problems, suspend and probe. At a quick glance the "ghost provider" idea > >> seems like a rather crazy idea but hey, there may be some goods in there. > > >From what I remember, and I could be totally wrong, these patches were > > way too complex and required that every subsystem change their > > interfaces. That's not going to work out well, but read the email > > threads for the details... > > I haven't seen your comment on my patches, except few general questions > regarding one of earlier version of the framework. > So maybe you are talking about different framework. > > Regarding complexity, if the subsystem have simple way of > '(un)publishing' resources it just adds single calls to restrack core: > restrack_up, restrack_down in proper places. > Additionally it adds quite simple stuff to encapsulate resource > description and allocation routines into generic *_restrack_desc > structure, see for example patch adding restrack to phy framework[1].
Ok, again, I have no idea what my response was to a 2 year-old patchset, again, I can't remember my response to a patchset that was sent just a month ago... update it, and repost and we can all go from there if you think it is a viable solution. thanks, greg k-h
