On Thu, Nov 3, 2016 at 12:27 PM, Brian Norris <briannorris@xxxxxxxxxxxx> wrote: > On Thu, Nov 03, 2016 at 09:15:04AM -0700, Dmitry Torokhov wrote: >> On Thu, Nov 03, 2016 at 08:34:06AM +0000, Xinming Hu wrote: >> > > -----Original Message----- >> > > From: linux-wireless-owner@xxxxxxxxxxxxxxx >> > > [mailto:linux-wireless-owner@xxxxxxxxxxxxxxx] On Behalf Of Dmitry Torokhov >> > > >> > > Instead please remove call to mwifiex_shutdown_drv() in the main routine >> > > and "if (adapter->mwifiex_processing)" check here. >> > > >> > >> > mwifiex_main_process will be used from interrupt or workqueue. >> > Now we have disabled interrupt and flush workqueue, so >> > mwifiex_main_process won't be scheduled in the future. >> > But mwifiex_main_process might just running in context of last >> > interrupt, so we need wait current main_process complete in >> > mwifiex_shutdown_drv. >> >> synchronize_irq() is your friend then. > > Hmm, that sounds right, but IIUC, the "interrupt context" is actually > only used for SDIO, and for SDIO, the driver doesn't actually have > access to the IRQ number. The MMC/SDIO layer has some extra abstraction > around the IRQ. So this may be more difficult than it appears. > > Do we need a sdio_synchronize_irq() API? Actually the ->disable_irq() method should be responsible for making sure it does not complete while interrupt handler is running. As far as I can see, for SDIO case, we end up calling sdio_card_irq_put() which stops kernel thread and won't return while the thread is running. For other interfaces we need to check. IIRC USB lacks ->disable_irq() altogether and this is something that shoudl be fixed (by doing usb_kill_urb() at the minimum). Thanks. -- Dmitry
