[PATCH] booting-without-of: add Xilinx uart 16550.

Grant Likely grant.likely at secretlab.ca
Sat Feb 16 06:33:38 EST 2008


On Fri, Feb 15, 2008 at 12:14 PM, Sergei Shtylyov
<sshtylyov at ru.mvista.com> wrote:
> Grant Likely wrote:
>  > The registers are not at the same location, therefore it is not compatible.
>
>  > However, the *driver* can be easily made compatible with the devices.
>  > We just teach the driver to bind against both "ns16550" and whatever
>  > value is chosen for these reg-shifted devices.  Not a big deal.
>
>     You're going to "teach" 8250.c? Good luck. :-)

:-P

As you already know, 8250.c already knows how to handle reg shifts.
But that is not what this conversation is about.

>     IMO we can only teach a glue layer which "passes" UARTs to 8250.c via
>  platform devices.

That's right.  This discussion is only about the device tree binding.
It is not about the core driver.

>  > compatible also covers bus binding when it is a memory mapped device.
>  > Otherwise you need another node between the bus and the ns16550 type
>  > device that does translation from the wide stride (regshift=2) to the
>  > ns16550 register definitions (regshift=0).
>
>     The chip can be connected to the bus (via chip select circuitry) in
>  different ways, therefore we need a "glue" node for that circuitry?

I'm not arguing that we want a glue node.  What I'm arguing is that
"compatible=ns16550" has a very specific meaning that has become a
defacto standard over the years.  To add a new interpretation of that
meaning is problematic.  Instead, if reg shift is needed then use a
different value for compatible.

It's not like we're talking about something that is hard to do.  It is
simply being explicit in the device tree layout.  Historically
"ns16550" means no reg shift, so don't use it for devices that have a
reg shift.

Cheers,
g.

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



More information about the Linuxppc-dev mailing list