Linux PCI subsystem development
 help / color / mirror / Atom feed
From: Peixin Xie <peixin.xie@linux.spacemit.com>
To: rafael@kernel.org
Cc: andriy.shevchenko@linux.intel.com, hansg@kernel.org,
	helgaas@kernel.org, ilpo.jarvinen@linux.intel.com,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-pm@vger.kernel.org,
	lukas@wunner.de, mika.westerberg@linux.intel.com,
	peixin.xie@linux.spacemit.com, sakari.ailus@linux.intel.com
Subject: Re: [PATCH v1 0/7] ACPI: scan: Address power management initialization and PCI devices handling
Date: Wed,  2 Sep 2026 20:42:05 +0800	[thread overview]
Message-ID: <20260902124205.1458089-1-peixin.xie@linux.spacemit.com> (raw)
In-Reply-To: <3435655.aeNJFYEL58@rafael.j.wysocki>

Hi Rafael,

On Mon, Aug 31, 2026 at 06:20:42PM +0200, Rafael J. Wysocki wrote:
> Hi All,
> 
> This series aims at addressing a few issues present in the core ACPI device
> enumeration code, mostly related to the acpi_bus_attach() function (that
> gets renamed in one of the patches).
> 
> The first one is that, on some systems, ACPI power management is initialized
> twice for devices that have missing dependencies to start with.  An attempt
> to address this issue had been made during the 7.3 merge window, but it had
> to be reverted [1].  The approach used here is roughly the same as in the
> reverted commit, but it takes PCI devices (which are a special case) into
> account.
> 
> The other issues are that flags are unnecessarily cleared by acpi_bus_attach()
> for devices with missing dependencies, the "initialized" ACPI device object
> flag is not particularly useful, the "visited" ACPI device object flag is
> used for two different things which is confusing at best, and that PCI
> devices are handled by acpi_bus_attach() like any other devices which is
> a mistake.
> 
> Please see the changelogs of individual patches for details.
> 
> I have tested this series on a couple of machines, but let's see what
> Sashiko has to say about it.
> 
> Thanks!

I tested the complete series on the SpacemiT K3 RISC-V Pico-ITX platform
where the original duplicate ACPI PowerResource reference issue was
observed.

The power resource left on by firmware is now turned off as unused after
the namespace scan. After the device dependency is satisfied, the power
resource is turned on once for the device and is turned off normally
during runtime suspend. Runtime resume also works correctly.

Tested-by: Peixin Xie <peixin.xie@linux.spacemit.com>

-- 
Best Regards,
Peixin Xie

      parent reply	other threads:[~2026-09-02 12:43 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-31 16:20 [PATCH v1 0/7] ACPI: scan: Address power management initialization and PCI devices handling Rafael J. Wysocki
2026-08-31 16:24 ` [PATCH v1 1/7] ACPI: scan: Stop calling acpi_bus_init_power() early Rafael J. Wysocki
2026-08-31 20:14   ` sashiko-bot
2026-09-01 17:31     ` Rafael J. Wysocki (Intel)
2026-09-01  8:27   ` Andy Shevchenko
2026-08-31 16:25 ` [PATCH v1 2/7] ACPI: PM: Introduce acpi_device_init_power() Rafael J. Wysocki
2026-08-31 20:25   ` sashiko-bot
2026-09-01  8:29   ` Andy Shevchenko
2026-09-01 16:38     ` Rafael J. Wysocki (Intel)
2026-08-31 17:59 ` [PATCH v1 3/7] ACPI: bus: Drop initialized flag from struct acpi_device_flags Rafael J. Wysocki
2026-08-31 21:03   ` sashiko-bot
2026-08-31 17:59 ` [PATCH v1 4/7] ACPI: scan: Combine two conditionals in acpi_bus_attach() Rafael J. Wysocki
2026-08-31 21:05   ` sashiko-bot
2026-09-01  8:40   ` Andy Shevchenko
2026-09-01 19:11     ` Rafael J. Wysocki (Intel)
2026-08-31 17:59 ` [PATCH v1 5/7] ACPI: scan: Add ACPI device "enumerated" marker Rafael J. Wysocki
2026-08-31 21:14   ` sashiko-bot
2026-08-31 17:59 ` [PATCH v1 6/7] ACPI: scan: Adjust and rename acpi_bus_attach() Rafael J. Wysocki
2026-08-31 21:17   ` sashiko-bot
2026-08-31 17:59 ` [PATCH v1 7/7] ACPI: scan: Take PCI device enumeration into account directly Rafael J. Wysocki
2026-08-31 21:23   ` sashiko-bot
2026-09-01  8:44   ` Andy Shevchenko
2026-09-01 19:14     ` Rafael J. Wysocki (Intel)
2026-09-02 12:42 ` Peixin Xie [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=20260902124205.1458089-1-peixin.xie@linux.spacemit.com \
    --to=peixin.xie@linux.spacemit.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=hansg@kernel.org \
    --cc=helgaas@kernel.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rafael@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox