On Tue, 25 Aug 2026, Rafael J. Wysocki (Intel) wrote: > On Tue, Aug 25, 2026 at 2:07 PM Sakari Ailus > 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 > > > 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.