Re: [PATCH] mmc: sdio: Set acpi_device.power.flags.ignore_parent flag on sdio_func companion

["Luka Gejak" <luka.gejak@linux.dev>]

Hi Hans,

October 17, 2026 at 6:04 PM, "Hans de Goede" <johannes.goede@oss.qualcomm.com> wrote:

> 
> Many MMC host drivers call pm_suspend_ignore_children() which allows
> to keep MMC cards and SDIO-functions on while the host is suspended.
> 
> For SDIO functions which are in the ACPI power-domain this causes a race
> where the host may end up runtime-suspended before the driver for a SDIO
> function loads and probes it. When the probe() looses this race this causes
> the pm_runtime_get_sync() in sdio_bus_probe() to fail in the ACPI pm-domain
> code with e.g. the following error:
> 
>  ACPI: \_SB_.SDHB.WLAN: Cannot transition to D0 for parent in D3hot
> 
> Busses using pm_suspend_ignore_children() for their children should set
> acpi_device.power.flags.ignore_parent on the ACPI companion device of
> their children to avoid this.
> 
> This is safe todo because drivers for sdio_func devices should always
> call sdio_claim_host() before doing any IO and that runtime-resumes
> the host.
> 
> Add the missing setting of the acpi_device.power.flags.ignore_parent flag
> to fix probing of SDIO functions sometimes failing on ACPI systems with
> the error mentioned above.
> 
> Also add a sdio_acpi_clear_handle() function to undo this, since the ACPI
> companion device wills stay around after removing the sdio_func device. To
> make sdio_acpi_clear_handle() the proper inverse of sdio_acpi_set_handle()
> also make it actually clear the companion pointer on the sdio_func device.
> Technically this clearing is not really necessary since the sdio_func
> device will go away shortly afterwards anyways.
> 
> Closes: https://github.com/MocLG/rtw/issues/2/
> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
> ---
[...]
+
> +static void sdio_acpi_clear_handle(struct sdio_func *func)
> +{
> +     struct acpi_device *adev;
> +
> +     adev = ACPI_COMPANION(&func->dev);
> +     if (adev) {
> +             adev->power.flags.ignore_parent = false;
> +             ACPI_COMPANION_SET(&func->dev, NULL);
> +     }
>  }
>  #else
>  static inline void sdio_acpi_set_handle(struct sdio_func *func) {}
> +static inline void sdio_acpi_clear_handle(struct sdio_func *func) {}
>  #endif
>
>  static void sdio_set_of_node(struct sdio_func *func)
[...]
> @@ -414,6 +432,8 @@ int sdio_add_func(struct sdio_func *func)
>   */
>  void sdio_remove_func(struct sdio_func *func)
>  {
> +     sdio_acpi_clear_handle(func);
> +
>       if (sdio_func_present(func))
>               device_del(&func->dev);
>

I am not an expert on this topic, but clearing the companion here
before device_del(), looks wrong to me. As far as I understand
device_add() binds this device with acpi_bind_one() and that takes
a reference on both the companion and the device. The unbinding is
done in device_del() via acpi_device_notify_remove(), which returns
early when the companion is NULL, so does acpi_unbind_one()
never run and the physical_node entry, the sysfs links and the
references from acpi_bind_one() all stay behind and does that also
mean that sdio_release_func() never runs, causing the sdio_func and
its card reference to leak on every removal?

Also it seems to me that the stale entry stays first in the physical
node list, so the next card init would fail
acpi_device_is_first_physical_node() and would gets no ACPI PM domain
at all. Therefore the flag set here would then do nothing.

Would it be enough to only clear ignore_parent in sdio_acpi_clear_handle()
and let device_del() clear the companion?

Take this review with a grain of salt as I am not an expert on this
topic as I previously said.

Best regards,
Luka Gejak