Re: [parisc-linux] 3 Serial issues up for discussion (was: Re: Serial core problems on embedded PPC)

[Christoph Plattner <christoph.plattner@gmx.at>]

Ad "setserial API":

Please use /proc/serialdev (or similar), *NOT* a `/dev' entry !!
This is typical `/proc'-FS stuff !
(See SCSI: echo "scsi add-single-device 0 0 4 0" > /proc/scsi/scsi
!!!)

Christoph P.


Russell King wrote:
>
> On Mon, Jul 29, 2002 at 07:44:08AM -0700, Tom Rini wrote:
> > On Mon, Jul 29, 2002 at 10:00:10AM +0100, Russell King wrote:
> > > Unless ppc and others are willing to put up with major breakage when I
> > > change asm/serial.h, I don't see this getting cleaned up.  Comments on
> > > this area welcome.
> >
> > Well, what changes do you have in mind?
>
> Firstly, apologies to Tom for turning this into a general discussion
> mail.  At the request of Tom, this message is also CC:'d to the PPC
> devel lists.
>
> There's quite a lot in here, so please, when replying edit out stuff
> your not replying to.  Thanks.
>
> 1. Serial port initialisation
> -----------------------------
>
> Firstly, one thing to bear in mind here is that, as Alan says "be nice
> to make sure it was much earlier".  I guess Alan's right, so we can get
> oopsen out of the the kernel relatively easily, even when we're using
> framebuffer consoles.
>
> I'm sure Alan will enlighten us with his specific reasons if required.
>
> There have been several suggestions around on how to fix this table:
>
> a. architectures provide a sub-module to 8250.c which contains the
>    per-port details, rather than a table in serial.h.  This would
>    ideally mean removing serial.h completely.  The relevant object
>    would be linked into 8250.c when 8250.c is built as a module.
>
> b. we create 8250_hub6.c, 8250_generic.c, 8250_multiport.c and friends
>    each containing the parameters for the specific cards and handle it
>    as above.
>
> c. make it the responsibility of user space to tell the kernel about
>    many serial ports, and leave just the ones necessary for serial
>    console in the kernel.  (see issue 2 below)
>
> d. we keep serial.h, make it 8250-compatible ports only, and change
>    CONFIG_SERIAL_MULTIPORT and friends to CONFIG_SERIAL_8250_MULTIPORT
>    This is the simplest and least likely to break other code.  On the
>    other hand, we end up hauling the ISA table and struct old_serial_port
>    into 2.6.
>
> 2. setserial API
> ----------------
>
> This is actually tied closely into another issue; I'd like to get rid
> of this silly idea where we're able to open serial ports that don't
> exist (ie, their UART is "unknown").  This behaviour appears to be for
> the benefit of setserial to allow it to modify port base addresses and
> interrupt levels, etc.  Removing this facility would require a new API
> for such things.  The best suggestion made so far is to do something
> like:
>
> # echo "add 0x2e8,3,autoconfig" >/dev/serialctl
> # echo "remove 0x2e8" >/dev/serialctl
>
> (or s,/dev/serialctl,/proc/tty/driver/serial, which pre-exists)
>
> where we have "add ioport,irq,flags" and "remove ioport" (note that
> mmio ports aren't covered here since they require ioremap games which
> tends to be card specific!)
>
> Why make this change?  Well, we have quite a lot of baggage being
> dragged around to support configuration of an open port and being
> able to open a non-existent port.  I'd really like to get rid of
> this excess baggage.
>
> 3. /dev/ttyS*, /dev/ttySA*, /dev/ttyCL*, /dev/ttyAM*, etc
> ---------------------------------------------------------
>
> All the above are serial ports of various types.  It has been expressed
> several times that people would like to see all of them appear as
> /dev/ttyS* (indeed, there was an, erm, rather heated discussion about
> it a couple of years ago.)  I'm going to be neutral on this point
> here.
>
> There are several issues surrounding this:
>
> a. The serial core.c is very almost capable of handling this abstraction,
>    with one exception - a registered port can only be in one group at
>    one time.  This restriction is brought about because of the way the
>    tty layer handles its tty ports.
>
>    (Handling dual registrations in two different majors gets _really_
>     messy - eg, you two built-in 16550A ports and two SA1100 ports
>     taking up ttyS0 to ttyS3.  You then add a 16550A PCMCIA modem,
>     which becomes ttyS4.  Oh, and the SA1100 ports are also appearing
>     as ttySA0 and ttySA1.  _really_ messy.  No thanks.)
>
> b. serial consoles.  Each hardware driver handles its serial consoles
>    by itself, and if you have two or more hardware drivers built in
>    with serial console support, you need to be able to tell them apart
>    with the console= kernel parameter.
>
>    Again, this could be solvable if we have one "ttyS" view of everything
>    (core.c would then be responsible for registering the console with
>     printk.c and passing the various methods off to the relevant
>     hardware).
>
> c. People with many serial ports.  We _could_ change the device number
>    allocations such that ttyS gobbles up the ttySA, ttyCL, ttyAM, etc
>    device numbers so we end up with the same number of port slots
>    available for those with many many serial ports in their machines.
>
> --
> Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
>              http://www.arm.linux.org.uk/personal/aboutme.html
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

--
-------------------------------------------------------
private:	christoph.plattner@gmx.at
company:	christoph.plattner@alcatel.at


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/