+config SND_SOC_INTEL_USE_CTL_COMPONENTS + bool "Use CTL components for I/O configuration" + help + Some drivers might pass the I/O configuration through the + soundcard's driver name in the control user space API. + The new scheme is to put this information to the components + field in the ALSA's card info structure. Say Y, if you + have ALSA user space version 1.2.2+.
If this is at the board level, then maybe move this to sound/soc/intel/boards/Kconfig
I am not sure about the alsa-lib dependency, it's a bit odd, isn't it? shouldn't this be handled via protocol versions? or a configuration provided by alsa-lib somehow?
It's not about the protocol. It's about to move this type of information to another place. I can remove the ALSA version sentence from the help, because it's just a hint. I would like to create ucm2 configurations based on this rather than the misused long card names.
I am with you on the idea, it's the transition that worries me. I guess for a distro that would be fine, one would hope that there is a communication between the alsa-lib and the kernel configurations parts, but for a random user there's a chance that they would not select this and not use ucm2 and vice versa.
it's also painful for kernel developers to rely on to-be-released alsa-lib changes, we've been there with SOF and I don't know how many times we had reports of issues related to alsa-lib setup problems. Here it'd be worse since alsa-lib updates would need to be deployed on target devices.
Again I am not against the idea, but anything we can do to reuse friction during the transition will help a great deal.