public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: "Greg Kroah-Hartman" <gregkh@suse.de>,
	linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org
Subject: Re: [PATCH 7/7] serial/8250: make PIO support optional
Date: Mon, 4 Jul 2011 18:35:22 +0200	[thread overview]
Message-ID: <201107041835.22660.arnd@arndb.de> (raw)
In-Reply-To: <20110628132255.71dcb72a@lxorguk.ukuu.org.uk>

On Tuesday 28 June 2011, Alan Cox wrote:
> Agreed but that can be done by io_serial_in/io_serial_out out of the
> 8250.c file. Really we need p->ops or a function in another file which
> provides the ioport 8250 interface and then all you'd have in the core
> code would be
> 
>         uart8250_set_ioport_ops(p);
> 
> which would live in 8250_ioport.c or be a "return -EINVAL' for anything
> else. 
> 
> That leaves request/release_std resources depending how such platforms
> handle request_region attempts, and the other fourport bits which want
> pushing into the 8250f_fourport driver perhaps as extra p-> ops.
> 
>         if (p->startup)
>                 p->startup(p);
> 
> etc
> 
> (Or indeed probably a p->ops-> for the lot is even saner)
> 
> Thoughts ?

I've tried a few of variations of that now, and I felt that I'm
getting drawn into some of the darkest corners of Linux driver
history ;-)

I first started out by separating the classing ISA device probing
and the platform driver into separate files. I think these
are useful to split out, because e.g. the PCI driver has no
dependency on either. Having the option to build without the
ISA stuff simplifies a lot of things.

I also made a patch for the mn10300 use of SERIAL_PORT_DFNS,
which is the only architecture that defines non-ISA ports
that way.

Where I failed so far is the dynamic configuration of ports using
setserial. This intentionally allows changing the io_type setting
as well as the actual resources (ioport, mapbase, irq, ...).
Changing the io_type is not supported by /bin/setserial, but
other tools might be doing it.
My question is whether we should still care about those. If
we can remove the reconfiguration of existing ports or move
it to one of the more obscure parts of the driver, it's possible
to confine the dependencies on the ioport_ops to the front-end
drivers, while the core 8250 library driver would not need it
any more.

Today, most ports don't set the UPF_FIXED flag, even though
the ports definitely have fixed resources, e.g. all of the
8250-platform drivers in arch/ or the 8250_pnp and 8250_cs
front-ends. Do you think it would be reasonable to mark all
8250 ports except the ISA ones as UPF_FIXED, and move the
reconfiguration logic into the 8250_isa driver along with
old_serial_port, serial8250_isa_devs,  and
serial8250_isa_init_ports?

	Arnd

  reply	other threads:[~2011-07-04 16:35 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-27 21:45 [PATCH 0/7] serial/8250: I/O accessor cleanups Arnd Bergmann
2011-06-27 21:45 ` [PATCH 1/7] serial/8250: remove obsolete RM9000 port type Arnd Bergmann
2011-06-27 21:45 ` [PATCH 2/7] serial/8250: move alchemy I/O handler to platform code Arnd Bergmann
2011-06-28  8:06   ` Manuel Lauss
2011-06-28 11:29   ` Manuel Lauss
2011-06-28 15:36     ` Manuel Lauss
2011-06-28 17:07       ` Arnd Bergmann
2011-06-27 21:45 ` [PATCH 3/7] serial/8250: move UPIO_TSI to powerpc Arnd Bergmann
2011-06-27 23:51   ` David Daney
2011-09-01  6:02   ` Benjamin Herrenschmidt
2011-09-01  8:28     ` Arnd Bergmann
2011-06-27 21:45 ` [PATCH 4/7] serial/8250: move DWAP support to arch/mips Arnd Bergmann
2011-06-27 22:15   ` Jamie Iles
2011-06-28  5:43     ` Arnd Bergmann
2011-06-28 10:06   ` Alan Cox
2011-06-28 10:48     ` Arnd Bergmann
2011-06-27 21:45 ` [PATCH 5/7] serial/8250: remove obsolete and broken PORT_RSA support Arnd Bergmann
2011-06-28 10:11   ` Alan Cox
2011-06-27 21:45 ` [PATCH 6/7] serial/8250: sanitize fourport handling Arnd Bergmann
2011-06-28 10:10   ` Alan Cox
2011-06-28 12:07     ` Arnd Bergmann
2011-06-27 21:45 ` [PATCH 7/7] serial/8250: make PIO support optional Arnd Bergmann
2011-06-28 10:05   ` Alan Cox
2011-06-28 11:52     ` Arnd Bergmann
2011-06-28 12:22       ` Alan Cox
2011-07-04 16:35         ` Arnd Bergmann [this message]
2011-07-04 17:02           ` Alan Cox
2011-07-04 19:27             ` Arnd Bergmann
2011-07-04 19:53               ` Alan Cox
2011-07-04 20:37                 ` Arnd Bergmann
2011-07-04 21:55                   ` Alan Cox
2011-07-04 21:54                     ` Arnd Bergmann
2011-06-28 10:11   ` Alan Cox
2011-06-27 23:57 ` [PATCH 0/7] serial/8250: I/O accessor cleanups David Daney

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=201107041835.22660.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox