-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
| It's basically that s3cmci asks the stack to remove the driver on | suspend, and to re-insert it on resume. This causes the stack to | try to identify the "new" card. Unfortunately, without a prior | reset, this will fail, because the commands used for this are only | allowed after reset. Yes it's the same of uSD handling with the higher levels controlled by this stack. It sends a command to reset the card to idle during suspend and brings the card up fresh during resume: but this is hidden from the higher levels on the Linux side so it sees an unchanged device. Association is presumably lost because the firmware in the Atheros module is directly seeing this "go down", "come back up from scratch" traffic. | That change will partially obsolete the patch set I just sent in | the sense that the HIF will never be reached on resume, but all | the rest of the power handling is still needed for modules. It's fine for now, It's no worse than normal soft MAC device under Linux where mac80211 is down in suspend and association is lost: NetworkManager or similar will reacquire it on resume. I don't think many users at all (any?) right now rely on WLAN operation live in suspend, IIUI this should at least get us over the common case of WLAN not broken on resume so it's very good to have: thanks. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkknx0kACgkQOjLpvpq7dMr+OQCfd+BJHbq6Md1mnrH3Xct4N/wW 2X4An3OItU+CrFG9k15OhrHNVb1TqWZb =Dk4x -----END PGP SIGNATURE-----
