On Fri, Nov 20, 2009 at 3:11 PM, John Linn [off-list ref] wrote:

quoted

-----Original Message-----
From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of Gr=

ant Likely

quoted

Sent: Friday, November 20, 2009 2:58 PM
To: Stephen Neuendorffer
Cc: Arnd Bergmann; John Linn; Alon Ziv; linuxppc-dev@lists.ozlabs.org
Subject: Re: Bug in drivers/serial/of_serial.c?

On Thu, Nov 19, 2009 at 10:42 AM, Stephen Neuendorffer
[off-list ref] wrote:

quoted

quoted

-----Original Message-----
From: linuxppc-dev-bounces+stephen=3Dneuendorffer.name@lists.ozlabs.o=

rg

quoted

quoted

[mailto:linuxppc-dev-

quoted

bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org] On Behalf Of Ar=

nd

quoted

quoted

Bergmann

quoted

Sent: Thursday, November 19, 2009 9:33 AM
To: Stephen Neuendorffer
Cc: John Linn; Alon Ziv; linuxppc-dev@lists.ozlabs.org
Subject: Re: Bug in drivers/serial/of_serial.c?

On Thursday 19 November 2009, Stephen Neuendorffer wrote:

quoted

If the problem is in the device trees that are being generated, we
should fix the issue there.
We've been trying to avoid putting the fully specified IP versions

in

quoted

quoted

the kernel like this, since
the IP changes so often.

No, the problem that Alon has is that the firmware currently has no
way whatsoever to give a correct device tree, because of-serial.c
does not even know about ns16550a.

The patch adds both a special-case for the specific uart he
is using so that one is grandfathered in and a new compatible
value so future boards can specify both ns16550a and ns16550.

That's true... =A0The 16550a line still needs to get added, but not th=

e

quoted

quoted

xlnx-
specific line.

The xlnx- line should be added and is entirely appropriate for exactly
the reason Arnd stated.

I'm just wanting to make sure I'm on the same page...

It seems like you're saying that adding this line fixes the system before=

 any device tree generator fix, for existing systems, true?

If that's true, how do you know that the 16550 in the xilinx system is no=

t a 16450 as that's the default?

Right now we're not generating the ns16450 as we should be when there are=

 no FIFOs. =A0Since we've been using 16550 and not 16550A it probably hasn'=
t been a problem.

Hmmm, right.  I forgot that we talked about that on the phone.  Yes,
in that case it is not a good idea to add the
xlnx,xps-uart16550-2.00.b because we don't know if it is configured as
a 16450 or a 16550.  At least, if the xlnx,... match is added, then
the driver *also* needs to look for the value of the "xlnx,is-a-16550"
property.

BTW, while looking at that file... Arnd, does the .type =3D "serial"
stuff really need to be there?

Cheers,
g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.