[PATCH AUTOSEL 6.17-6.12] ACPI: scan: Update honor list for RPMI System MSI

[Sasha Levin]

From: Sunil V L <sunilvl at 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 at rivosinc.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki at intel.com>
Signed-off-by: Sunil V L <sunilvl at ventanamicro.com>
Signed-off-by: Anup Patel <apatel at ventanamicro.com>
Acked-by: Jassi Brar <jassisinghbrar at gmail.com>
Link: https://lore.kernel.org/r/20250818040920.272664-17-apatel@ventanamicro.com
Signed-off-by: Paul Walmsley <pjw at kernel.org>
Signed-off-by: Sasha Levin <sashal at 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
 };
-- 
2.51.0