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. Clearly, there are race conditions here. Say magic packet wakeup is configured, but we get disconnected by the AP just before suspend. There will not be a way to honour that trigger now, so I would argue that we should fail the suspend in that case. The only other alternative is silently not failing, but then there will be no wakeup trigger at all, and had the disconnect happened earlier network detection might've been configured. If it fails, the userspace suspend agent I was talking about can reconfigure. However, in this case the userspace agent would also have to completely deconfigure wowlan triggers before being able to suspend "normally". Maybe even this distinction has to be under userspace control to allow it to operate in multiple models. 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? As far as the actual API is concerned, I don't really see any big issues with it, since we simply set and retrieve triggers. There will be a need for getting some more information after wakeup, particularly when the device supports GTK rekeying while asleep. The bigger questions I have are around the semantic issues I've outlined. How do we want to treat those? johannes [1] incidentally, this might be supported in the "continue operating" model, by programming filters into the device, which might not be exposed as host runtime APIs. -- 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
