From: Peter Hurley <peter@hurleysoftware.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
Jiri Slaby <jslaby@suse.cz>,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Tony Lindgren <tony@atomide.com>,
Grant Likely <grant.likely@linaro.org>
Subject: Re: [PATCH] serial: 8250: Make ISA ports optional
Date: Tue, 06 Jan 2015 16:47:55 -0500 [thread overview]
Message-ID: <54AC580B.2050809@hurleysoftware.com> (raw)
In-Reply-To: <6786513.g26uGMFKLE@wuerfel>
On 01/06/2015 02:43 PM, Arnd Bergmann wrote:
> On Tuesday 06 January 2015 09:32:02 Peter Hurley wrote:
>> On 01/06/2015 08:13 AM, Arnd Bergmann wrote:
>>> On Monday 05 January 2015 22:09:45 Peter Hurley wrote:
>>>> Some arches have no need to create unprobed 8250 ports; these phantom
>>>> ports are primarily required for ISA ports which have no probe
>>>> mechanism or to provide non-operational ports for userspace to
>>>> configure (via TIOCSSERIAL and TIOCSERCONFIG ioctls).
>>>>
>>>> Provide CONFIG_SERIAL_8250_PHANTOM_UARTS knob to disable phantom port
>>>> registration; ie., CONFIG_SERIAL_8250_PHANTOM_UARTS=N only registers
>>>> probed ports (ACPI/PNP, "serial8250" platform devices, PCI, etc).
>>>>
>>>> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>>>> Cc: Tony Lindgren <tony@atomide.com>
>>>> Cc: Grant Likely <grant.likely@linaro.org>
>>>> Cc: Arnd Bergmann <arnd@arndb.de>
>>>> Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
>>>
>>> The intent is definitely right, but I think a better approach is
>>> possible.
>>>
>>> I haven't tried it here, but how about moving the serial8250_init
>>> function into a separate module, along with all the other parts
>>> that are only used for ISA devices, but leaving the actual core
>>> (all exported symbols) in this file?
>>
>> Unfortunately, I don't see a way to remove the stacked initialization
>> without risking tons of breakage.
>>
>> Since later probes can "find" an already-existing port and
>> re-initialize it, the probe order is crucial. For example, a PCI
>> probe can "find" an existing "serial8250" platform device port,
>> resulting in only one device node.
>
> I'm probably missing something important, by why would that
> be any different if the PCI driver gets loaded first and the
> ISA driver second?
Well, the PCI driver would have the proper irq, for one. So, if the
the platform driver re-initialized the port to the wrong irq...
>> And the configuration knob will be required on all arches anyway because
>> that's how user-configurable device nodes are created.
>
> I think that's fine: The user-configurable ports are the same as
> the "ISA" or "phantom" ports we were talking about above, right?
Yes.
> If those are part of a separate (possibly loadable) module, having
> a configuration knob is the obvious way to do it. A lot of architectures
> can just turn it off because they know exactly which ports are present
> and there is no need for user-configurability. The ones that don't know
> can load the module.
Let me give this some more thought.
Regards,
Peter Hurley
WARNING: multiple messages have this Message-ID (diff)
From: peter@hurleysoftware.com (Peter Hurley)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] serial: 8250: Make ISA ports optional
Date: Tue, 06 Jan 2015 16:47:55 -0500 [thread overview]
Message-ID: <54AC580B.2050809@hurleysoftware.com> (raw)
In-Reply-To: <6786513.g26uGMFKLE@wuerfel>
On 01/06/2015 02:43 PM, Arnd Bergmann wrote:
> On Tuesday 06 January 2015 09:32:02 Peter Hurley wrote:
>> On 01/06/2015 08:13 AM, Arnd Bergmann wrote:
>>> On Monday 05 January 2015 22:09:45 Peter Hurley wrote:
>>>> Some arches have no need to create unprobed 8250 ports; these phantom
>>>> ports are primarily required for ISA ports which have no probe
>>>> mechanism or to provide non-operational ports for userspace to
>>>> configure (via TIOCSSERIAL and TIOCSERCONFIG ioctls).
>>>>
>>>> Provide CONFIG_SERIAL_8250_PHANTOM_UARTS knob to disable phantom port
>>>> registration; ie., CONFIG_SERIAL_8250_PHANTOM_UARTS=N only registers
>>>> probed ports (ACPI/PNP, "serial8250" platform devices, PCI, etc).
>>>>
>>>> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>>>> Cc: Tony Lindgren <tony@atomide.com>
>>>> Cc: Grant Likely <grant.likely@linaro.org>
>>>> Cc: Arnd Bergmann <arnd@arndb.de>
>>>> Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
>>>
>>> The intent is definitely right, but I think a better approach is
>>> possible.
>>>
>>> I haven't tried it here, but how about moving the serial8250_init
>>> function into a separate module, along with all the other parts
>>> that are only used for ISA devices, but leaving the actual core
>>> (all exported symbols) in this file?
>>
>> Unfortunately, I don't see a way to remove the stacked initialization
>> without risking tons of breakage.
>>
>> Since later probes can "find" an already-existing port and
>> re-initialize it, the probe order is crucial. For example, a PCI
>> probe can "find" an existing "serial8250" platform device port,
>> resulting in only one device node.
>
> I'm probably missing something important, by why would that
> be any different if the PCI driver gets loaded first and the
> ISA driver second?
Well, the PCI driver would have the proper irq, for one. So, if the
the platform driver re-initialized the port to the wrong irq...
>> And the configuration knob will be required on all arches anyway because
>> that's how user-configurable device nodes are created.
>
> I think that's fine: The user-configurable ports are the same as
> the "ISA" or "phantom" ports we were talking about above, right?
Yes.
> If those are part of a separate (possibly loadable) module, having
> a configuration knob is the obvious way to do it. A lot of architectures
> can just turn it off because they know exactly which ports are present
> and there is no need for user-configurability. The ones that don't know
> can load the module.
Let me give this some more thought.
Regards,
Peter Hurley
next prev parent reply other threads:[~2015-01-06 21:47 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-06 3:09 [PATCH] serial: 8250: Make ISA ports optional Peter Hurley
2015-01-06 3:09 ` Peter Hurley
2015-01-06 13:13 ` Arnd Bergmann
2015-01-06 13:13 ` Arnd Bergmann
2015-01-06 13:13 ` Arnd Bergmann
2015-01-06 14:32 ` Peter Hurley
2015-01-06 14:32 ` Peter Hurley
2015-01-06 19:43 ` Arnd Bergmann
2015-01-06 19:43 ` Arnd Bergmann
2015-01-06 21:47 ` Peter Hurley [this message]
2015-01-06 21:47 ` Peter Hurley
2015-01-07 10:05 ` Arnd Bergmann
2015-01-07 10:05 ` Arnd Bergmann
2015-01-08 13:10 ` One Thousand Gnomes
2015-01-08 13:10 ` One Thousand Gnomes
2015-01-08 13:10 ` One Thousand Gnomes
2015-01-08 16:11 ` Peter Hurley
2015-01-08 16:11 ` Peter Hurley
2015-01-08 22:05 ` Arnd Bergmann
2015-01-08 22:05 ` Arnd Bergmann
2015-01-08 22:36 ` One Thousand Gnomes
2015-01-08 22:36 ` One Thousand Gnomes
2015-01-08 23:25 ` Peter Hurley
2015-01-08 23:25 ` Peter Hurley
2015-01-09 5:13 ` Peter Hurley
2015-01-09 5:13 ` Peter Hurley
2015-01-09 8:48 ` Arnd Bergmann
2015-01-09 8:48 ` Arnd Bergmann
2015-01-09 14:14 ` Peter Hurley
2015-01-09 14:14 ` Peter Hurley
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=54AC580B.2050809@hurleysoftware.com \
--to=peter@hurleysoftware.com \
--cc=arnd@arndb.de \
--cc=bigeasy@linutronix.de \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=grant.likely@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.cz \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=tony@atomide.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.