linux-kernel - Re: [PATCH v1 2/4] ACPI: property: Add code comments explaining what is going on

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJZ5v0gGcyWfgUxj-ayTj0QXaDa9eayWP7ANfumzGqAU61-vAA@mail.gmail.com>
Date: Tue, 16 Sep 2025 13:10:29 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, 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 2/4] ACPI: property: Add code comments explaining what
 is going on

Hi Sakari,

On Mon, Sep 15, 2025 at 10:19 PM Sakari Ailus
<sakari.ailus@...ux.intel.com> wrote:
>
> Hi Rafael,
>
> On Mon, Sep 15, 2025 at 02:27:16PM +0200, Rafael J. Wysocki wrote:
> > Hi Sakari,
> >
> > On Mon, Sep 15, 2025 at 1:32 PM Sakari Ailus
> > <sakari.ailus@...ux.intel.com> wrote:
> > >
> > > Hi Rafael,
> > >
> > > On Fri, Sep 12, 2025 at 09:40:58PM +0200, Rafael J. Wysocki wrote:
> > > > +                     /*
> > > > +                      * The reference is expected to point to an object
> > > > +                      * returning a package that contains _DSD-equivalent
> > > > +                      * information.
> > > > +                      */
> > > >                       handle = link->package.elements[1].reference.handle;
> > > >                       result = acpi_nondev_subnode_data_ok(handle, link, list,
> > > >                                                            parent);
> > > >                       break;
> > > >               case ACPI_TYPE_PACKAGE:
> > >
> > > And similarly, the result of an evaluation here is a package when a
> > > reference points to a name object (i.e. a data node).
> >
> > Well, I'm not sure how this remark is related to the new comment below.
> >
> > Do you mean that this always happens when a reference is used in ASL
> > to point to the target here?
>
> As long as the target is a non-device object (or name or method object at
> least), which is required by DSD-guide for (non-string-)referenced objects.
>
> >
> > But the comment would still be valid in that case, wouldn't it?
>
> After re-reading the first paragraph, I agree.
>
> >
> > > > +                     /*
> > > > +                      * This happens when the target package is embedded
> > > > +                      * within the links package as a result of direct
> > > > +                      * evaluation of an object pointed to by a reference.
> > > > +                      *
> > > > +                      * The target package is expected to contain _DSD-
> > > > +                      * equivalent information, but the scope in which it
> > > > +                      * is located in the original AML is unknown.  Thus
> > > > +                      * it cannot contain pathname segments represented as
> > > > +                      * strings because there is no way to build full
> > > > +                      * pathnames out of them.
>
> Is the "original AML" relevant? Aren't we just interested in how the
> evaluation result was reached instead of what was its actual path?

So long as the node in question is not referred to via a namepath from
a different place (for instance, a reference property in a different
node), we don't.  However, if there is such a reference to it
somewhere, we need to know that this is the target node of that
reference.

> We won't know the latter in any case. What would you think of:
>
>                         /*
>                          * Evaluating a reference results in a package object
>                          * (required by DSD guide) allocated on the fly. The
>                          * actual target object of the reference isn't
>                          * available.
>                          */

The target object actually is available, but the path to it isn't
known at this point.

>
> I guess nothing prevents having further string references within the
> object?

The _DSD guide forbids that and they would only work if they were full
namepaths (because of the unknown scope).

Anyway, I think that the comment is as good as it gets in its current form.

> I think it'd be best to deprecate direct references in the DSD guide.

That I agree with, but the code needs to be retained for compatibility
with the installed base.

> > > > +                      */
> > > >                       desc = &link->package.elements[1];
> > > >                       result = acpi_nondev_subnode_extract(desc, NULL, link,
> > > >                                                            list, parent);
> > > >
> > >
>
> --