Re: [PATCH 1/2] serial: 8250: Allow port registration without UPF_BOOT_AUTOCONF
From: Andy Shevchenko
Date: Mon Apr 29 2019 - 09:35:42 EST
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