On Wed, Apr 28, 2010 at 4:13 PM, Timur Tabi timur.tabi@gmail.com wrote:
On Wed, Apr 28, 2010 at 4:58 PM, Grant Likely grant.likely@secretlab.ca wrote:
The sound0 node needs a compatible value,
I knew I was forgetting something
:-)
the sound-device node should probably have one too.
The aliases, cpus, and memory node don't have a compatible property, and I was modeling the design after the aliases node.
Well, there are typically three ways to find a node; by name, by device_type and by compatible. device_type is meaningless for the flattened tree, so that's out. Matching by name could potentially have namespace collisions, but I'm not sure. I'll defer to Ben & Mitch's judgment here.
The difference with aliases, cpus and memory nodes is that the conventions around them were defined and agreed on a very long time ago. We could get consensus to do the same here, but I cannot make that call.
The sound0 node should have something board specific like "fsl,mpc8610hpcd-sound" to make it clear that the binding really only applies to this particular board. It would also be a good idea to prefix all of the property names with 'fsl,' to avoid conflicting with any future common bindings or conventions. Other boards can use the same binding, but they would get a different compatible value (the driver could bind on both).
The aliases node doesn't have an fsl, prefix. I understand the need for the prefix, but I wonder why we don't do that for the aliases node.
aliases is not a vendor-specific or limited scope convention.
g.