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

[Takashi Iwai <tiwai@suse.de>]

On Wed, 16 Sep 2026 10:29:49 +0200,
Cezary Rojewski wrote:
> 
> 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.

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.


Takashi