On Mon, Apr 29, 2019 at 11:29:05AM +0200, Esben Haabendal wrote: > Andy Shevchenko <andy.shevchenko@xxxxxxxxx> writes: > > On Mon, Apr 29, 2019 at 9:27 AM Esben Haabendal <esben@xxxxxxxxxxxx> wrote: > >> Andy Shevchenko <andy.shevchenko@xxxxxxxxx> writes: > >> > On Sat, Apr 27, 2019 at 12:01 PM Esben Haabendal <esben@xxxxxxxxxxxx> wrote: > >> >> Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> writes: > >> >> > On Fri, Apr 26, 2019 at 06:54:05PM +0200, Esben Haabendal wrote: > >> >> >> Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> writes: > So maybe we should go down that direction intead, extending 8250 driver > to replace mapbase with a resource struct instead? > > > Btw, we have PCI MFD driver which enumerates 8250 (more precisely > > 8250_dw) w/o any issues. > > I am aware of that (sm501.c). It avoids the problem by not requesting > the parent memory region (sm->io_res), and requesting all child memory > regions directly in root instead of relative to the sm->io_res parent. > > But as resoure management is designed for managing a parent/child > resource tree, this looks much more like a workaround than the right > solution. > > >> It would be nice if child drivers requesting memory would pass the > >> parent memory resource. Maybe 8250 driver could be changed to accept a > >> struct resource pointer instead of a simple mapbase value, allowing to > >> setup the resource with parent pointing to the MFD memory resource. > > > > I don't see the problem in certain driver, I guess you are trying to > > workaround existin Linux device resource model. > > No, I actually try to do the right thing in relation to Linux device > resource model. But 8250 is just not behaving very well in that > respect, not having been made really aware of the resource model. The point here is that. MFD driver can re-use existing platform drivers which may be used standalone. They and only they are the right owners of the requesting *their* resources. When parent request resources on the behalf of its child it simple will break this flexibility. -- With Best Regards, Andy Shevchenko
