All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Esben Haabendal <esben@haabendal.dk>
Cc: linux-serial@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.com>, Nishanth Menon <nm@ti.com>,
	Vignesh R <vigneshr@ti.com>, Tony Lindgren <tony@atomide.com>,
	Lokesh Vutla <lokeshvutla@ti.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] serial: 8250: Add support for 8250/16550 as MFD function
Date: Tue, 7 May 2019 14:38:44 +0100	[thread overview]
Message-ID: <20190507133844.GA6194@dell> (raw)
In-Reply-To: <87o94ejwrx.fsf@haabendal.dk>

On Tue, 07 May 2019, Esben Haabendal wrote:

> Lee Jones <lee.jones@linaro.org> writes:
> 
> > On Fri, 26 Apr 2019, Esben Haabendal wrote:
> >
> >> The serial8250-mfd driver is for adding 8250/16550 UART ports as functions
> >> to an MFD driver.
> >> 
> >> When calling mfd_add_device(), platform_data should be a pointer to a
> >> struct plat_serial8250_port, with proper settings like .flags, .type,
> >> .iotype, .regshift and .uartclk.  Memory (or ioport) and IRQ should be
> >> passed as cell resources.
> >
> > What?  No, please!
> >
> > If you *must* create a whole driver just to be able to use
> > platform_*() helpers (which I don't think you should), then please
> > call it something else.  This doesn't have anything to do with MFD.
> 
> True.
> 
> I really don't think it is a good idea to create a whole driver just to
> be able to use platform_get_*() helpers.  And if I am forced to do this,
> because I am unable to convince Andy to improve the standard serial8250
> driver to support that, it should be called MFD.  The driver would be

I assume you mean "shouldn't"?

> generally usable for all usecases where platform_get_*() works.
> 
> I don't have any idea what to call such a driver.  It really would just
> be a fork of the current serial8250 driver, just allowing use of
> platform_get_*(), supporting exactly the same hardware.
> 
> I am still hoping that we can find a way to improve serial8250 to be
> usable in these cases.

Me too.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2019-05-07 13:38 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
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 [this message]
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 16:55 [PATCH 2/2] " 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=20190507133844.GA6194@dell \
    --to=lee.jones@linaro.org \
    --cc=esben@haabendal.dk \
    --cc=f.fainelli@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=lokeshvutla@ti.com \
    --cc=nm@ti.com \
    --cc=tony@atomide.com \
    --cc=vigneshr@ti.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.