[0/14] Ebony support, 2nd spi

[Arnd Bergmann]

On Tuesday 20 February 2007 16:25, Segher Boessenkool wrote:
> >> And the ebony dts also has the a bus type of "ibm,opb" as well.
> >
> > We should really get a common name for these. I don't remember
> > what the discussions were, but it seems we came up with different
> > results for Axon and ppc4xx, which is very bad.
> 
> "Very bad"...  Well sure it's less than desirable, but
> we have to deal with this problem anyway already.
> 
> > Using type "ibm,opb" rather than just "opb" makes sense to me,
> > but I don't know if we already have shipping systems that use
> > "opb" here.
> >
> > There is probably a similar problem with the nodes for "plb4",
> > "plb5" and "ebc",
> 
> It makes sense for generic code to always if it is asked
> to match for "vendor-code,some-name" also to match on
> plain "some-name".  Well unless people start doing crazy
> things like naming something "vendor-code,pci" which
> isn't PCI compatible or something -- in that case there
> could be a function that matches on exact name only, or
> the caller can deal with it itself perhaps.
> 
> But in most cases the matching-without-prefix should work
> fine.

but is it really the right thing to call it "ibm,plb"
when the identical macro is used on amcc based systems?

I think that was our reasoning when we introduced the
code in linux to scan for "plb5", "plb4" and "opb" buses.

Changing the "device-type" now would result in the final
product to not work on the 2.6.20 kernel, which was released
with the code only scanning for the short names.

Still, it's probably a good idea to list both variants
in compatible, e.g.

type="plb4", compatible="ibm,plb\0ibm,plb4\0plb"

on CAB/axon, and

type="ibm,plb", compatible="ibm,plb4\0plb4\0plb"

on ebony and others. Do you think it makes sense to do it this
way, or should we rather adopt the axon style on the 440 boards?

> > as well as the "compatible" property of the
> > serial port, which, as you noted earlier is "ns16550" on
> > ebony and "ns16750" on axon, although it is exactly the same
> > macro.
> 
> So the "compatible" property should read ns16750, ns16550,
> ns16450, i8250.  The kernel really only needs the device
> to be compatible to the 8250; but since lots of device trees
> mention only the newer UART types, you have to match on those
> too.

Right, that sounds completely correct. I think I've done the
right thing in of_serial already. Christian, please check
what the firmware does today, and make sure to change it
accordingly.
We probably also need a volunteer to clean up the legacy_serial
code for this, it's grown pretty messy by now.

	Arnd <><
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20070220/77531286/attachment.htm>