Re: [0/14] Ebony support, 2nd spi

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.

quoted

So the "compatible" property should read ns16750, ns16550,

quoted

ns16450, i8250. The kernel really only needs the device

quoted

to be compatible to the 8250; but since lots of device trees

quoted

mention only the newer UART types, you have to match on those

quoted

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