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

[Takashi Iwai <tiwai@suse.de>]

On Tue, 15 Sep 2026 13:26:11 +0200,
Cezary Rojewski wrote:
> 
> On 9/15/2026 1:14 PM, Takashi Iwai wrote:
> > On Mon, 14 Sep 2026 19:58:05 +0200,
> > Cezary Rojewski wrote:
> >>
> >> On 9/14/2026 6:44 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...


thanks,

Takashi