| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20260127172557.GA364754@bhelgaas>
Date: Tue, 27 Jan 2026 11:25:57 -0600
From: Bjorn Helgaas <helgaas@...nel.org>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: huyuye <huyuye812@....com>, Bjorn Helgaas <bhelgaas@...gle.com>,
Sunil V L <sunilvl@...tanamicro.com>,
Paul Walmsley <pjw@...nel.org>, Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>,
Robert Moore <robert.moore@...el.com>, linux-pci@...r.kernel.org,
linux-acpi@...r.kernel.org, linux-riscv@...ts.infradead.org,
linux-kernel@...r.kernel.org, dai.hualiang@....com.cn,
deng.weixian@....com.cn, guo.chang2@....com.cn,
liu.qingtao2@....com.cn, wu.jiabao@....com.cn,
lin.yongchun@....com.cn, hu.yuye@....com.cn,
zhang.longxiang@....com.cn, zuo.jiang@....com.cn,
li.kunpeng@....com.cn
Subject: Re: [PATCH v2] ACPI: pci_root: Clear the acpi dependencies after PCI
root bridge initialization on RISC-V
On Tue, Jan 27, 2026 at 04:00:49PM +0100, Rafael J. Wysocki wrote:
> On Mon, Jan 12, 2026 at 3:17 PM huyuye <huyuye812@....com> wrote:
> >
> > Hi Rafael,
> > Thank you for your thorough review and valuable comments on v1.
> > I've updated the patch as follows:
> > 1. Removed the redundant #ifdef CONFIG_ACPI and if (!acpi_disabled)
> > guard as you pointed out. The entire code block indeed already depends
> > on CONFIG_ACPI at a higher level, making the inner guard unnecessary.
> > 2. Moved acpi_dev_clear_dependencies to RISC-V specific architecture
> > code (driver/acpi/riscv/acpi_pci.c). This ensures that ACPI dependency
> > clearing is handled within the appropriate architectural context.
> >
> > Best regards
> > Signed-off-by: huyuye <huyuye812@....com>
> > ---
> > drivers/acpi/pci_root.c | 6 ++++++
> > drivers/acpi/riscv/Makefile | 2 +-
> > drivers/acpi/riscv/acpi_pci.c | 11 +++++++++++
> > include/acpi/acpi_bus.h | 1 +
> > 4 files changed, 19 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/acpi/riscv/acpi_pci.c
> >
> > diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> > index 9d7f85dadc48..a16eb9097cdc 100644
> > --- a/drivers/acpi/pci_root.c
> > +++ b/drivers/acpi/pci_root.c
> > @@ -30,6 +30,11 @@ static int acpi_pci_root_add(struct acpi_device *device,
> > const struct acpi_device_id *not_used);
> > static void acpi_pci_root_remove(struct acpi_device *device);
> >
> > +
> > +void __weak arch_acpi_pci_root_add_clear_dep(struct acpi_device *device)
> > +{
> > +}
> > +
> > static int acpi_pci_root_scan_dependent(struct acpi_device *adev)
> > {
> > acpiphp_check_host_bridge(adev);
> > @@ -760,6 +765,7 @@ static int acpi_pci_root_add(struct acpi_device *device,
> > pci_lock_rescan_remove();
> > pci_bus_add_devices(root->bus);
> > pci_unlock_rescan_remove();
> > + arch_acpi_pci_root_add_clear_dep(device);
>
> Actually, this could be as simple as
>
> if (IS_ENABLED(CONFIG_RISCV))
> acpi_dev_clear_dependencies(device);
>
> with a brief comment explaining why it is needed.
>
> Bjorn, any thoughts?
The justification ("If a host bridge B depends on host bridge A (via
_DEP), this call allows bridge B to proceed with enumeration after
bridge A is fully initialized") doesn't sound specific to RISC-V.
For that matter, it doesn't sound specific to host bridges either.
The _DEP spec language is a bit vague. ACPI r6.6, sec 6.5.8, says:
_DEP evaluates to a package and designates device objects that OSPM
should assign a higher priority in start ordering due to
dependencies between devices (for example, related to future
operation region accesses).
I don't know what "device start" means. It sounds like this alludes
to the order in which OSPM runs some device start method? _INI?
Should acpi_dev_clear_dependencies() be done at the point where that
device start method is run?
> > return 1;
> >
> > remove_dmar:
> > diff --git a/drivers/acpi/riscv/Makefile b/drivers/acpi/riscv/Makefile
> > index 1284a076fa88..5b1bd0298fb9 100644
> > --- a/drivers/acpi/riscv/Makefile
> > +++ b/drivers/acpi/riscv/Makefile
> > @@ -1,5 +1,5 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > -obj-y += rhct.o init.o irq.o
> > +obj-y += rhct.o init.o irq.o acpi_pci.o
> > obj-$(CONFIG_ACPI_PROCESSOR_IDLE) += cpuidle.o
> > obj-$(CONFIG_ACPI_CPPC_LIB) += cppc.o
> > obj-$(CONFIG_ACPI_RIMT) += rimt.o
> > diff --git a/drivers/acpi/riscv/acpi_pci.c b/drivers/acpi/riscv/acpi_pci.c
> > new file mode 100644
> > index 000000000000..368ff113e5c6
> > --- /dev/null
> > +++ b/drivers/acpi/riscv/acpi_pci.c
> > @@ -0,0 +1,11 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2026, ZTE Corporation
> > + * Author: Yu Ye Hu <hu.yuye@....com.cn>
> > + */
> > +#include <linux/acpi.h>
> > +
> > +void arch_acpi_pci_root_add_clear_dep(struct acpi_device *device)
> > +{
> > + acpi_dev_clear_dependencies(device);
> > +}
> > diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> > index aad1a95e6863..c00b523a6ebd 100644
> > --- a/include/acpi/acpi_bus.h
> > +++ b/include/acpi/acpi_bus.h
> > @@ -996,6 +996,7 @@ int acpi_wait_for_acpi_ipmi(void);
> >
> > int acpi_scan_add_dep(acpi_handle handle, struct acpi_handle_list *dep_devices);
> > u32 arch_acpi_add_auto_dep(acpi_handle handle);
> > +void arch_acpi_pci_root_add_clear_dep(struct acpi_device *device);
> > #else /* CONFIG_ACPI */
> >
> > static inline int register_acpi_bus_type(void *bus) { return 0; }
> > --
> > 2.43.0
> >
Powered by blists - more mailing lists