Re: [PATCH v2 3/5] ACPI: Support __free() from cleanup.h for ACPI objects

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]

On Tue, 25 Aug 2026, Rafael J. Wysocki (Intel) wrote:

> On Tue, Aug 25, 2026 at 2:07 PM Sakari Ailus
> <sakari.ailus@linux.intel.com> wrote:
> >
> > Hi Rafael,
> >
> > On Tue, Aug 25, 2026 at 01:51:18PM +0200, Rafael J. Wysocki (Intel) wrote:
> > > On Mon, Aug 24, 2026 at 11:13 PM Sakari Ailus
> > > <sakari.ailus@linux.intel.com> wrote:
> > > >
> > > > Use DEFINE_FREE() to allow ACPI objects to be released automatically.
> > >
> > > But at least some of them are allocated by ACPICA functions like
> > > acpi_evaluate_object() and so they have no proper constructors.
> >
> > You could still assign the return buffer to a local variable. It's not
> > ideal API-wise though.
> 
> Exactly.
> 
> > I'm not quite sure what was the point you wanted to make but I reckon this
> > wasn't an ack. :-)
> 
> Using the _FREE with variables that are not initialized through a
> constructor is questionable, so this is generally not particularly
> clean.

The driver does call ACPI_FREE() for that pointer so clearly it's already 
using something ending with "_FREE" already. So unless Rafael is 
suggesting ACPI_FREE() should be renamed, I'm a bit lost what that 
even means on concrete terms.

> There is no cleanup.h in ACPICA that is a more traditional C code
> base, so mixing up ACPICA code, which ACPI_FREE() is strictly
> speaking, with cleanup.h stuff is not particularly straightforward
> IMV.  I'd rather not do it.

Perhaps add the DEFINE_FREE() into int3472 driver then, it seems to be 
what intel/pmc is already doing (I don't seem to anymore recall why it was 
added there). Using cleanup.h for that variable it clearly simplifies the 
code flow. It feels a bit stupid to duplicate it there but I guess we'll 
just have to live with that if there's no place in any acpi related 
headers for cleanup.h.

-- 
 i.