Re: [PATCH v1 06/17] ACPI: HED: Switch over to devres-based resource management

[Rafael J. Wysocki]

On Wed, Jun 3, 2026 at 12:10 AM Andy Shevchenko
<andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
>
> On Thu, May 21, 2026 at 04:04:03PM +0200, Rafael J. Wysocki wrote:
>
> > Use the newly introduced devm_acpi_install_notify_handler() for
> > installing an ACPI notify handler and since that function checks the
> > ACPI companion of the owner device against NULL internally, remove the
> > the explicit ACPI companion check from acpi_hed_probe().
> >
> > No intentional functional impact.
>
> ...
>
> >  static void acpi_hed_remove(struct platform_device *pdev)
> >  {
> > -     struct acpi_device *device = ACPI_COMPANION(&pdev->dev);
> > -
> >       hed_present = false;
> > -     acpi_dev_remove_notify_handler(device, ACPI_DEVICE_NOTIFY,
> > -                                    acpi_hed_notify);
> >  }
>
> devm will be cleaned after this, right?

Yes.

> So, here is a window that if one tries
> to unbind device from the driver in one thread and do the opposite in another
> they will see the flag false while resources are still allocated for the old
> one. It seems that hed_present should be also devm:ed?

If this is the same device, both binding and unbinding (including
devm) take place under its device lock which will serialize all of
that.

If they are different devices with different ACPI companions, there's
no resource conflict.  If they are both valid HEDs (which would be a
stretch already) and they both trigger a notification exactly at the
"wrong" time (more stretch), worst-case stuff will be called twice in
a row via blocking_notifier_call_chain().