On 11/8/07, Scott Wood <[EMAIL PROTECTED]> wrote: > Jon Smirl wrote: > > On 11/7/07, Matt Sealey <[EMAIL PROTECTED]> 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? :-)
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. > 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. > > 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 > > -- Jon Smirl [EMAIL PROTECTED] _______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded