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

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

[Cezary Rojewski]

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>
---
 sound/hda/common/codec.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/sound/hda/common/codec.c b/sound/hda/common/codec.c
index 7d17d773cfbf..73b0009a0395 100644
--- a/sound/hda/common/codec.c
+++ b/sound/hda/common/codec.c
@@ -32,6 +32,10 @@
 #define codec_has_clkstop(codec) \
 	((codec)->core.power_caps & AC_PWRST_CLKSTOP)
 
+static char *modelname[HDA_MAX_CODEC_ADDRESS];
+module_param_array_named(model, modelname, charp, NULL, 0444);
+MODULE_PARM_DESC(model, "Use the given board model.");
+
 static int call_exec_verb(struct hda_bus *bus, struct hda_codec *codec,
 			  unsigned int cmd, unsigned int flags,
 			  unsigned int *res)
@@ -966,6 +970,7 @@ int snd_hda_codec_device_new(struct hda_bus *bus, struct snd_card *card,
 			bool snddev_managed)
 {
 	char component[31];
+	const char *mname;
 	hda_nid_t fg;
 	int err;
 	static const struct snd_device_ops dev_ops = {
@@ -988,8 +993,9 @@ int snd_hda_codec_device_new(struct hda_bus *bus, struct snd_card *card,
 
 	snd_hda_sysfs_init(codec);
 
-	if (codec->bus->modelname) {
-		codec->modelname = kstrdup(codec->bus->modelname, GFP_KERNEL);
+	mname = bus->modelname ? bus->modelname : modelname[codec_addr];
+	if (mname && strlen(mname)) {
+		codec->modelname = kstrdup(mname, GFP_KERNEL);
 		if (!codec->modelname)
 			return -ENOMEM;
 	}
-- 
2.34.1

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

[Takashi Iwai]

On Mon, 14 Sep 2026 12:22:53 +0200,
Cezary Rojewski 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.


thanks,

Takashi

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

[Cezary Rojewski]

On 9/14/2026 6:01 PM, Takashi Iwai wrote:
> On Mon, 14 Sep 2026 12:22:53 +0200,
> Cezary Rojewski 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.

Kind regards,
Czarek

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

[Takashi Iwai]

On Mon, 14 Sep 2026 18:29:19 +0200,
Cezary Rojewski wrote:
> 
> On 9/14/2026 6:01 PM, Takashi Iwai wrote:
> > On Mon, 14 Sep 2026 12:22:53 +0200,
> > Cezary Rojewski 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...


thanks,

Takashi

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

[Cezary Rojewski]

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.

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

[Takashi Iwai]

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.


thanks,

Takashi

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

[Cezary Rojewski]

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.

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

[Takashi Iwai]

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

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

[Cezary Rojewski]

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

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

[Takashi Iwai]

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

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

[Cezary Rojewski]

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

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

[Takashi Iwai]

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