Hi Daniel, > > Normally TX is blocked until resume handler is called and host sleep handshake between driver and > firmware is done. > > Where is the code that makes such synchronization happen? If a data packet is received unexpectedly during suspended, driver blocks it and displays a message "not allowed while suspended". Earlier you mentioned that doing netif attach/detach in suspend/resume would work around this problem. It reminders me that previously we set carrier off in suspend so that kernel won't send data packets to driver. That carrier-off code was removed in recent commit 1499d9f to fix a missing ping response issue right after resume. Perhaps it's worth a revisit to this change. > > > Does the TX happen before "hs_deactivated" event? > > hard_start_xmit is called approximately 1ms after hs_deactivated arrives. When hs_deactivated event arrives, 'is_suspended' flag must have been cleared already. The tx packets should be allowed to send freely. I don't know why the message "not allowed while suspended" is fired in this case. There could be a race condition somewhere though. Could you please send a complete dynamic_debug enabled log showing all the sequence? > > > I'm thinking of releasing IRQ in driver suspend handler and re-claim the IRQ in resume. Of course > it needs some changes in sdio_release_irq to skip SDIO_CCCR_IENx disabling, otherwise host may not be > woken up by SDIO DAT1. > > > > Attached is the sample code, not tested. > > That patch breaks wake-on-LAN, the suspended system simply doesn't > respond to incoming packets. Could you confirm that you saw this message on suspend? "SDIO: KEEP IRQ ON for ..." Thanks, Bing > > Daniel -- 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
