Re: [PATCH v1 01/17] ACPI: bus: Introduce devm_acpi_install_notify_handler()

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Tue, Jun 02, 2026 at 10:57:23PM +0200, Rafael J. Wysocki wrote:
> On Tue, Jun 2, 2026 at 8:50 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Thu, May 21, 2026 at 03:59:50PM +0200, Rafael J. Wysocki wrote:

...

> > > +     acpi_dev_remove_notify_handler(ACPI_COMPANION(dev), dr->handler_type,
> >
> > acpi_dev might be also part of the same data structure, so you won't need to
> > take dev again and derive adev from it.
> 
> I'm not sure what you mean.
> 
> Put acpi_dev into struct acpi_notify_handler_devres?

Yes.

> > > +                                    dr->handler);

...

> > > + * devm_acpi_install_notify_handler - Install an ACPI notify handler for a

> > > + *                                 managed device
> >
> > There is a stray space just after asterisk.
> 
> Which asterisk?

The line above has "<space>*<space>(sic!)<tab><tab> ... managed device".
The <space> after the asterisk is a stray one.

...

> > > +             return dev_err_probe(dev, -ENODEV, "No ACPI companion in %s()\n", __func__);
> >
> > Not sure how __func__ may help here. We will have a device instance to be
> > printed. It's obvious then how to find the culprit call.
> 
> But it doesn't hurt either, does it?

From my p.o.v. it's just extra information that's not needed. But I'm not going
fight to death against it.

...

> So thanks for the review, but I don't think I want to send a v2 at this point.
> 
> I'd rather send a follow-up patch to clean up these things.

Okay!

-- 
With Best Regards,
Andy Shevchenko