But I still oppose this idea. This idea allows drivers to add control element sets of different types (int/int64/bytes etc...) with the same name and different index number. This certainly brings confusions to applications.
Today is already possible using the device or subdevice field instead of index.
Please explain about the reason or show references to the reason that usage of iface/card/device/subdevice combination is not convenient to your issue. To me, this solves the issue (second issue in your previous message) because at least, from user land, applications can identify a control element corresponding to each PCM subdevice.
In other words, in your taste, why this is not a generic way for something you face (this is not cleared yet to me).
iface/card/device/subdevice can be used when control is linked to a PCM device. Main difference for ASoC drivers is that controls associated to CPU_DAIs and CODEC_DAIs are not linked to PCM device. That's why i had mentioned in a previous mail a patch that proposed to link DAI to PCM (it just a first version for concept). [PATCH v4 1/6] ASoC: core: add snd_soc_add_dai_pcm_controls helper: http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/105501.html
This could link control to PCM device for CPU and CODEC DAI in ASoC implementation. But issue still there for DPCM implementation where back-end is not linked to the PCM device, or for CODECS without DAI interface, as mentioned in feedbacks: http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/105570.html http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/105660.html
Also we can imagine 2 instances of the same codec (for instance HDMI1 and HDMI2 output for TV and AVR). They can export twice the same controls. In this case issue can also exists for none PCM controls (such as MIXER controls).
The last point is the iecset application. It uses card/index and not iface/card/device/subdevice. But this also makes sense if iec control is not linked to PCM device.
Another solution is to declare a card per instance of control. This should work for my use case and for use cases with several codecs that declare same controls.> But this should not work for DPCM... The drawback for my use case, would be that i need to declare one card per PCM device.
In my understanding, this idea is not good for simple-card implementation in ALSA SoC part, too. The idea needs more complicated driver to have several instances of sound card.
Simple card can be instantiate in DT to create several sound cards. But look like more a backup that a main solution, from my point of view.
Regards Arnaud