Bug in 8520.c - port.type not set for serial console

From: Jim Ramsay (jim.ramsay_at_gmail.com)
Date: 05/31/05

  • Next message: Karim Yaghmour: "Re: RT patch acceptance" 
    Date:	Mon, 30 May 2005 16:38:29 -0600
To: linux-kernel@vger.kernel.org

    I am attempting to get the 8520.c driver's serial console working with
    a 16550A UART implementation, and have run into what I consider to be
    a bug: In short, the proper 'port.type' for this serial port is not
    set until the module init (serial8250_init) is called, so the FCR is
    set incorrectly during serial8250_console_init for any port type which
    is different than UNKNOWN.

    The exact problem is that the FCR is being set to '0x0' for a port
    type of 'UNKNOWN', when for my specific 16550A, it should be set to
    '0xC1' - and this makes my screen fill with empty characters instead
    of the printk output I need. It appears that after some time (once
    the kernel actually calls serial8250_init) the problem clears up, but
    I still lose a large section of the output before this point.

    The proper flags are sitting there in the uart_config array for the
    proper type, and this type is properly deduced by the 'autoconfig'
    routine that eventually gets called by serial8250_init. The problem
    is that the autoconfig is isn't called by serial8250_console_init
    which of course happens much earlier than serial8250_init.

    I have a workaround that works for me, telling the
    serial8250_set_termios() routine to only set the FCR if the type is
    not UNKNOWN, changing
        if (up->port.type != PORT_16750 ) {
    to
        if (up->port.type != PORT_16750 && up->port.type != PORT_UNKNOWN) {

    This will leave the FCR at whatever it was at boot time, which for me
    is correct.

    Would this be a "good enough" fix in general, or would there be a
    better way of doing this?

    I suppose the other way would be to duplicate some of what
    serial8250_init does (like call 'autoconfig') in
    serial8250_console_init, but I haven't tried this yet... maybe it
    depends on too much kernel magic to be called as early as
    'console_init'?

    Any suggestions on the best way to fix this would be great, I'd be
    happy to develop this more, test a bit, and submit a patch. 

    -- 
Jim Ramsay
"Me fail English?  That's unpossible!"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
  • Next message: Karim Yaghmour: "Re: RT patch acceptance"