[lkml]   [2002]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [parisc-linux] 3 Serial issues up for discussion (was: Re: Serial core problems on embedded PPC)
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
> 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 ( The developer of ARM Linux
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to
> More majordomo info at
> Please read the FAQ at
> _______________________________________________
> parisc-linux mailing list


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:27    [W:0.148 / U:7.548 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site