On Tue, Mar 22, 2011 at 5:13 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > In the second email, I'll gather some thoughts about userspace APIs. > > Regardless of how suspend works, the device may need special > configuration (e.g. wakeup patterns [1], rekeying information or > similar), in our case it even needs special firmware uploaded. Suspend > might also only be possible in certain configurations, like being > associated with exactly one AP, and not while operating as an AP, for > example. > as Ohad noted, we do need to be able to suspend while operating as AP (which is possible as the beaconing is done in the fw), at least with our model. i can also think of use cases in which it will be useful to have a suspended AP also in standard wowlan - like letting the ap go to sleep while there are no clients, and waking it up on a directed probe request. > Back to the unsupported modes though, should those fail suspend as well? > Currently, we simply deconfigure everything during suspend. But once we > have a model of "the connection stays up during suspend", should we > still silently shut down AP mode interfaces and keep the others during > suspend? That seems inconsistent. > > Again, the solution might be a suspend agent that will configure the > system in a way that suspend is possible. But how can it tell that > suspend will be possible? Between the different possible models, there > can be a lot of variety. We can expose those, but what will userspace do > with the information? Do we require that it configures the device in a > way that it can suspend, or do we do that in the drivers? maybe we can add each trigger an additional parameter which describes whether this trigger is optional (when applicable) or mandatory (which will abort the suspend if it can't be configured)? Eliad. -- 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
