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? :-) 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 _______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
