From: Esben Haabendal <esben@haabendal.dk>
To: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
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@vger.kernel.org
Subject: Re: [PATCH 1/2] serial: 8250: Allow port registration without UPF_BOOT_AUTOCONF
Date: Mon, 29 Apr 2019 08:37:59 +0200 [thread overview]
Message-ID: <87tvehz588.fsf@haabendal.dk> (raw)
In-Reply-To: <7a1fd6cc-050f-a077-6169-03552a89c563@metux.net> (Enrico Weigelt's message of "Sat, 27 Apr 2019 13:57:57 +0200")
"Enrico Weigelt, metux IT consult" <lkml@metux.net> writes:
> On 27.04.19 10:58, Esben Haabendal wrote:
>
> Hi folks,
>
>> That said, the purpose of UPF_BOOT_AUTOCONF (for 8250 driver) is to
>> request and map the register memory. So when that is already done by
>> the parent MFD driver, I think it is silly to workaround problems
>> caused by UPF_BOOT_AUTOCONF being force setted, when it really
>> shouldn't.
> I tend to agree. Maybe we should give serial8250_register_8250_port()
> some flags for controlling this, or add another function for those
> cases.
Changing serial8250_register_8250_port() would break existing drivers,
as I have seen that some explicitly rely on the automtic addition of
UPF_BOOT_AUTOCONF.
> A minimal-invasive approach could be introducing an
> serial8250_register_8250_port_ext() with extra parameters, and let
> serial8250_register_8250_port() just call it.
So basically a rename of __serial8250_register_8250_port() in my patch
to serial8250_register_8250_port_ext()? Fine with me. Should we give
it an EXPORT_SYMBOL() also, as it is just as valid to use in modules as
the current serial8250_register_8250_port()?
/Esben
WARNING: multiple messages have this Message-ID (diff)
From: Esben Haabendal <esben@haabendal.dk>
To: "Enrico Weigelt\, metux IT consult" <lkml@metux.net>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
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@vger.kernel.org
Subject: Re: [PATCH 1/2] serial: 8250: Allow port registration without UPF_BOOT_AUTOCONF
Date: Mon, 29 Apr 2019 08:37:59 +0200 [thread overview]
Message-ID: <87tvehz588.fsf@haabendal.dk> (raw)
In-Reply-To: <7a1fd6cc-050f-a077-6169-03552a89c563@metux.net> (Enrico Weigelt's message of "Sat, 27 Apr 2019 13:57:57 +0200")
"Enrico Weigelt, metux IT consult" <lkml@metux.net> writes:
> On 27.04.19 10:58, Esben Haabendal wrote:
>
> Hi folks,
>
>> That said, the purpose of UPF_BOOT_AUTOCONF (for 8250 driver) is to
>> request and map the register memory. So when that is already done by
>> the parent MFD driver, I think it is silly to workaround problems
>> caused by UPF_BOOT_AUTOCONF being force setted, when it really
>> shouldn't.
> I tend to agree. Maybe we should give serial8250_register_8250_port()
> some flags for controlling this, or add another function for those
> cases.
Changing serial8250_register_8250_port() would break existing drivers,
as I have seen that some explicitly rely on the automtic addition of
UPF_BOOT_AUTOCONF.
> A minimal-invasive approach could be introducing an
> serial8250_register_8250_port_ext() with extra parameters, and let
> serial8250_register_8250_port() just call it.
So basically a rename of __serial8250_register_8250_port() in my patch
to serial8250_register_8250_port_ext()? Fine with me. Should we give
it an EXPORT_SYMBOL() also, as it is just as valid to use in modules as
the current serial8250_register_8250_port()?
/Esben
next prev parent reply other threads:[~2019-04-29 6:37 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 [this message]
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
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=87tvehz588.fsf@haabendal.dk \
--to=esben@haabendal.dk \
--cc=Jisheng.Zhang@synaptics.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bigeasy@linutronix.de \
--cc=darwin.dingel@alliedtelesis.co.nz \
--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=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.