use of fsl, in lite5200b.dts in git current

[Jon Smirl]

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.

>
> 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 :]

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.


> It's just to separate out the fact that sometimes you get chips with
> very similar or identical names, or to mark out vendor-specific

You don't get chips with identical names. If they had identical names
you couldn't order them from a distributor. Similar yes, identical 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.

> Freescale watchdog timers aren't the same as other watchdog timers -
> the term is pretty pliable, Freescale's GPT on the MPC52xx isn't
> always a watchdog (it can be a normal, non-watchdog timer too..)
>
> > The mpc/pxa parts numbers don't get changes when chip families get sold.
>
> There is a case that between selling chips, some of them get updated
> or bug fixed, and you can tell which one you have by the name.

You can always tell which one you have. The vendors add suffixes to
the part numbers so that you can identify the steppings.

>
> There has to be some standardization on the first implementation of
> the device tree for the chip, otherwise the chopping and changing
> gets rather tedious.
>
> I'm sure you can see why we don't release firmware updates every time
> some Linux guy changes some lousy, hacky tree definition for yet another
> 6 times a year, until it finally stabilizes and the product is usually
> discontinued anyway :D

That's life in the Linux world, no backwards binary compatibility. I'm
in favor of the model since we can fix things until with get the right
instead of piling hacks upon hacks trying to keep ancient, broken
interfaces working (I used to work on the Windows kernel. it is major
ugly).

> However in the current situation it just means you need to flash new
> FDT blobs to your U-Boots which are more clean, and keep your kernel
> in sync, because Linux only handles what it currently thinks is the
> standard.
>
> The real loser is the real Open Firmware implementation, but nobody
> seems to think about that, the device trees on OF devices get more
> cluttered.

Open Firmware lost when it initially came out closed source and people
charged for it. uBoot/redboot/etc took the market because they were
open and free. If Open Firmware had been a free implementation from
day one things would have ended up differently.


-- 
Jon Smirl
jonsmirl at gmail.com