[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aMfyqjZZwozuRmW_@kekkonen.localdomain>
Date: Mon, 15 Sep 2025 14:04:10 +0300
From: Sakari Ailus <sakari.ailus@...ux.intel.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Linux ACPI <linux-acpi@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Subject: Re: [PATCH v1 1/4] ACPI: property: Fix buffer properties extraction
for subnodes
Hi Rafael,
On Fri, Sep 12, 2025 at 09:39:52PM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>
> The ACPI handle passed to acpi_extract_properties() as the first
> argument represents the ACPI namespace scope in which to look for
> objects returning buffers associated with buffer properties.
>
> For _DSD objects located immediately under ACPI devices, this handle is
> the same as the handle of the device object holding the _DSD, but for
> data-only subnodes it is not so.
>
> First of all, data-only subnodes are represented by objects that
> cannot hold other objects in their scopes (like control methods).
> Therefore a data-only subnode handle cannot be used for completing
> relative pathname segments, so the current code in
> in acpi_nondev_subnode_extract() passing a data-only subnode handle
> to acpi_extract_properties() is invalid.
>
> Moreover, a data-only subnode of device A may be represented by an
> object located in the scope of device B (which kind of makes sense,
> for instance, if A is a B's child). In that case, the scope in
> question would be the one of device B. In other words, the scope
> mentioned above is the same as the scope used for subnode object
> lookup in acpi_nondev_subnode_extract().
>
> Accordingly, rearrange that function to use the same scope for the
> extraction of properties and subnode object lookup.
>
> Fixes: 103e10c69c61 ("ACPI: property: Add support for parsing buffer property UUID")
I believe the commit introducing this is
99db5ff7fe0b4e1657423d7bbe2aa8f655dd02d1 .
> Cc: 6.0+ <stable@...r.kernel.org> # 6.0+
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> ---
> drivers/acpi/property.c | 30 +++++++++++-------------------
> 1 file changed, 11 insertions(+), 19 deletions(-)
>
> --- a/drivers/acpi/property.c
> +++ b/drivers/acpi/property.c
> @@ -83,6 +83,7 @@ static bool acpi_nondev_subnode_extract(
> struct fwnode_handle *parent)
> {
> struct acpi_data_node *dn;
> + acpi_handle scope = NULL;
> bool result;
>
> if (acpi_graph_ignore_port(handle))
> @@ -98,27 +99,18 @@ static bool acpi_nondev_subnode_extract(
> INIT_LIST_HEAD(&dn->data.properties);
> INIT_LIST_HEAD(&dn->data.subnodes);
>
> - result = acpi_extract_properties(handle, desc, &dn->data);
> + /*
> + * The scope for the completion of relative pathname segments and
> + * subnode object lookup is the one of the namespace node (device)
> + * containing the object that has returned the package. That is, it's
> + * the scope of that object's parent device.
> + */
> + if (handle)
> + acpi_get_parent(handle, &scope);
>
> - if (handle) {
> - acpi_handle scope;
> - acpi_status status;
> -
> - /*
> - * The scope for the subnode object lookup is the one of the
> - * namespace node (device) containing the object that has
> - * returned the package. That is, it's the scope of that
> - * object's parent.
> - */
> - status = acpi_get_parent(handle, &scope);
> - if (ACPI_SUCCESS(status)
> - && acpi_enumerate_nondev_subnodes(scope, desc, &dn->data,
> - &dn->fwnode))
> - result = true;
> - } else if (acpi_enumerate_nondev_subnodes(NULL, desc, &dn->data,
> - &dn->fwnode)) {
> + result = acpi_extract_properties(scope, desc, &dn->data);
> + if (acpi_enumerate_nondev_subnodes(scope, desc, &dn->data, &dn->fwnode))
> result = true;
> - }
>
> if (result) {
> dn->handle = handle;
>
>
--
Kind regards,
Sakari Ailus
Powered by blists - more mailing lists