In this third email, some thoughts about the internal APIs.
For the model 2) that I described, I think the current APIs as
implemented in this patchset are not effective. Remember that in this
model, there's no change to how the chip operates, it just continues
operating as before, while the host is suspended, and has no extra
wakeup conditions, just the regular interrupt.
Things are more complex in the more traditional model, mostly depending
on how we answer the questions I posed in my second email.
However, ultimately I think we should move away from the start/stop
model we've imposed right now. The model makes sense for the case where
the device is shut down, but I think it doesn't make sense at all for
the case where the device stays up, in whatever form.
Just looking at patch 4/9 in Eliad's series that I'm replying to, I
think that it's clear that there's no sense in trying to keep the
mac80211 logic for the wowlan suspend case.
I think what we should do instead is this:
1) Add suspend/resume ops instead of going through stop/start and all
the deconfiguration / reconfiguration (of course keep all the
previous logic for drivers that don't implement suspend.)
2) Implement more iterators / accessors to allow drivers to get access
to more information. Some of that might not be necessary since at
resume in some cases the device might just go and request a restart,
but in other cases this might be necessary to simplify/avoid book-
keeping in drivers.
Adding such APIs would allow drivers to be more in control of what
happens at suspend, which given the complexity of how this might work,
with configuring the driver etc.
Thoughts?
johannes
--
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
