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

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

On 9/16/2026 12:57 PM, Takashi Iwai wrote:

>>>>> 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.
> 
> Basically the model option is passed per controller, not per codec.
> 
> So, if you have two HDMI controllers (e.g. built-in audio and HDMI on
> d-GPU), it's common that they are bound to different drivers (ASoC and
> hda-intel) on the same machine.
> Now when you pass the model option to snd-hda-intel, only the HDMI
> controller takes it.  Meanwhile, if you pass the same model option to
> snd-hda-codec, it's taken from both, and the order matters, and you'd
> have to be very careful at which position you'd have to put.
> That is, the same model option, but they have different values.

Marvelous! Thank you for the example.  I was typically using a FPGA for
multi-bus tests, oh well..
In such case I do not see us avoiding the bus' modelname when specifying
the quirks e.g.:

	// array param, [SND_MAX_CARDS]
	model=my_bus_xyz:my_codec_abc,my_bus_123:my_codec_890