From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Esben Haabendal <esben@haabendal.dk>
Cc: "open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jslaby@suse.com>,
Darwin Dingel <darwin.dingel@alliedtelesis.co.nz>,
He Zhe <zhe.he@windriver.com>,
Jisheng Zhang <Jisheng.Zhang@synaptics.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] serial: 8250: Allow port registration without UPF_BOOT_AUTOCONF
Date: Mon, 29 Apr 2019 16:35:35 +0300 [thread overview]
Message-ID: <20190429133535.GG9224@smile.fi.intel.com> (raw)
In-Reply-To: <87ef5lxiqm.fsf@haabendal.dk>
On Mon, Apr 29, 2019 at 11:29:05AM +0200, Esben Haabendal wrote:
> Andy Shevchenko <andy.shevchenko@gmail.com> writes:
> > On Mon, Apr 29, 2019 at 9:27 AM Esben Haabendal <esben@haabendal.dk> wrote:
> >> Andy Shevchenko <andy.shevchenko@gmail.com> writes:
> >> > On Sat, Apr 27, 2019 at 12:01 PM Esben Haabendal <esben@haabendal.dk> wrote:
> >> >> Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:
> >> >> > On Fri, Apr 26, 2019 at 06:54:05PM +0200, Esben Haabendal wrote:
> >> >> >> Andy Shevchenko <andriy.shevchenko@linux.intel.com> 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
next prev parent reply other threads:[~2019-04-29 13:35 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-26 8:40 [PATCH 0/2] serial: 8250: Add support for 8250/16550 as MFD function Esben Haabendal
2019-04-26 8:40 ` [PATCH 1/2] serial: 8250: Allow port registration without UPF_BOOT_AUTOCONF Esben Haabendal
2019-04-26 14:39 ` Andy Shevchenko
2019-04-26 16:54 ` Esben Haabendal
2019-04-26 21:51 ` Andy Shevchenko
2019-04-27 8:58 ` Esben Haabendal
2019-04-27 11:57 ` Enrico Weigelt, metux IT consult
2019-04-29 6:37 ` Esben Haabendal
2019-04-27 16:41 ` Andy Shevchenko
2019-04-29 6:27 ` Esben Haabendal
2019-04-29 8:33 ` Andy Shevchenko
2019-04-29 9:29 ` Esben Haabendal
2019-04-29 12:56 ` Enrico Weigelt, metux IT consult
2019-04-29 13:35 ` Andy Shevchenko [this message]
2019-04-29 14:25 ` Esben Haabendal
2019-04-26 8:40 ` [PATCH 2/2] serial: 8250: Add support for 8250/16550 as MFD function Esben Haabendal
2019-05-07 11:49 ` Lee Jones
2019-05-07 12:04 ` Esben Haabendal
2019-05-07 13:38 ` Lee Jones
2019-05-14 8:00 ` Esben Haabendal
2019-05-14 10:47 ` Lee Jones
2019-05-14 12:26 ` Greg Kroah-Hartman
2019-05-14 12:41 ` Esben Haabendal
2019-05-21 10:09 ` Greg Kroah-Hartman
2019-05-21 11:11 ` Esben Haabendal
2019-05-21 11:18 ` Greg Kroah-Hartman
2019-05-21 11:50 ` Esben Haabendal
2019-05-21 12:56 ` Greg Kroah-Hartman
2019-05-21 14:31 ` Esben Haabendal
2019-05-21 14:43 ` Greg Kroah-Hartman
2019-05-27 19:56 ` Enrico Weigelt, metux IT consult
2019-04-26 14:35 ` [PATCH 0/2] " Andy Shevchenko
2019-04-26 16:57 ` Esben Haabendal
2019-04-26 17:21 ` Andy Shevchenko
-- strict thread matches above, loose matches on Subject: below --
2019-04-26 8:36 [PATCH 1/2] serial: 8250: Allow port registration without UPF_BOOT_AUTOCONF Esben Haabendal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190429133535.GG9224@smile.fi.intel.com \
--to=andy.shevchenko@gmail.com \
--cc=Jisheng.Zhang@synaptics.com \
--cc=bigeasy@linutronix.de \
--cc=darwin.dingel@alliedtelesis.co.nz \
--cc=esben@haabendal.dk \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=zhe.he@windriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).