[0/14] Ebony support, 2nd spi

[Segher Boessenkool]

> 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.

Yes, the vendor-code is there only as a unique marker
so different vendors won't have clashing namespaces.
Seen from that viewpoint, if a company buys stuff from
another company, or the whole company is bought or something,
it makes sense to keep the original name.

> 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.

If it's important for you to support .20, you obviously
shouldn't change this in the device tree anymore.
Unfortunate.

> Still, it's probably a good idea to list both variants
>
> in compatible, e.g.
>
> type="plb4", compatible="ibm,plb\0ibm,plb4\0plb"

No, that's a very bad idea.

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

Like I said, it is probably best to have the device_is_compatible()
function return true if it is asked for "some-vendor,some-name"
and the actual property contains just "some-name".  The device
tree isn't more specific in that case, so any matcher can easily
be hurt by a namespace clash -- too bad, nothing the kernel
can do about it, but at least it can do the right thing for
device trees that *do* comply to best practice.

> > 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.

Yeah I think so.

> Christian, please check
>
> what the firmware does today, and make sure to change it
>
> accordingly.

Note that it doesn't matter much for Linux if you change the
"compatible" property for serial now; the kernel will have to
support ns16550, ns16750 for ever since there are device
trees in the wild that don't include the more generic devices
in their "compatible" property.  Not only Axon etc. device
trees, don't get me wrong :-)

> We probably also need a volunteer to clean up the legacy_serial
>
> code for this, it's grown pretty messy by now.

I nominate you :-)


Segher