Re: [PATCH] ALSA: hda: Allow for codec model selection with module param

[Cezary Rojewski <cezary.rojewski@intel.com>]

On 9/15/2026 6:02 PM, Takashi Iwai wrote:

>>>>>>>> Model selection allows for customization of codec behaviour and thus
>>>>>>>> dealing with various problems on very specific configurations. The
>>>>>>>> parameter already exists but is part of snd_hda_intel specifically.
>>>>>>>> Non-Intel HDAudio controllers and DSP-capable drivers cannot benefit
>>>>>>>> from it.
>>>>>>>>
>>>>>>>> The common place for all the bus drivers is snd_hda_codec. Add modelname
>>>>>>>> parameter there and honor it when initializing codec->modelname field.
>>>>>>>>
>>>>>>>> Link: https://github.com/thesofproject/linux/issues/5683
>>>>>>>> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
>>>>>>>
>>>>>>> The handling of the model option is a very long-standing PITA.
>>>>>>> A few years ago, I proposed a change like:
>>>>>>>   https://mailman.alsa-project.org/pipermail/alsa-devel/2022-September/206631.html
>>>>>>> but it didn't reach to agreement.  So I'm not 100% sure whether adding
>>>>>>> here is the best choice, either.
>>>>>> Thank you for the link, Takashi.
>>>>>>
>>>>>> IMHO patch presented here addresses the feedback. I too prefer
>>>>>> one-location-for-all approach. Also, I do believe having no option for
>>>>>> specifying the model is worse than choosing either of the approaches for
>>>>>> the model selection.
>>>>>>
>>>>>> snd_hda_codec module is *everywhere* and given the param is an array, it
>>>>>> supports even very complicated scenarios when multiple HDAudio codecs
>>>>>> are engaged.
>>>>>
>>>>> The multi-codec is exactly the problem I've been seeing (of course in
>>>>> addition to the lack of the option in ASoC HD-audio).  You'll have to
>>>>> be very careful how to pass the option, and it can be even fragile.
>>>>> That's why I hesitated to take this...
>>>> By multi-codec I also meant scenarios where one has 2+ codecs from one
>>>> vendor e.g.: realtek. Having non-array param e.g.: for
>>>> snd_hda_codec_realtek would not suffice.
>>>
>>> But those 2+ codecs are for the single device, right?  (e.g. driving
>>> multiple channels with multiple codecs, but all of them are a single
>>> device for user.)
>>>
>>> In theory, it can be a hotplug device, and in that case, we may have
>>> two device configurations for multiple codecs of the same codec chip.
>>> But, that's an exception, and I wonder whether we should care for the
>>> model option that is mainly used for debugging or workaround.
>> On reference setups we do anything. 2+ standalone codecs on HDAudio bus
>> in our lab is not some kind of sorcery. Obviously right now we
>> workaround the kernel by applying a bunch of patches. But adding a
>> module param (of type array) covers both: any userspace and any
>> reference scenario.
> 
> Well, using an array itself isn't a big problem.  The codec module
> option could be an array, too.
> 
> The problem I've been seeing is, however, that it's cumbersome to pass
> the arrays correctly if there are multiple devices.  Currently it
> depends on the controller probe order, and that's often unintuitive
> for users.  This problem still remains with your proposed change --
> even more confusing because now there are multiple entries but
> digested differently (imagine a combination of hda-intel and SOF).
> 
> So, obviously, I haven't found any good solution yet...
snd_hda_codec is fetched with SND_HDA kconfig which is always on when
SND_HDA_CORE is selected - this is true for both DSP drivers, avs-driver
and the sof-driver as both depend on SND_HDA_EXT_CORE:

	SND_HDA <- SND_HDA_CORE <- SND_HDA_EXT_CORE

Depending on dsp_driver, not selected drivers will quit probe() early
before the code gets to model assignment part.

And thus I'm not sure what you meant by "combination of hda-intel and
SOF".  At the same time not quite sure about "controller probe order"
issue either - bus->modelname and codec's model are two different
things.  It's likely I've missed something and if so, I'd greatly
appreciate additional input.

Kind regards,
Czarek