From: fangyu.yu@linux.alibaba.com
To: sunilvl@oss.qualcomm.com
Cc: ajones@ventanamicro.com, alex@ghiti.fr,
andrew.jones@oss.qualcomm.com, aou@eecs.berkeley.edu,
fangyu.yu@linux.alibaba.com, guoren@kernel.org,
iommu@lists.linux.dev, joro@8bytes.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
palmer@dabbelt.com, pjw@kernel.org, robin.murphy@arm.com,
tomasz.jeznach@linux.dev, will@kernel.org
Subject: Re: [PATCH] iommu/riscv: prefer WSI on IGS=BOTH when wired IRQs are described
Date: Wed, 20 May 2026 17:54:11 +0800 [thread overview]
Message-ID: <20260520095411.92045-1-fangyu.yu@linux.alibaba.com> (raw)
In-Reply-To: <CAB19ukGk2AUA3yjsrBxjsUsH9pUSeeu5F6vo1FFBcd504VQPzg@mail.gmail.com>
>>
>> From: Fangyu Yu <fangyu.yu@linux.alibaba.com>
>>
>> The RISC-V IOMMU spec defines IGS=BOTH as supporting both MSI and
>> WSI, with software selecting the path. The DT path already behaves
>> as expected by selecting WSI when wired IRQ resources are described.
>> The ACPI path, however, currently falls back to MSI even when
>> firmware describes wired IRQ resources.
>>
>> Use firmware-described wired IRQ resources as the trigger to select
>> WSI for IGS=BOTH:
>> - DT: "interrupts" present, no "msi-parent"
>> - ACPI: DSDT _CRS Interrupt() descriptors
>> (mainline does not yet parse the RIMT Interrupt Wire Array)
>>
>> When triggered, rewrite igs to IGS_WSI and reuse the existing WSI
>> handling. Keep the existing behaviour otherwise.
>>
>> Fixes: d5f88acdd6ff ("iommu/riscv: Add support for platform msi")
>> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com>
>> ---
>> drivers/iommu/riscv/iommu-platform.c | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/iommu/riscv/iommu-platform.c b/drivers/iommu/riscv/iommu-platform.c
>> index 399ba8fe1b3e..bd7712231140 100644
>> --- a/drivers/iommu/riscv/iommu-platform.c
>> +++ b/drivers/iommu/riscv/iommu-platform.c
>> @@ -71,6 +71,21 @@ static int riscv_iommu_platform_probe(struct platform_device *pdev)
>> iommu->irqs_count = RISCV_IOMMU_INTR_COUNT;
>>
>> igs = FIELD_GET(RISCV_IOMMU_CAPABILITIES_IGS, iommu->caps);
>> +
>> + /*
>> + * IGS=BOTH means the IOMMU supports either MSI or WSI;
>> + * the spec leaves the choice to software. Use the firmware-described
>> + * wired interrupt resources as the trigger:
>> + * - DT : "interrupts" property present, no "msi-parent" -> WSI
>> + * - ACPI: DSDT _CRS Interrupt() present -> WSI
>> + * Otherwise default to the MSI path.
>> + */
>> + if (igs == RISCV_IOMMU_CAPABILITIES_IGS_BOTH &&
>> + platform_irq_count(pdev) > 0) {
>> + dev_info(dev, "firmware describes wired IRQs; preferring WSI on IGS=BOTH\n");
>> + igs = RISCV_IOMMU_CAPABILITIES_IGS_WSI;
>> + }
>> +
>Won't it change the DT behavior as it doesn't check msi-parent
>anymore? IOW, should this be made specific to ACPI
>by checking whether the device node is acpi node?
>
Thanks for the review, you're right that the current condition would
affect DT as well.
My assumption was that DT would describe either "interrupts" for WSI
or "msi-parent" for MSI, but not both, so platform_irq_count() > 0
would effectively imply "no msi-parent" in practice.
That said, I agree that this should be limited to the ACPI path. That
matches the actual bug scope — only ACPI was falling back to MSI when
wired IRQs were described — and leaves DT unchanged.
I'll respin a v2 to scope the fix to ACPI only, and tighten the commit
message accordingly.
Thanks,
Fangyu
>Thanks,
>Sunil
>
next prev parent reply other threads:[~2026-05-20 9:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-19 12:57 fangyu.yu
2026-05-20 7:45 ` Sunil V L
2026-05-20 9:54 ` fangyu.yu [this message]
2026-05-20 12:25 ` Robin Murphy
2026-05-20 13:44 ` fangyu.yu
2026-05-20 16:03 ` Andrew Jones
2026-05-20 16:13 ` Robin Murphy
2026-05-20 16:03 ` Robin Murphy
2026-05-21 11:21 ` fangyu.yu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260520095411.92045-1-fangyu.yu@linux.alibaba.com \
--to=fangyu.yu@linux.alibaba.com \
--cc=ajones@ventanamicro.com \
--cc=alex@ghiti.fr \
--cc=andrew.jones@oss.qualcomm.com \
--cc=aou@eecs.berkeley.edu \
--cc=guoren@kernel.org \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=robin.murphy@arm.com \
--cc=sunilvl@oss.qualcomm.com \
--cc=tomasz.jeznach@linux.dev \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®