All of lore.kernel.org
 help / color / mirror / Atom feed
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

  parent reply	other threads:[~2019-04-29 13:35 UTC|newest]

Thread overview: 39+ 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-29  6:37               ` Esben Haabendal
2019-04-27 16:41           ` Andy Shevchenko
2019-04-29  6:27             ` Esben Haabendal
2019-04-29  6:27               ` Esben Haabendal
2019-04-29  8:33               ` Andy Shevchenko
2019-04-29  9:29                 ` Esben Haabendal
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-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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.