public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Linux ACPI <linux-acpi@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Subject: Re: [PATCH v1 2/4] ACPI: property: Add code comments explaining what is going on
Date: Mon, 15 Sep 2025 23:18:57 +0300	[thread overview]
Message-ID: <aMh0sRizzRFTtp6z@kekkonen.localdomain> (raw)
In-Reply-To: <CAJZ5v0ivX3s=pChGZ_+zeUswJgMPDH2Wi_cGeATyh+M9Tb0LYw@mail.gmail.com>

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@linux.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? 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.
			 */

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

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

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

-- 
Kind regards,

Sakari Ailus

  parent reply	other threads:[~2025-09-15 20:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-12 19:37 [PATCH v1 0/4] ACPI: property: Two fixes, more documentation and a cleanup Rafael J. Wysocki
2025-09-12 19:39 ` [PATCH v1 1/4] ACPI: property: Fix buffer properties extraction for subnodes Rafael J. Wysocki
2025-09-15 11:04   ` Sakari Ailus
2025-09-15 12:09     ` Rafael J. Wysocki
2025-09-12 19:40 ` [PATCH v1 2/4] ACPI: property: Add code comments explaining what is going on Rafael J. Wysocki
2025-09-15 11:32   ` Sakari Ailus
2025-09-15 12:27     ` Rafael J. Wysocki
2025-09-15 17:12       ` Rafael J. Wysocki
2025-09-15 17:51         ` Sakari Ailus
2025-09-15 18:05           ` Rafael J. Wysocki
2025-09-15 20:23             ` Sakari Ailus
2025-09-15 20:18       ` Sakari Ailus [this message]
2025-09-16 11:10         ` Rafael J. Wysocki
2025-09-12 19:42 ` [PATCH v1 3/4] ACPI: property: Do not pass NULL handles to acpi_attach_data() Rafael J. Wysocki
2025-09-15 11:49   ` Sakari Ailus
2025-09-15 12:57     ` Rafael J. Wysocki
2025-09-15 20:43       ` Sakari Ailus
2025-09-12 19:43 ` [PATCH v1 4/4] ACPI: property: Adjust failure handling in acpi_nondev_subnode_extract() Rafael J. Wysocki

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=aMh0sRizzRFTtp6z@kekkonen.localdomain \
    --to=sakari.ailus@linux.intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rafael@kernel.org \
    /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