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

[Takashi Iwai <tiwai@suse.de>]

On Fri, 18 Sep 2026 10:33:00 +0200,
Cezary Rojewski wrote:
> 
> 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

There is already a handling with a colon in the model option as an
alias, so this syntax would conflict.  I think it can be something
with '@', e.g. model=something@bus. (Or other way round).
It's still an open question how the bus should be represented, though.

And, there can be the cases where you want to specify a different
quirk per codec address for multiple codecs.  This would need an
extension of the model string syntax, too.

So, overall, we need some redesign, I suppose.


thanks,

Takashi