Re: use of fsl, in lite5200b.dts in git current

[Matt Sealey <matt@genesi-usa.com>]

Jon Smirl wrote:
> On 11/8/07, Scott Wood <scottwood@freescale.com> wrote:
>
>> 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? :-)
> 
> There has to be more to the part number for the Freescale powerpc chip
> than just 7400. 7400 is a shorthand name, it is not an orderable part number.

The orderable part numbers add 3 or 4 characters to the front and about
8 after. There is a difference between MPC7400 and PPC7400, and the
low voltage versions, and the different clock speeds. Orderable part
number for a recent G4 might be PPC7448B1333NL - this is a ridiculous
amount of specificity in a device tree, and it also does not match the
datasheet (MPC7448 is the name of the chip).

What people usually do is use what's in the datasheet.

>> If you want to argue that the "MPC" part differentiates them, that's
>> just a less readable and more obsolete vendor prefix.
> 
> The MPC is what is printed on the chip. fsl is not printed there. MPC
> is part of the orderable part number.

Not all of them *ahem* :)

Like I said, trust the datasheet, not the number on the chip.

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

Indeed, so.. at some point we should all sit down and hammer out the
major issues in describing something like the MPC5121E because right
now Genesi has a vested interest in that. Thanks Grant for your
discussion on it, I agree of course :)

One thing we don't want to go through again is the complaints we got
because we named the chip node "/builtin" rather than "/soc". My fixup
script is still handling that mess because you guys refused to
accept it (and some drivers were coded to map from the MBAR contained
in device_type soc's reg property rather than find a real device).

If we could all agree on how it should be mapped out, with an example
tree which shows *every damn thing available* so platform developers
can pick and choose and OF developers can use it as a reference, it
would make a much happier process.

And then we can fix up the Efika to fit some definition of the new
MPC5200 tree too.

By the way while I was poking around the tree today I noticed that
there is a PCI errata fixup handled by a Kconfig in there. Why? Surely
this is something you check the PVR/SVR for and switch on that for
a runtime solution, and not trick users with the possibility of
forgetting to enable some obscure "PCI errata fix" configuration
item? (CONFIG_PPC_MPC5200_BUGFIX)

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations