On Wed, Apr 28, 2010 at 4:13 PM, Timur Tabi <timur.tabi@xxxxxxxxx> wrote: > On Wed, Apr 28, 2010 at 4:58 PM, Grant Likely <grant.likely@xxxxxxxxxxxx> 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. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
