use of fsl, in lite5200b.dts in git current

[Scott Wood]

Jon Smirl wrote:
> On 11/7/07, Matt Sealey <matt at genesi-usa.com> wrote:
>> Jon Smirl wrote:
>>> I'm not in favor of all these fsl prefixes. These chip families
>>> do get sold. What would we have done with intel,pxa320 all over
>>> the place when they sold it to marvell? mass changes to
>>> marvell,pxa320?
>> That's the idea, and there'd be a compatible entry for
>> intel,pxa320.
> 
> The vendor part really isn't needed and it is going to be a source of
>  trouble. The vendors are smart enough not to create two chips with
> the same part number. Adding a vendor qualifier complicates things 
> needlessly.

I think you may be placing too much faith in the vendors.
Is a 7400 a Freescale powerpc chip, or a quad 2-input NAND gate? :-)

If you want to argue that the "MPC" part differentiates them, that's
just a less readable and more obsolete vendor prefix.

And not all compatible entries are part numbers; many are descriptions
of programming interfaces (such as cpm2 or gianfar).  I'm not inclined
to bet that there will never be a conflict in such a namespace.

>> Actually the spec says you should use the stock ticker (IBM, FSL,
>> INTC, JAVA, MRVL) if they have one and if not, the company name in
>> lower case.
>> 
>> Freescale are a funny one because they used to have a stock ticker
>> as MOT and then FSL but now they're privately owned, so it's gonna
>> have to be lower case :]

Well, technically the recommended prefix is an OUI number, and those are
less likely to change due to corporate shuffling, but they suck from a
readability perspective.

> Another example of how these vendor prefixes can change. The chip 
> numbers are never going to change. Just use them and drop these
> vendor prefixes.

No. :-)

>> functionality. fsl,has-wdt differs from has-wdt ideally because
> 
> This one I can buy, but it should be fsl-has-wdt. Drop the vendor
> prefixes.

How is fsl-has-wdt any better, other than it obscures namespace issues?

Vendor prefixes on properties are useful in that it might not mean
exactly the same thing as a similar property that gets standardized
later on.

> That's life in the Linux world, no backwards binary compatibility.

There's a huge difference between compatibility of kernel interfaces and
compatibility of interfaces between the kernel and something else --
whether it be userspace or firmware.

-Scott