Hi Daniel, >I don't see any external reason why we are not allowed to communicate to >the hardware here. The other suspend paths do run some communication. The reason is mwifiex_sdio_remove() gets called even if user removes an externally connected wifi card. In that case the hardware is not present so there is no point in reading/writing hardware registers. If mwifiex_sdio_remove() is called when card is not powered off or unplugged, we do take care of hardware de-initialization using user_rmmod flag. Interrupt storm issue doesn't exist there. >However, disabling interrupts at this point does seem like a bad >solution to me, and something that would come back and bite us in the >future. mwifiex_sdio_suspend() is not directly related to the cause of >the problem. This approach looks correct to me. While returning failure in suspend handler, 'pm_flag & MMC_PM_KEEP_POWER' is false. Card is going to be powered off soon. There won't be any further communication with card, so disabling interrupts at this point of time is logical. When system is resumed, bus rescan etc. will happen and card will be redetected. Can you please try this change? Thanks and 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
