From nobody Thu Oct 2 14:13:39 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 86D6128033C; Mon, 15 Sep 2025 18:30:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757961025; cv=none; b=NGymBDYDXSIGQvhK3hsks+AOY0+3KXeLXaSsihggUJznn/TD5Ie0k2l5kuAja5HnPRBAK90u1pM6cUX1z8mr2czzocKfRCURT3AgGXCoJpfLeUuL0l9RtlLj3S//JEa7C+83DaTD5yS7vsT+Dj+vl+1dVrxKJoFl0Q+LVSH1lCU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757961025; c=relaxed/simple; bh=y+J9yIOdBWychfvrYQpWWRtMiBBLRZp6apu6S5jI3YE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=doAyZsOnNur3rep4AaD4f7JOpPMOKLRylVY7nz/TJ2F8Dly8lrfENOQFcJvsnk5FeHrpGhFteYdw0RIPDCBxV+pJApFdO6Ra7u+z7Kx/KWYb61kzls8eGMjocLYHg5rkuA5EtZxLamk5XAmceSauFMBuGoRDhe/Nqc1ldEH13y4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Rxh4jE7y; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Rxh4jE7y" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0582BC4CEFA; Mon, 15 Sep 2025 18:30:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1757961025; bh=y+J9yIOdBWychfvrYQpWWRtMiBBLRZp6apu6S5jI3YE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Rxh4jE7ybHNuusMqkkI9/Ow085aiB64jGd0daMmqsMyouYxg8QgWzz+zbHmvwBECy DvuTuroanREvRZ68b9CWLgyidAcofvIgEPFL32Appmvvc9iQl73gmFgSDs737u3yU1 PY5oJ42Rj1XJ7yukK61iZYf9XEQLrS5e1/vgxk7AuSl8jsGgg22wG4HY3qy6fYCW9T K7sj5hUMhXLiVOB0yJgaMQR15XFPsGcre4neVn9EyECtupWwr0l0uWDHPlFtLf/a1u UcXdze7cZIOKJNFcnbF2z7REYkQ9U+CT6SScAOTS2+y4s6jsANthb1lJReryHZdWGA 6EEiKNonlD1ag== From: "Rafael J. Wysocki" To: Linux ACPI Cc: LKML , Mika Westerberg , Andy Shevchenko , Sakari Ailus Subject: [PATCH v2 1/5] ACPI: property: Fix buffer properties extraction for subnodes Date: Mon, 15 Sep 2025 20:21:33 +0200 Message-ID: <5011694.GXAFRqVoOG@rafael.j.wysocki> Organization: Linux Kernel Development In-Reply-To: <5922318.DvuYhMxLoT@rafael.j.wysocki> References: <5922318.DvuYhMxLoT@rafael.j.wysocki> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Rafael J. Wysocki 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 proper= ty UUID") Cc: 6.0+ # 6.0+ Signed-off-by: Rafael J. Wysocki --- v1 -> v2: No changes --- 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 =3D NULL; bool result; =20 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); =20 - result =3D 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); =20 - 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 =3D acpi_get_parent(handle, &scope); - if (ACPI_SUCCESS(status) - && acpi_enumerate_nondev_subnodes(scope, desc, &dn->data, - &dn->fwnode)) - result =3D true; - } else if (acpi_enumerate_nondev_subnodes(NULL, desc, &dn->data, - &dn->fwnode)) { + result =3D acpi_extract_properties(scope, desc, &dn->data); + if (acpi_enumerate_nondev_subnodes(scope, desc, &dn->data, &dn->fwnode)) result =3D true; - } =20 if (result) { dn->handle =3D handle;