From: Arnd Bergmann <arnd@arndb.de>
To: Peter Hurley <peter@hurleysoftware.com>
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 20:43:37 +0100 [thread overview]
Message-ID: <6786513.g26uGMFKLE@wuerfel> (raw)
In-Reply-To: <54ABF1E2.1010905@hurleysoftware.com>
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?
> 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?
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.
> > At the same time, the serial8250_pnp_init/serial8250_pnp_exit calls
> > can be removed from the serial8250_init function and become
> > standalone initcalls.
>
> PNP probe must occur before the phantom ports are registered.
> See commit 835d844d1a28efba81d5aca7385e24c29d3a6db2
> ("8250_pnp: do pnp probe before legacy probe").
Makes sense.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] serial: 8250: Make ISA ports optional
Date: Tue, 06 Jan 2015 20:43:37 +0100 [thread overview]
Message-ID: <6786513.g26uGMFKLE@wuerfel> (raw)
In-Reply-To: <54ABF1E2.1010905@hurleysoftware.com>
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?
> 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?
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.
> > At the same time, the serial8250_pnp_init/serial8250_pnp_exit calls
> > can be removed from the serial8250_init function and become
> > standalone initcalls.
>
> PNP probe must occur before the phantom ports are registered.
> See commit 835d844d1a28efba81d5aca7385e24c29d3a6db2
> ("8250_pnp: do pnp probe before legacy probe").
Makes sense.
Arnd
next prev parent reply other threads:[~2015-01-06 19:44 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 [this message]
2015-01-06 19:43 ` Arnd Bergmann
2015-01-06 21:47 ` Peter Hurley
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=6786513.g26uGMFKLE@wuerfel \
--to=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=peter@hurleysoftware.com \
--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.