mmc: Synchronization of in-band SDIO IRQ

mmc: Synchronization of in-band SDIO IRQ

[Nemanov, Michael]

Hi,

I'm working on a WLAN driver that will use SDIO transport and will 
support both GPIO and SDIO IRQ sources (only 1 source will be selected 
at runtime).
During driver cleanup there is a need to synchronize the IRQ handler and 
guarantee it is no longer running. For GPIO IRQs is trivial via 
synchronize_irq(). For SDIO IRQs I see no similar option and thinking 
about possible solution.

Is calling flush_work(host->sdio_irq_work) a reasonable approach here? 
This can be done either directly from my driver or added as an API in 
mmc/host.h.

Another solution might be registering with MMC core a minimal handler 
that only triggers a driver-local work item which can be easily flushed 
by the driver. Though in that case handling IRQs that are already 
"in-flight" is a bit more tricky.

Any guidance is much appreciated.

Thanks you and best regards,
Michael.

Re: mmc: Synchronization of in-band SDIO IRQ

[Ulf Hansson]

On Tue, 20 May 2025 at 18:54, Nemanov, Michael <michael.nemanov@ti.com> wrote:
>
> Hi,
>
> I'm working on a WLAN driver that will use SDIO transport and will
> support both GPIO and SDIO IRQ sources (only 1 source will be selected
> at runtime).
> During driver cleanup there is a need to synchronize the IRQ handler and
> guarantee it is no longer running. For GPIO IRQs is trivial via
> synchronize_irq(). For SDIO IRQs I see no similar option and thinking
> about possible solution.

At SDIO func driver (WLAN driver) cleanup?

>
> Is calling flush_work(host->sdio_irq_work) a reasonable approach here?
> This can be done either directly from my driver or added as an API in
> mmc/host.h.
>
> Another solution might be registering with MMC core a minimal handler
> that only triggers a driver-local work item which can be easily flushed
> by the driver. Though in that case handling IRQs that are already
> "in-flight" is a bit more tricky.
>
> Any guidance is much appreciated.

I think the best option to move forward is just to propose something
(including a complete solution, not just a change to the mmc core)
that seems reasonable to you. Post it to linux-mmc, then we will get
the discussion going more easily.

>
> Thanks you and best regards,
> Michael.

Kind regards
Uffe