Exar ST16C2550 rev A2 bug

From: Alex Williamson (alex.williamson_at_hp.com)
Date: 11/17/04

  • Next message: Greg KH: "Re: [PATCH] [Request for inclusion] Filesystem in Userspace"
    To: rmk+serial@arm.linux.org.uk
    Date:	Wed, 17 Nov 2004 11:26:47 -0700
    
    

    Hi Russell,

       There seem to be an increasing number of the above UARTs floating
    around and I'm wondering if we can do something to better detect and
    work around their flaw. Exar has documented the problem and their
    proposed serial driver changes to work around the issue here:

    http://www.exar.com/info.php?pdf=dan180_oct2004.pdf

    In short, they had a mask problem that inadvertently exposes the DVID,
    DREV and EFR registers on the chip. This causes us to detect the device
    as a 16650V2 and try to make use of the FIFO as if it were 32 bytes.
    The previous version of the UART detected correctly as a 16550A and
    worked fine. Exar's proposed solution is simply to only set the port
    type to 16650V2 if size_fifo() == 32, or simply:

    ===== drivers/serial/8250.c 1.91 vs edited =====
    --- 1.91/drivers/serial/8250.c 2004-11-13 17:43:56 -07:00
    +++ edited/drivers/serial/8250.c 2004-11-17 11:13:05 -07:00
    @@ -570,7 +570,7 @@
             */
            if (size_fifo(up) == 64)
                    up->port.type = PORT_16654;
    - else
    + else if (size_fifo(up) == 32)
                    up->port.type = PORT_16650V2;
     }
     
    The proposed 2.4 solution is quite similar. It seems reasonable to
    verify the reported FIFO size, but perhaps you have a better solution.
    For anyone currently impacted by this bug, a simple yet limited
    workaround is to change the uart type using setserial. Thanks,

            Alex

    -- 
    Alex Williamson                             HP Linux & Open Source Lab
    -
    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: Greg KH: "Re: [PATCH] [Request for inclusion] Filesystem in Userspace"

    Relevant Pages

    • Re: KITL Addres
      ... You'll need to define what hardware platform ... you are working including the CPU, and UART type you are using along with ... the UART init and byte write code and any defines they use for the boot ...
      (microsoft.public.windowsce.embedded)
    • Re: KITL Addres
      ... You'll need to define what hardware platform ... you are working including the CPU, and UART type you are using along with ... the UART init and byte write code and any defines they use for the boot ...
      (microsoft.public.windowsce.platbuilder)
    • Re: [PATCH] backup timer for UARTs that lose interrupts
      ... > it seems like the UART gets way behind on transmitting bits. ... process in your patch. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: serial: 8250 fails to detect Exar XR16L2551 correctly
      ... Alex, could you test ... I contacted Exar about these two seemingly ... > output from the time the UART is detected until we hit userspace. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Bitrotting serial drivers
      ... The uart is just different enough to make that hard, though I admit I ... > never spent too much time on it. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)