[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.030 / U:12.932 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site