[PATCH] [RFC] ALSA: hda: Fix the control element identification for multiple codecs

[Takashi Iwai]

On Mon, 30 Jan 2023 09:21:18 +0100,
Jaroslav Kysela wrote:
> 
> [This is a RFC for the discussion]
> 
> Some motherboards have multiple HDA codecs connected to the serial bus.
> The current code may create multiple mixer controls with the almost
> identical identification.
> 
> The current code use id.device field from the control element structure
> to store the codec address to avoid such clashes for multiple codecs.
> Unfortunately, the user space do not handle this correctly. For mixer
> controls, only name and index are used for the identifiers.
> 
> This patch fixes this problem to compose the index using the codec
> address as an offset in case, when the control already exists. It is
> really unlikely that one codec will create 10 similar controls.
> 
> This patch adds new kernel module parameter 'ctl_dev_id' to allow
> select the old behaviour, too.
> 
> BugLink: https://github.com/alsa-project/alsa-lib/issues/294
> BugLink: https://github.com/alsa-project/alsa-lib/issues/205
> Fixes: 54d174031576 ("[ALSA] hda-codec - Fix connection list parsing")
> Fixes: 1afe206ab699 ("ALSA: hda - Try to find an empty control index when it's occupied")
> Signed-off-by: Jaroslav Kysela <perex at perex.cz>
> 
> --
> 
> Discussion:
> 
> There are several possibilities to handle the old behaviour - a kernel
> module parameter (proposed), a kernel configuration option or drop
> the old behaviour completely.

Dropping is likely no-go, as we don't even know whether it really
breaks or is safe, I suppose.  The module option sounds like a
feasible workaround, maybe with the default behavior defined by
kconfig.  And we can put some message for the old behavior to mention
it'll be deprecated, for example.  Then after some time, we can really
drop the old behavior, too.

One more question is which driver provides the option.  Does this
problem happen with SOF HDA driver, too?


thanks,

Takashi