On Tue, Dec 31, 2013 at 06:44:30PM +0100, Jean-Francois Moine wrote:
Mark Brown broonie@kernel.org wrote:
It's possible there is a benefit I'm just not seeing but you'll need to tell me.
The first benefit I got was in the front-end definition: the codec side is the dummy codec, and this one has no phandle.
That's a sign that you're putting Linux implementation details into your DT - remember, DT is supposed to be implementation neutral.
Then, finding the CODEC DAI from phandle asks for more code (of_xlate_dai_name in the CODEC drivers) and finding it from the CODEC
They should be able to use a default there; I'd expect that just to be making the IDs the same as the index into the array or the ID field.
name asks for a double loop in soc_bind_dai_link. On the other way, a simple loop without any more change may be used when the DAI is simply specified by its name. I would say that the DAI name is more meaningful
Then as soon as anything else starts using the same name for some reason the binding stops being useful.
than a DAI index and that it is less subject to internal changes of the CODEC driver.
Obviously the numbers that get assigned become a part of the ABI and can't be changed. Now that we have preprocessor support for DT the plain text can be done with that, though for a lot of devices that won't be needed as the devices are just numbered anyway.
Eventually, I don't think that, using only the name of the CODEC side DAI to identify it, is not more fragile than identifying the CPU side of the DAI link by its name.
This doesn't mean it's a good idea to do it - as you will remember I said I expected things to want to go more towards using phandle plus ID for everything.