It's vital that you mention the kernel version you're using; some of
these problems sound like 2.5.28.
> In 8250.c, it appears that in order for a port to be used for the
> serial console it must be defined "old style" with SERIAL_PORT_DFNS,
> rather than being registered with register_serial() (because
> serial8250_console_setup() indexs into the serial8250_ports array)).
> This presents a small problem for 4xx, since it's serial ports are
> memory mapped and the new old_serial_port structure can't represent
There is no easy solution for this. Alan said we must not drop support
for serial console initialisation early on in the kernel setup, which
means before the memory subsystems are initialised.
> I added support for these into 8250.c, but ran into further troubles.
I suspect a 2.5.28 kernel; please confirm and we'll that it from there.
> The current plethora of similar-but-not-the-same structures describing
> serial ports (serial_state, serial_struct, uart_port, old_serial_port)
> is also rather confusing. I'm guessing some of these are deprecated
> and remain only as an aid to transition, but I'm not sure which.
I don't see there being an easy way to kill this off:
1. serial_struct is a userspace API.
2. old_serial_port glues asm/serial.h into 8250.c; asm/serial.h can't be
changed because (mainly) ppc uses it elsewhere. Other architectures
seem to do the same sort of thing.
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.
-- Russell King (firstname.lastname@example.org) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/