All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Esben Haabendal <esben@haabendal.dk>
Cc: linux-serial@vger.kernel.org, Enrico Weigelt <lkml@metux.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.com>,
	Darwin Dingel <darwin.dingel@alliedtelesis.co.nz>,
	Jisheng Zhang <Jisheng.Zhang@synaptics.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	He Zhe <zhe.he@windriver.com>, Marek Vasut <marex@denx.de>,
	Douglas Anderson <dianders@chromium.org>,
	Paul Burton <paul.burton@mips.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] serial: 8250: Add support for using platform_device resources
Date: Thu, 2 May 2019 13:45:56 +0300	[thread overview]
Message-ID: <20190502104556.GS9224@smile.fi.intel.com> (raw)
In-Reply-To: <874l6efxta.fsf@haabendal.dk>

On Wed, May 01, 2019 at 09:17:37AM +0200, Esben Haabendal wrote:
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:

> > Hmm... Currently it's done inside individual port drivers, like 8250_dw.c.
> > Each of the drivers can do it differently, for example 8250_lpss.c or
> > 8250_pnp.c.
> 
> So, you would prefer to create a new "specialized" port driver that uses
> platform resources?  I am not doing anything else different from
> the generic port driver here in 8250_core.c.

If it's required and using serial8250 directly is not enough.

> >> +				if (!(port->flags & UPF_DEV_RESOURCES))
> >> +					release_mem_region(port->mapbase, size);
> >
> > This is again same issue. The parent should not request resource it
> > doesn't use.
> 
> Yes, this is same issue.
> 
> But the last part is not true.  A parent mfd driver might "use" a memory
> resource for the sole purpose of splitting it up for it's mfd child
> devices.  This is a core part of mfd framework, and not something I am
> inventing with this patch.  I am just trying to make it possible to use
> 8250 driver in that context.
> 
> > I think I understand what is a confusion here.
> >
> > For the IO resources we have two operations:
> > - mapping / re-mapping (may be shared)
> > - requesting (exclusive)
> >
> > In the parenthesis I put a level of access to it. While many device
> > drivers can *share* same resource (mapped or unmapped), the only one
> > can actually request it.
> 
> Mostly true.  But there is an important twist to the exclusive restriction.
> 
> The exclusive part of the request is limited to the the same root/parent
> resource.
> 
> When you request a memory resource from the root resource
> (iomem_resource), the resource returned can be used as a new parent
> resource.  This new parent can then be used to give exclusive access to
> slices of that resource.  When used like that, I expect that the parent
> resource is not supposed to be used for anything else than honoring
> resource requests.
> 
> And this is exactly what mfd-core uses the mem_base argument
> in mfd_add_devices().
> 
> > So, the parent can take an slice resources as it would be
> > appropriated, but not requesting them.
> 
> The parent is not and should not be doing that by itself.  The request
> is done on by mfd-core when mfd_add_devices() is called.

No, MFD *does not* (and actually *may not* in order to allow standalone drivers
to be used as children w/o modifications) request resources. It just passes
them to children as parent suggested.

> > OTOH, it's possible to have a (weird) MFD case where parent *requested*
> > resources, and *all* of its children are aware of that.
> 
> I am not sure what you mean with this, but mfd drivers should not pass
> along it's intire requested memory resource(s) to child devices.  The
> child devices will get the requested resource slices, as implemented by
> mfd_add_devices().
> 
> I hope you can see that I am not violating any fundamental design
> decissions here, but actually try adhere to them (resource management,
> platform_device resource management, and mfd-core).

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2019-05-02 10:46 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-30 14:04 [PATCH] serial: 8250: Add support for using platform_device resources Esben Haabendal
2019-04-30 15:37 ` Andy Shevchenko
2019-05-01  7:17   ` Esben Haabendal
2019-05-02 10:45     ` Andy Shevchenko [this message]
2019-05-02 12:41       ` Esben Haabendal
2019-05-02 15:31         ` Andy Shevchenko
2019-05-06 15:46           ` Esben Haabendal
2019-05-06 16:44             ` Andy Shevchenko
2019-05-06 17:40               ` Esben Haabendal
2019-05-06 21:04                 ` Andy Shevchenko
2019-05-07  9:32         ` Lee Jones
2019-05-07  9:36           ` Lee Jones
2019-05-07 11:32             ` Esben Haabendal
2019-05-07 11:35           ` Esben Haabendal
2019-05-07 11:53             ` Andy Shevchenko
2019-05-07 12:22               ` Esben Haabendal
2019-05-07 15:08                 ` Andy Shevchenko
2019-05-14  7:22                   ` Esben Haabendal
2019-05-14  9:23                     ` Andy Shevchenko
2019-05-14  9:37                       ` Andy Shevchenko
2019-05-14 12:02                         ` Esben Haabendal
2019-05-14 12:02                           ` Esben Haabendal
2019-05-14 12:42                           ` Andy Shevchenko
2019-05-14 12:02                       ` Esben Haabendal
2019-05-14 12:02                         ` Esben Haabendal
2019-05-14 12:38                         ` Andy Shevchenko
2019-05-14  7:37                   ` Esben Haabendal
2019-05-02 19:41 ` Enrico Weigelt, metux IT consult
2019-05-06 15:19   ` Esben Haabendal
2019-05-06 15:19     ` Esben Haabendal
2019-05-21 11:34 ` [PATCH resend] " Esben Haabendal
2019-05-21 12:42   ` Andy Shevchenko
2019-05-21 14:43     ` Esben Haabendal
2019-05-21 17:03       ` Andy Shevchenko
2019-05-21 13:11   ` Greg Kroah-Hartman
2019-05-21 14:45     ` Esben Haabendal
2019-05-21 14:53       ` Greg Kroah-Hartman
2019-06-11 18:11       ` Enrico Weigelt, metux IT consult

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=20190502104556.GS9224@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=Jisheng.Zhang@synaptics.com \
    --cc=bigeasy@linutronix.de \
    --cc=darwin.dingel@alliedtelesis.co.nz \
    --cc=dianders@chromium.org \
    --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=lkml@metux.net \
    --cc=marex@denx.de \
    --cc=paul.burton@mips.com \
    --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.