On Wed, 2009-05-13 at 16:08 -0700, Luis R. Rodriguez wrote: > > That's a good point. Somehow I thought this was intimately tied to > > suspend. And I think for cfg80211 that makes sense, since cfg80211 > > doesn't do much for suspend. But for mac80211 you're right in that it > > would make sense to > > * keep the radio on > > This is implicit by not calling stop, right? Yeah, I think so. > > * not call stop > > This makes sense for ath9k so far -- I was just exiting out. Ok. > > * maybe not remove all the sta info structs > > Which ones? In my tests I'm just not removing any. I'm talking about sta_notify() not code :) > > * and whatever else may be necessary -- that might even depend on the > > wow mode > > So lets start with a basic goal -- magic packet. If you think about it > though if you disassociate you won't get this magic packet Actually I think you still can or something, it's very strange. Does anyone have a WoW documentation/spec? > so I guess > that's also why we have link-change trigger (or called disassoc > trigger on some other hardware?). That could make some sense, though do you want to wake up, reassociate (if possible) and go to sleep again? That would take some synchronisation across layers... > Anyway out of these link change and > magic packet seem like a reasonable goal to get working first. For > that besides the above I'm not sure what else is required. > > I'm building this stuff now on a box with a card that is supposed to > have WoW working so I'll know for sure if we are missing something > soon. Cool. Anyway I think Bob is right, we may not need to have anything added to ->stop() and instead do some wow config, or something. Too tired to think about it I think. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
