From: sashiko-bot@kernel.org
To: "Anup Patel" <anup.patel@oss.qualcomm.com>
Cc: devicetree@vger.kernel.org, conor+dt@kernel.org, robh@kernel.org
Subject: Re: [PATCH] driver core: platform: Setup device MSI domain just before driver probe
Date: Tue, 26 May 2026 15:44:04 +0000 [thread overview]
Message-ID: <20260526154405.579361F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260526145240.1627200-1-anup.patel@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Incorrect parameter passed to `of_msi_configure()` causes silent MSI domain configuration failures for devices where `dev->of_node` is NULL.
- [Medium] Removing explicit `-EPROBE_DEFER` causes permanent probe failures when MSI controllers probe later.
--
commit 117de411608386f49450165e5a9b44f955e55db1
Author: Anup Patel <anup.patel@oss.qualcomm.com>
driver core: platform: Setup device MSI domain just before driver probe
This commit moves the configuration of the device MSI domain for platform
devices into the platform_dma_configure() function. It removes the duplicate
domain setup and EPROBE_DEFER handling from individual RISC-V MSI client
drivers.
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index a19dd22deef2f..225e33080bc62 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -1470,8 +1470,12 @@ static int platform_dma_configure(struct device *dev)
> int ret = 0;
>
> if (is_of_node(fwnode)) {
> + if (!dev_get_msi_domain(dev))
> + of_msi_configure(dev, dev->of_node);
[Severity: High]
Does this code silently fail to configure the MSI domain for devices where
dev->of_node is NULL?
If a device is instantiated such that its fwnode is a valid OF node but its
primary dev->of_node is not explicitly populated (like some dynamically
created devices or MFD children), dev->of_node will be NULL.
Should this use to_of_node(fwnode) instead of dev->of_node, similar to the
of_dma_configure() call right below it?
> ret = of_dma_configure(dev, to_of_node(fwnode), true);
> } else if (is_acpi_device_node(fwnode)) {
[ ... ]
> diff --git a/drivers/irqchip/irq-riscv-aplic-msi.c b/drivers/irqchip/irq-riscv-aplic-msi.c
> index fb8d1838609fb..2cf5d42cd66a8 100644
> --- a/drivers/irqchip/irq-riscv-aplic-msi.c
> +++ b/drivers/irqchip/irq-riscv-aplic-msi.c
[ ... ]
> @@ -245,32 +244,6 @@ int aplic_msi_setup(struct device *dev, void __iomem *regs)
> /* Setup global config and interrupt delivery */
> aplic_init_hw_global(priv, true);
>
> - /* Set the APLIC device MSI domain if not available */
> - if (!dev_get_msi_domain(dev)) {
[ ... ]
> - if (!dev_get_msi_domain(dev))
> - return -EPROBE_DEFER;
> - }
[Severity: Medium]
Will removing this -EPROBE_DEFER fallback cause permanent probe failures if
fw_devlink is disabled (e.g., via fw_devlink=off) or fails to fully resolve
dependencies?
If the client device probes before the IMSIC controller in such scenarios,
dev_get_msi_domain(dev) will be NULL, and subsequent calls like
msi_create_device_irq_domain() might return false.
Would it be safer to retain a way to gracefully defer the probe here rather
than failing permanently?
> -
> if (!msi_create_device_irq_domain(dev, MSI_DEFAULT_DOMAIN, &aplic_msi_template,
> priv->nr_irqs + 1, priv, priv)) {
> dev_err(dev, "failed to create MSI irq domain\n");
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260526145240.1627200-1-anup.patel@oss.qualcomm.com?part=1
prev parent reply other threads:[~2026-05-26 15:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-26 14:52 [PATCH] driver core: platform: Setup device MSI domain just before driver probe Anup Patel
2026-05-26 14:52 ` Anup Patel
2026-05-26 15:22 ` Robin Murphy
2026-05-26 15:22 ` Robin Murphy
2026-06-03 6:44 ` Anup Patel
2026-06-03 6:44 ` Anup Patel
2026-05-26 15:44 ` sashiko-bot [this message]
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=20260526154405.579361F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=anup.patel@oss.qualcomm.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.