All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v2 6/6] ACPI: scan: Take PCI device enumeration into account directly
Date: Wed, 02 Sep 2026 20:51:40 +0000	[thread overview]
Message-ID: <20260902205141.4DF4D1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <6207934.MhkbZ0Pkbq@rafael.j.wysocki>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Bypassing `acpi_bus_get_status()` for PCI companions leaves `device->status` stale, which can cause `acpi_device_is_present()` to incorrectly return false.
--

commit 7f00077fea1f2ada305a470b1a050f31934232c4
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI: scan: Take PCI device enumeration into account directly

This commit skips evaluating ACPI device status during hierarchy walks
for devices already associated with a PCI companion, assuming they are
present and functional because the PCI devices are already enumerated.

> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index f4718b0207e0e..34f7f477a25ad 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
[ ... ]
> @@ -2353,10 +2355,26 @@ static int attach_subtree(struct acpi_device *device, void *not_used)
>  	if (ACPI_SUCCESS(acpi_bus_get_ejd(device->handle, &ejd)))
>  		register_dock_dependent_device(device, ejd);
>  
> -	acpi_bus_get_status(device);
> -	/* Skip devices that are not ready for enumeration (e.g. not present) */
> -	if (!acpi_dev_ready_for_enumeration(device))
> -		return 0;
> +	/*
> +	 * If the given ACPI device object has been already associated with a
> +	 * PCI device found on the bus, its status is effectively "present
> +	 * and functional".
> +	 */
> +	pci = acpi_dev_get_pci_dev(device);
> +	if (pci) {
> +		acpi_handle_debug(device->handle, "PCI companion %s found\n",
> +				  pci_name(pci));
> +
> +		pci_dev_put(pci);
> +	} else {

[Severity: High]
Bypassing acpi_bus_get_status() for PCI companions leaves device->status
stale. Could this cause acpi_device_is_present() to incorrectly return false?

If the initial evaluation of the device status returned 0 (e.g., due to unmet
dependencies at boot or firmware quirks), device->status.present will remain
0 permanently because it is not explicitly updated here to reflect the
"present and functional" assumption.

This stale status might prevent ACPI power management features, such as
acpi_device_fix_up_power(), and other subsystems relying on
acpi_device_is_present() from properly operating on the device.

> +		acpi_bus_get_status(device);
> +		/*
> +		 * Skip devices that are not ready for enumeration (e.g. not
> +		 * present).
> +		 */
> +		if (!acpi_dev_ready_for_enumeration(device))
> +			return 0;
> +	}
>  
>  	acpi_ec_register_opregions(device);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/5144065.31r3eYUQgx@rafael.j.wysocki?part=6

  reply	other threads:[~2026-09-02 20:51 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02 19:21 [PATCH v2 0/6] ACPI: scan: Adjust power management initialization and PCI devices handling Rafael J. Wysocki
2026-09-02 19:24 ` [PATCH v2 1/6] ACPI: PM: Drop parent state update from acpi_device_get_power() Rafael J. Wysocki
2026-09-02 19:44   ` sashiko-bot
2026-09-02 19:26 ` [PATCH v2 2/6] ACPI: scan: Stop calling acpi_bus_init_power() early Rafael J. Wysocki
2026-09-02 19:58   ` sashiko-bot
2026-09-02 19:30 ` [PATCH v2 3/6] ACPI: scan: Combine two conditionals in acpi_bus_attach() Rafael J. Wysocki
2026-09-02 20:01   ` sashiko-bot
2026-09-03  7:27   ` Andy Shevchenko
2026-09-02 19:33 ` [PATCH v2 4/6] ACPI: scan: Add ACPI device enumerated marker Rafael J. Wysocki
2026-09-02 20:26   ` sashiko-bot
2026-09-02 19:35 ` [PATCH v2 5/6] ACPI: scan: Adjust and rename acpi_bus_attach() Rafael J. Wysocki
2026-09-02 20:30   ` sashiko-bot
2026-09-02 19:36 ` [PATCH v2 6/6] ACPI: scan: Take PCI device enumeration into account directly Rafael J. Wysocki
2026-09-02 20:51   ` sashiko-bot [this message]
2026-09-03  8:12   ` Andy Shevchenko

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=20260902205141.4DF4D1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rafael@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.