mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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
>

  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®