Hi Daniel, Thanks for your elaborative comments. We can go with your patch which fixes the issue in a cleaner way. I ran some tests and verified remove path with it. >Unless there is a reason to do otherwise, the norm here would be to >tightly couple the hardware bits that enable interrupts to the Linux >IRQ handler registration. i.e. sdio_claim_irq should be called >immediately before mwifiex_sdio_enable_host_int, and sdio_release_irq >should be called immediately after mwifiex_sdio_disable_host_int. >Right now these 2 steps are very separate (sdio_release_irq is being >called far too late, long after the point when the driver could sanely >handle an interrupt). Now if_ops.disable_int call is a bit closer to sdio_release_irq (in if_ops.unregister). >Although you would never expect an interrupt to arrive after >mwifiex_sdio_disable_host_int() has been called, the cleanliness and >readability has value here, and maybe damaged hardware would misbehave >and fire an interrupt anyway, which would cause the driver to go >wrong. mwifiex_main_process() which may go into an infinite loop is not called in this case now. >Secondly, it should be symmetrical. If the core mwifiex driver is the >thing that enables interrupts, it should be the component responsible >for disabling them as well. With your patch, the core mwifiex driver >enables interrupts, but it is up to the sdio sub-driver to disable >them. if_ops.disable_int call takes care of it. Regards, Amitkumar Karwar -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
