[PATCH] ALSA: hda: intel: Introduce msi64 parameter to override 64-bit MSI restriction
Arnd Bergmann
arnd at arndb.de
Tue Dec 23 02:44:12 PST 2025
On Tue, Dec 23, 2025, at 10:40, Han Gao wrote:
> On Tue, Dec 23, 2025 at 1:01 AM Arnd Bergmann <arnd at 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
More information about the linux-riscv
mailing list