On Sat, Oct 17, 2026 at 11:35:16PM -0400, Myeonghun Pak wrote:
> The managed IRQ handlers are acquired before the managed register
> mapping, so devres unmaps the registers before freeing the IRQs. A
> transfer wakes its waiter before the ISR's final register read, and
> unregistering the adapter does not synchronize these IRQs. An in-flight
> handler can therefore still access the mapping when it is released
> during driver detach.
> 
> With forced-threaded IRQs, the handler can be preempted after waking the
> transfer waiter and before its final ICSR read.
> 
> Map the registers before requesting the IRQs so that managed cleanup
> frees and synchronizes all handlers before unmapping their registers.
> Keep IRQs available while unregistering the adapter because client
> removal may perform transfers.
> 
> This issue was identified as part of our ongoing research while
> reviewing kernel code.
> 
> Fixes: 7fe8a9993337 ("i2c: sh_mobile: devm conversion, irq setup")
> Co-developed-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Myeonghun Pak <mhun512@gmail.com>

I know I am late to the game, but I still want to say that while
changing the order to be "regs then irqs" is in general a good thing, it
won't matter here, as I see it. Unless the later pm_runtime_get_sync()
the device should not(tm) be able to send irqs. Famous last words...

Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>