[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5f7a4e3f-0f60-46bb-8448-6750803fdd8e@intel.com>
Date: Thu, 16 Oct 2025 09:51:35 +0300
From: Adrian Hunter <adrian.hunter@...el.com>
To: Michael Wu <michael@...winnertech.com>, <ulf.hansson@...aro.org>,
<linus.walleij@...aro.org>, <brgl@...ev.pl>, <avri.altman@....com>,
<wsa+renesas@...g-engineering.com>, <victor.shih@...esyslogic.com.tw>,
<andy-ld.lu@...iatek.com>
CC: <jason.lai@...esyslogic.com.tw>, <linux-mmc@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-gpio@...r.kernel.org>
Subject: Re: [RESEND] mmc: core: Fix system shutdown hang in mmc_bus_shutdown
On 16/10/2025 09:38, Michael Wu wrote:
> Hello,
>
> The execution timing of this `host->detect` work actually depends on when the WiFi driver executes its unload procedure.
Devices should not really be removed during shutdown. The
requirement for shutdown is to ensure there are no on-going
operations and to prepare the hardware for power-off.
So this sounds like the WiFi driver should not be executing
an unload procedure at shutdown.
> This is something we cannot control and cannot handle using `reboot_notifier_list` and `register_reboot_notifier()` operations. Moreover, different WiFi drivers may have different handling sequences for this timing.
>
> From this perspective, we believe it's not convenient to address the issue in that way.
>
> We noticed that the `mmc_bus_shutdown` function calling `cancel_delayed_work_sync` was newly added. Therefore, we suggest removing this part first.
>
> On 10/15/2025 3:09 PM, Adrian Hunter wrote:
>> reboot_notifier_list and
>> register_reboot_notifier()
>
Powered by blists - more mailing lists