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 > <[email protected]> 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
