From: Sunil V L sunilvl@ventanamicro.com
[ Upstream commit 4215d1cf59e4b272755f4277a05cd5967935a704 ]
The RPMI System MSI interrupt controller (just like PLIC and APLIC) needs to probed prior to devices like GED which use interrupts provided by it. Also, it has dependency on the SBI MPXY mailbox device.
Add HIDs of RPMI System MSI and SBI MPXY mailbox devices to the honor list so that those dependencies are handled.
Reviewed-by: Atish Patra atishp@rivosinc.com Reviewed-by: Andy Shevchenko andriy.shevchenko@linux.intel.com Acked-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Sunil V L sunilvl@ventanamicro.com Signed-off-by: Anup Patel apatel@ventanamicro.com Acked-by: Jassi Brar jassisinghbrar@gmail.com Link: https://lore.kernel.org/r/20250818040920.272664-17-apatel@ventanamicro.com Signed-off-by: Paul Walmsley pjw@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES **Why** - The patch extends the `_DEP` honor list in `drivers/acpi/scan.c:856-866` so that ACPI dependencies pointing at the SBI MPXY mailbox (`RSCV0005`) and RPMI System MSI controller (`RSCV0006`) are actually enforced. Without these entries, `acpi_scan_add_dep()` never sets `dep->honor_dep` for those HIDs (`drivers/acpi/scan.c:2034-2049`), leaving `device->flags.honor_deps` clear and allowing consumers to enumerate even when their IRQ provider/mailbox is missing, because `acpi_dev_ready_for_enumeration()` only blocks devices when both `honor_deps` and `dep_unmet` are set (`drivers/acpi/scan.c:2481-2486`). - On RISC-V ACPI systems the arch helper builds implicit dependencies between devices and their interrupt controllers (`drivers/acpi/riscv/irq.c:340-404`). GED and other consumers therefore get `_DEP` entries that reference the RPMI System MSI node. If the honor flag is missing, GED can probe before the MSI domain exists, causing its interrupt setup to fail. - The RPMI System MSI driver itself requires the MPXY mailbox to be ready; it immediately requests a mailbox channel in probe (`drivers/irqchip/irq-riscv-rpmi-sysmsi.c:223-233`). A premature probe hits `-EPROBE_DEFER`, and without the dependency being honored the driver keeps churning instead of waiting for the mailbox to finish. - Both suppliers call `acpi_dev_clear_dependencies()` once they succeed (`drivers/irqchip/irq-riscv-rpmi-sysmsi.c:298-303`, `drivers/mailbox/riscv-sbi-mpxy-mbox.c:974-979`), so honoring their `_DEP`s restores the intended sequencing with no behavioral change elsewhere. - Change risk is minimal: it only adds two strings, matching the precedent already in place for other RISC-V interrupt controllers. It fixes a user-visible failure (missing interrupts / repeated probe defers) on ACPI RISC-V platforms that already shipped the new RPMI + MPXY support.
**Next Step** - Boot-test on an ACPI RISC-V platform using RPMI/MPXY to confirm GED and dependent devices enumerate cleanly once the MSI controller and mailbox load.
drivers/acpi/scan.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index fb1fe9f3b1a36..54181b03b345b 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -858,6 +858,8 @@ static const char * const acpi_honor_dep_ids[] = { "INTC10CF", /* IVSC (MTL) driver must be loaded to allow i2c access to camera sensors */ "RSCV0001", /* RISC-V PLIC */ "RSCV0002", /* RISC-V APLIC */ + "RSCV0005", /* RISC-V SBI MPXY MBOX */ + "RSCV0006", /* RISC-V RPMI SYSMSI */ "PNP0C0F", /* PCI Link Device */ NULL };