[PATCH] ALSA: hda: intel: Introduce msi64 parameter to override 64-bit MSI restriction

[PATCH] ALSA: hda: intel: Introduce msi64 parameter to override 64-bit MSI restriction

[Han Gao]

Sophgo SG2042 MSI driver does not support 32-bit MSI.
Introduce an 'msi64' kernel parameter to bypass NO_MSI64 for ATI/HDMI.

Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
---
 sound/hda/controllers/intel.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/sound/hda/controllers/intel.c b/sound/hda/controllers/intel.c
index 1e8e3d61291a..b4bad9e65235 100644
--- a/sound/hda/controllers/intel.c
+++ b/sound/hda/controllers/intel.c
@@ -121,6 +121,7 @@ static bool beep_mode[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS-1)] =
 #endif
 static bool dmic_detect = 1;
 static bool ctl_dev_id = IS_ENABLED(CONFIG_SND_HDA_CTL_DEV_ID) ? 1 : 0;
+static bool msi64;
 
 module_param_array(index, int, NULL, 0444);
 MODULE_PARM_DESC(index, "Index value for Intel HD audio interface.");
@@ -161,6 +162,8 @@ MODULE_PARM_DESC(dmic_detect, "Allow DSP driver selection (bypass this driver) "
 		 "deprecated, use snd-intel-dspcfg.dsp_driver option instead");
 module_param(ctl_dev_id, bool, 0444);
 MODULE_PARM_DESC(ctl_dev_id, "Use control device identifier (based on codec address).");
+module_param(msi64, bool, 0444);
+MODULE_PARM_DESC(msi64, "Force use msi 64bit.");
 
 #ifdef CONFIG_PM
 static int param_set_xint(const char *val, const struct kernel_param *kp);
@@ -1903,7 +1906,7 @@ static int azx_first_init(struct azx *chip)
 		chip->gts_present = true;
 #endif
 
-	if (chip->msi && chip->driver_caps & AZX_DCAPS_NO_MSI64) {
+	if (chip->msi && chip->driver_caps & AZX_DCAPS_NO_MSI64 && !msi64) {
 		dev_dbg(card->dev, "Disabling 64bit MSI\n");
 		pci->no_64bit_msi = true;
 	}
-- 
2.47.3


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH] ALSA: hda: intel: Introduce msi64 parameter to override 64-bit MSI restriction

[Han Gao]

Sophgo SG2042 MSI driver does not support 32-bit MSI.
Introduce an 'msi64' kernel parameter to bypass NO_MSI64 for ATI/HDMI.

Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
---
 sound/hda/controllers/intel.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/sound/hda/controllers/intel.c b/sound/hda/controllers/intel.c
index 1e8e3d61291a..b4bad9e65235 100644
--- a/sound/hda/controllers/intel.c
+++ b/sound/hda/controllers/intel.c
@@ -121,6 +121,7 @@ static bool beep_mode[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS-1)] =
 #endif
 static bool dmic_detect = 1;
 static bool ctl_dev_id = IS_ENABLED(CONFIG_SND_HDA_CTL_DEV_ID) ? 1 : 0;
+static bool msi64;
 
 module_param_array(index, int, NULL, 0444);
 MODULE_PARM_DESC(index, "Index value for Intel HD audio interface.");
@@ -161,6 +162,8 @@ MODULE_PARM_DESC(dmic_detect, "Allow DSP driver selection (bypass this driver) "
 		 "deprecated, use snd-intel-dspcfg.dsp_driver option instead");
 module_param(ctl_dev_id, bool, 0444);
 MODULE_PARM_DESC(ctl_dev_id, "Use control device identifier (based on codec address).");
+module_param(msi64, bool, 0444);
+MODULE_PARM_DESC(msi64, "Force use msi 64bit.");
 
 #ifdef CONFIG_PM
 static int param_set_xint(const char *val, const struct kernel_param *kp);
@@ -1903,7 +1906,7 @@ static int azx_first_init(struct azx *chip)
 		chip->gts_present = true;
 #endif
 
-	if (chip->msi && chip->driver_caps & AZX_DCAPS_NO_MSI64) {
+	if (chip->msi && chip->driver_caps & AZX_DCAPS_NO_MSI64 && !msi64) {
 		dev_dbg(card->dev, "Disabling 64bit MSI\n");
 		pci->no_64bit_msi = true;
 	}
-- 
2.47.3

Re: [PATCH] ALSA: hda: intel: Introduce msi64 parameter to override 64-bit MSI restriction

[Arnd Bergmann]

On Sat, Dec 20, 2025, at 18:05, Han Gao wrote:
> Sophgo SG2042 MSI driver does not support 32-bit MSI.
> Introduce an 'msi64' kernel parameter to bypass NO_MSI64 for ATI/HDMI.
>
> Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
> ---
> +module_param(msi64, bool, 0444);
> +MODULE_PARM_DESC(msi64, "Force use msi 64bit.");

This does not seem like an appropriate use for a module
parameter. There are very few things we want to use those
for in new code, and working around hardware bugs is
clearly not one.

> @@ -1903,7 +1906,7 @@ static int azx_first_init(struct azx *chip)
>  		chip->gts_present = true;
>  #endif
> 
> -	if (chip->msi && chip->driver_caps & AZX_DCAPS_NO_MSI64) {
> +	if (chip->msi && chip->driver_caps & AZX_DCAPS_NO_MSI64 && !msi64) {
>  		dev_dbg(card->dev, "Disabling 64bit MSI\n");
>  		pci->no_64bit_msi = true;
>  	}

The behavior is also wrong: if the system can use neither 32-bit
MSI nor 64-bit MSI, this would accidentally try to use the
64-bit variant and then cause runtime issues.

I would expect the only possible fallback to be using legacy IntX
interrupts, or returning a probe failure if that doesn't work
either.

      Arnd

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH] ALSA: hda: intel: Introduce msi64 parameter to override 64-bit MSI restriction

[Arnd Bergmann]

On Sat, Dec 20, 2025, at 18:05, Han Gao wrote:
> Sophgo SG2042 MSI driver does not support 32-bit MSI.
> Introduce an 'msi64' kernel parameter to bypass NO_MSI64 for ATI/HDMI.
>
> Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
> ---
> +module_param(msi64, bool, 0444);
> +MODULE_PARM_DESC(msi64, "Force use msi 64bit.");

This does not seem like an appropriate use for a module
parameter. There are very few things we want to use those
for in new code, and working around hardware bugs is
clearly not one.

> @@ -1903,7 +1906,7 @@ static int azx_first_init(struct azx *chip)
>  		chip->gts_present = true;
>  #endif
> 
> -	if (chip->msi && chip->driver_caps & AZX_DCAPS_NO_MSI64) {
> +	if (chip->msi && chip->driver_caps & AZX_DCAPS_NO_MSI64 && !msi64) {
>  		dev_dbg(card->dev, "Disabling 64bit MSI\n");
>  		pci->no_64bit_msi = true;
>  	}

The behavior is also wrong: if the system can use neither 32-bit
MSI nor 64-bit MSI, this would accidentally try to use the
64-bit variant and then cause runtime issues.

I would expect the only possible fallback to be using legacy IntX
interrupts, or returning a probe failure if that doesn't work
either.

      Arnd

Re: [PATCH] ALSA: hda: intel: Introduce msi64 parameter to override 64-bit MSI restriction

[Han Gao]

On Tue, Dec 23, 2025 at 1:01 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Sat, Dec 20, 2025, at 18:05, Han Gao wrote:
> > Sophgo SG2042 MSI driver does not support 32-bit MSI.
> > Introduce an 'msi64' kernel parameter to bypass NO_MSI64 for ATI/HDMI.
> >
> > Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
> > ---
> > +module_param(msi64, bool, 0444);
> > +MODULE_PARM_DESC(msi64, "Force use msi 64bit.");
>
> This does not seem like an appropriate use for a module
> parameter. There are very few things we want to use those
> for in new code, and working around hardware bugs is
> clearly not one.
>
> > @@ -1903,7 +1906,7 @@ static int azx_first_init(struct azx *chip)
> >               chip->gts_present = true;
> >  #endif
> >
> > -     if (chip->msi && chip->driver_caps & AZX_DCAPS_NO_MSI64) {
> > +     if (chip->msi && chip->driver_caps & AZX_DCAPS_NO_MSI64 && !msi64) {
> >               dev_dbg(card->dev, "Disabling 64bit MSI\n");
> >               pci->no_64bit_msi = true;
> >       }
>
> The behavior is also wrong: if the system can use neither 32-bit
> MSI nor 64-bit MSI, this would accidentally try to use the
> 64-bit variant and then cause runtime issues.
>
> I would expect the only possible fallback to be using legacy IntX
> interrupts, or returning a probe failure if that doesn't work

Unfortunately, the SG2042 chip does not have an available legacy INTx.

db79afa1e57925ba96ab18514c0ebe42a28e393e
91ed6fd2c383bb8f02d66e98b4a4d2f7207249dc

According to these two commits, these issues seem to be caused by powerpc.
Can we use the CONFIG_PPC64 macro to determine this?

> either.
>
>       Arnd

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH] ALSA: hda: intel: Introduce msi64 parameter to override 64-bit MSI restriction

[Han Gao]

On Tue, Dec 23, 2025 at 1:01 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Sat, Dec 20, 2025, at 18:05, Han Gao wrote:
> > Sophgo SG2042 MSI driver does not support 32-bit MSI.
> > Introduce an 'msi64' kernel parameter to bypass NO_MSI64 for ATI/HDMI.
> >
> > Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
> > ---
> > +module_param(msi64, bool, 0444);
> > +MODULE_PARM_DESC(msi64, "Force use msi 64bit.");
>
> This does not seem like an appropriate use for a module
> parameter. There are very few things we want to use those
> for in new code, and working around hardware bugs is
> clearly not one.
>
> > @@ -1903,7 +1906,7 @@ static int azx_first_init(struct azx *chip)
> >               chip->gts_present = true;
> >  #endif
> >
> > -     if (chip->msi && chip->driver_caps & AZX_DCAPS_NO_MSI64) {
> > +     if (chip->msi && chip->driver_caps & AZX_DCAPS_NO_MSI64 && !msi64) {
> >               dev_dbg(card->dev, "Disabling 64bit MSI\n");
> >               pci->no_64bit_msi = true;
> >       }
>
> The behavior is also wrong: if the system can use neither 32-bit
> MSI nor 64-bit MSI, this would accidentally try to use the
> 64-bit variant and then cause runtime issues.
>
> I would expect the only possible fallback to be using legacy IntX
> interrupts, or returning a probe failure if that doesn't work

Unfortunately, the SG2042 chip does not have an available legacy INTx.

db79afa1e57925ba96ab18514c0ebe42a28e393e
91ed6fd2c383bb8f02d66e98b4a4d2f7207249dc

According to these two commits, these issues seem to be caused by powerpc.
Can we use the CONFIG_PPC64 macro to determine this?

> either.
>
>       Arnd

Re: [PATCH] ALSA: hda: intel: Introduce msi64 parameter to override 64-bit MSI restriction

[Arnd Bergmann]

On Tue, Dec 23, 2025, at 10:40, Han Gao wrote:
> On Tue, Dec 23, 2025 at 1:01 AM Arnd Bergmann <arnd@arndb.de> wrote:
>> On Sat, Dec 20, 2025, at 18:05, Han Gao wrote:
>> >
>> > -     if (chip->msi && chip->driver_caps & AZX_DCAPS_NO_MSI64) {
>> > +     if (chip->msi && chip->driver_caps & AZX_DCAPS_NO_MSI64 && !msi64) {
>> >               dev_dbg(card->dev, "Disabling 64bit MSI\n");
>> >               pci->no_64bit_msi = true;
>> >       }
>>
>> The behavior is also wrong: if the system can use neither 32-bit
>> MSI nor 64-bit MSI, this would accidentally try to use the
>> 64-bit variant and then cause runtime issues.
>>
>> I would expect the only possible fallback to be using legacy IntX
>> interrupts, or returning a probe failure if that doesn't work
>
> Unfortunately, the SG2042 chip does not have an available legacy INTx.

Doesn't that mean that you can only use PCI drivers that enable
MSI at all? From what I can tell, only about a third of all
pci_driver instances do.

> db79afa1e57925ba96ab18514c0ebe42a28e393e
> 91ed6fd2c383bb8f02d66e98b4a4d2f7207249dc
>
> According to these two commits, these issues seem to be caused by powerpc.
> Can we use the CONFIG_PPC64 macro to determine this?

I wouldn't consider it a PPC64 specific issue, from my interpretation
this is the same issue as in the radeon driver, where the MSI
is limited by the DMA mask of the device, and the correct way to
do it is to check the mask while enabling an MSI, instead of
assuming that any high address is broken.

     Arnd

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH] ALSA: hda: intel: Introduce msi64 parameter to override 64-bit MSI restriction

[Arnd Bergmann]

On Tue, Dec 23, 2025, at 10:40, Han Gao wrote:
> On Tue, Dec 23, 2025 at 1:01 AM Arnd Bergmann <arnd@arndb.de> wrote:
>> On Sat, Dec 20, 2025, at 18:05, Han Gao wrote:
>> >
>> > -     if (chip->msi && chip->driver_caps & AZX_DCAPS_NO_MSI64) {
>> > +     if (chip->msi && chip->driver_caps & AZX_DCAPS_NO_MSI64 && !msi64) {
>> >               dev_dbg(card->dev, "Disabling 64bit MSI\n");
>> >               pci->no_64bit_msi = true;
>> >       }
>>
>> The behavior is also wrong: if the system can use neither 32-bit
>> MSI nor 64-bit MSI, this would accidentally try to use the
>> 64-bit variant and then cause runtime issues.
>>
>> I would expect the only possible fallback to be using legacy IntX
>> interrupts, or returning a probe failure if that doesn't work
>
> Unfortunately, the SG2042 chip does not have an available legacy INTx.

Doesn't that mean that you can only use PCI drivers that enable
MSI at all? From what I can tell, only about a third of all
pci_driver instances do.

> db79afa1e57925ba96ab18514c0ebe42a28e393e
> 91ed6fd2c383bb8f02d66e98b4a4d2f7207249dc
>
> According to these two commits, these issues seem to be caused by powerpc.
> Can we use the CONFIG_PPC64 macro to determine this?

I wouldn't consider it a PPC64 specific issue, from my interpretation
this is the same issue as in the radeon driver, where the MSI
is limited by the DMA mask of the device, and the correct way to
do it is to check the mask while enabling an MSI, instead of
assuming that any high address is broken.

     Arnd

Re: [PATCH] ALSA: hda: intel: Introduce msi64 parameter to override 64-bit MSI restriction

[Takashi Iwai]

On Sat, 20 Dec 2025 18:05:01 +0100,
Han Gao wrote:
> 
> Sophgo SG2042 MSI driver does not support 32-bit MSI.
> Introduce an 'msi64' kernel parameter to bypass NO_MSI64 for ATI/HDMI.
> 
> Signed-off-by: Han Gao <gaohan@iscas.ac.cn>

As Arnd already suggested, there is no reason to add a new module
option just for this case.

If any, we can add a device-specific quirk entry, but it should be
investigated more deeply at first.


thanks,

Takashi

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH] ALSA: hda: intel: Introduce msi64 parameter to override 64-bit MSI restriction

[Takashi Iwai]

On Sat, 20 Dec 2025 18:05:01 +0100,
Han Gao wrote:
> 
> Sophgo SG2042 MSI driver does not support 32-bit MSI.
> Introduce an 'msi64' kernel parameter to bypass NO_MSI64 for ATI/HDMI.
> 
> Signed-off-by: Han Gao <gaohan@iscas.ac.cn>

As Arnd already suggested, there is no reason to add a new module
option just for this case.

If any, we can add a device-specific quirk entry, but it should be
investigated more deeply at first.


thanks,

Takashi