RE: Bug in drivers/serial/of_serial.c?

[Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>]

> -----Original Message-----
> From: linuxppc-dev-bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org] On Behalf Of Alon
Ziv
> Sent: Thursday, November 19, 2009 4:47 AM
> To: Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
> Subject: RE: Bug in drivers/serial/of_serial.c?
> =

> Hi,
> =

> On Monday, November 16, 2009, Arnd wrote:
> > > -       { .type =3D "serial", .compatible =3D "ns16550",  .data =3D
(void
> *)PORT_16550, },
> > > +       { .type =3D "serial", .compatible =3D "ns16550",  .data =3D
(void
> *)PORT_16550A, },
> >
> > Does not seem logical. If the device claims compatibility with
> ns16550, we should
> > not automatically assume it's an ns16550a. Why not add another line
> for
> >
> =

> Unfortunately, there is no way to change what the device claims--it's
> encoded into the OpenFirmware tree by the EDK tools.
> And, in any case, the device is actually not lying: it _is_ compatible
> with NS16550--just with a non-buggy one.  Unfortunately the kernel
> driver for 8250-class UARTs makes the conservative choice to assume
any
> 16550 is one of the (early, buggy) revisions where the FIFO was
> non-functional; any 16550 with working UART is classed as a 16550A.

Definitely changing what is generated by EDK seems to make sense here...

Steve


This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.