Suspending 802.11 drivers

Suspending 802.11 drivers

[Michael Buesch]

Hi,

I am currently thinking about the best way to correctly
implement PM suspending for wireless drivers.
Currently, the 802.11 stack is not suspend aware (if I talk
about "stack" here, I mostly mean devicescape).
For example, if we suspend the bcm43xx driver, we don't
notify the stack before doing so. That's a bug.

I would say, we should have two functions, which are called
from the driver suspend and resume callbacks.
Let's call them
ieee80211_suspend() and ieee80211_resume() for now.
The suspend would save all status information, for example
to which AP we are associated and so on. After that it would
cleanly disassociate from the AP and do other cleanups which
are needed.
The resume function would try to re-esablish the connection.
Of course, that will not always be possible (the notebook
owner traveled around half the world between suspend and
resume ;) ). But that does not matter. We simply return silently
without a new association (Do a new scan, or whatever).

Are such functions generally desireable?

-- 
Greetings Michael.

Re: Suspending 802.11 drivers

[Ivo van Doorn]

[-- Attachment #1: Type: text/plain, Size: 1379 bytes --]

Hi,

> I am currently thinking about the best way to correctly
> implement PM suspending for wireless drivers.
> Currently, the 802.11 stack is not suspend aware (if I talk
> about "stack" here, I mostly mean devicescape).
> For example, if we suspend the bcm43xx driver, we don't
> notify the stack before doing so. That's a bug.

Similar in rt2x00. The basic approach in there is calling
netdev->open() and netdev->stop() which is not the most clean
or correct thing to do.

> I would say, we should have two functions, which are called
> from the driver suspend and resume callbacks.
> Let's call them
> ieee80211_suspend() and ieee80211_resume() for now.
> The suspend would save all status information, for example
> to which AP we are associated and so on. After that it would
> cleanly disassociate from the AP and do other cleanups which
> are needed.
> The resume function would try to re-esablish the connection.
> Of course, that will not always be possible (the notebook
> owner traveled around half the world between suspend and
> resume ;) ). But that does not matter. We simply return silently
> without a new association (Do a new scan, or whatever).
> 
> Are such functions generally desireable?

Absolutely, I have been looking into this some time ago as well,
but due to lack of time haven't managed to get anything done.

Ivo

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Suspending 802.11 drivers

[Michael Buesch]

On Thursday 15 June 2006 22:12, Florian Fainelli wrote:
> Hello Michael,
> 
> I think these are really interesting functions. Currently I scripted a bit to 
> do module unloading/loading on suspend/resume requests plus supplicant 
> context saving and restart.
> 
> Of course, if the driver is able to manage this by itself, it's far better.

Well, if the _suspend() and _resume() semantics are actually implemented
in kernel or userspace is another question. I would say, it should be possible
to defer it to userspace, after the userspace MLME stuff is done.
But that does not really matter here to get my point. My point is:
ieee80211 subsystem should provide functions which save/restore the
whole state of the stack (Well, the state of running connections and
associations ,actually). How these functions are implemented internally
is another matter.
But I would also say that it sounds sane to put these semantics into
userspace, in the long term.

> Any news on the power management specifications ?

No. I think I will start another attempt to measure the power consumption
of the card, soon. Maybe this time I will be able to figure out the
meaning of the PS bits :) I think I forgot to set important bits
last time I checked.

-- 
Greetings Michael.

Re: Suspending 802.11 drivers

[Stefan Rompf]

Am Donnerstag 15 Juni 2006 21:58 schrieb Michael Buesch:

> I am currently thinking about the best way to correctly
> implement PM suspending for wireless drivers.
> Currently, the 802.11 stack is not suspend aware (if I talk
> about "stack" here, I mostly mean devicescape).
> For example, if we suspend the bcm43xx driver, we don't
> notify the stack before doing so. That's a bug.

I think the most important question is how a suspend/resume action should be 
translated. For the managed case, it is clearly an association loss, normally 
signalled by netif_carrier_on/off() and a corresponding SIOCGIWAP event. 
Supplicants can act on this. In AP mode, suspend is equal to disassociating 
all stations. Ad-hoc... dunno.

For a softmac stack like devicescape, it makes sense to have a function that 
abstracts these scenarios as it is the stack anyway that handles association 
stuff. However, I'd rather extend the existing function 
ieee80211_netif_oper().

> The suspend would save all status information, for example
> to which AP we are associated and so on. After that it would
> cleanly disassociate from the AP and do other cleanups which
> are needed.

It would *try* to cleanly disassociate. No way waiting for the management 
packet to reach the air or even for the AP's acknowledgement while half of 
userspace is already frozen and the user wants the machine to go down ASAP. 
(But that's an interesting point. Will sniff whether ipw2200 hardware sends a 
final packet on suspend.)

> The resume function would try to re-esablish the connection.

Don't keep too much state - just notify userspace of the disassociation, then 
scan and reassociate using the given iwconfig parameters or the running 
supplicant as it would happen on a normal association loss. ipw2200 acts like 
this, and it is definitely fast enough.

Stefan

Re: Suspending 802.11 drivers

[Stefan Rompf]

Am Freitag 16 Juni 2006 20:36 schrieb Stefan Rompf:

> (But that's an interesting point. Will sniff whether ipw2200 hardware sends
> a final packet on suspend.)

neither on suspend to RAM nor on suspend to disk a disassociation is sent by 
ipw2200 - for the AP, the client just vanishes.

Stefan

Re: Suspending 802.11 drivers

[Luis R. Rodriguez]

On 6/16/06, Stefan Rompf <stefan@loplof.de> wrote:
> Am Donnerstag 15 Juni 2006 21:58 schrieb Michael Buesch:
>
> I think the most important question is how a suspend/resume action should be
> translated. For the managed case, it is clearly an association loss, normally
> signalled by netif_carrier_on/off() and a corresponding SIOCGIWAP event.
> Supplicants can act on this. In AP mode, suspend is equal to disassociating
> all stations. Ad-hoc... dunno.
>
> For a softmac stack like devicescape, it makes sense to have a function that
> abstracts these scenarios as it is the stack anyway that handles association
> stuff. However, I'd rather extend the existing function
> ieee80211_netif_oper().

Since d80211 is already being patched for sysfs how about we use sysfs
(and kobjects) to maintain the state at suspend() and resume(). This
would allow userspace tools like supplicant running in the background
to pick up from sysfs where it left off and for our drivers to save
where we left off. ieee80211_hw can then just refer to their suspend()
and resume() routines from its respective struct pci_driver or struct
usb_device.

  Luis

Re: Suspending 802.11 drivers

[Michael Buesch]

On Wednesday 21 June 2006 17:08, Luis R. Rodriguez wrote:
> On 6/16/06, Stefan Rompf <stefan@loplof.de> wrote:
> > Am Donnerstag 15 Juni 2006 21:58 schrieb Michael Buesch:
> >
> > I think the most important question is how a suspend/resume action should be
> > translated. For the managed case, it is clearly an association loss, normally
> > signalled by netif_carrier_on/off() and a corresponding SIOCGIWAP event.
> > Supplicants can act on this. In AP mode, suspend is equal to disassociating
> > all stations. Ad-hoc... dunno.
> >
> > For a softmac stack like devicescape, it makes sense to have a function that
> > abstracts these scenarios as it is the stack anyway that handles association
> > stuff. However, I'd rather extend the existing function
> > ieee80211_netif_oper().
> 
> Since d80211 is already being patched for sysfs how about we use sysfs
> (and kobjects) to maintain the state at suspend() and resume(). This
> would allow userspace tools like supplicant running in the background
> to pick up from sysfs where it left off and for our drivers to save
> where we left off. ieee80211_hw can then just refer to their suspend()
> and resume() routines from its respective struct pci_driver or struct
> usb_device.

Ok, so you mean we remove the full responsibility to recover a connection
from the driver resume() handler and let a userspace daemon keep
track of this?
So basically stay with the current implementation of suspend() and
resume() in the drivers and assume userspace does the right thing
and detects a resume and recovers connections and so on?
Did I understand that right? If yes, I think that's a very nice idea, too.
Probably the best.

-- 
Greetings Michael.

Re: Suspending 802.11 drivers

[Luis R. Rodriguez]

On 6/21/06, Michael Buesch <mb@bu3sch.de> wrote:
> On Wednesday 21 June 2006 17:08, Luis R. Rodriguez wrote:
> > On 6/16/06, Stefan Rompf <stefan@loplof.de> wrote:
> > > Am Donnerstag 15 Juni 2006 21:58 schrieb Michael Buesch:
> > >
> > > I think the most important question is how a suspend/resume action should be
> > > translated. For the managed case, it is clearly an association loss, normally
> > > signalled by netif_carrier_on/off() and a corresponding SIOCGIWAP event.
> > > Supplicants can act on this. In AP mode, suspend is equal to disassociating
> > > all stations. Ad-hoc... dunno.
> > >
> > > For a softmac stack like devicescape, it makes sense to have a function that
> > > abstracts these scenarios as it is the stack anyway that handles association
> > > stuff. However, I'd rather extend the existing function
> > > ieee80211_netif_oper().
> >
> > Since d80211 is already being patched for sysfs how about we use sysfs
> > (and kobjects) to maintain the state at suspend() and resume(). This
> > would allow userspace tools like supplicant running in the background
> > to pick up from sysfs where it left off and for our drivers to save
> > where we left off. ieee80211_hw can then just refer to their suspend()
> > and resume() routines from its respective struct pci_driver or struct
> > usb_device.
>
> Ok, so you mean we remove the full responsibility to recover a connection
> from the driver resume() handler and let a userspace daemon keep
> track of this?
> So basically stay with the current implementation of suspend() and
> resume() in the drivers and assume userspace does the right thing
> and detects a resume and recovers connections and so on?
> Did I understand that right? If yes, I think that's a very nice idea, too.
> Probably the best.

Michael, yes that was what I meant.

Re: Suspending 802.11 drivers

[Stefan Rompf]

Am Mittwoch 21 Juni 2006 17:08 schrieb Luis R. Rodriguez:

> Since d80211 is already being patched for sysfs how about we use sysfs
> (and kobjects) to maintain the state at suspend() and resume(). This
> would allow userspace tools like supplicant running in the background
> to pick up from sysfs where it left off and for our drivers to save
> where we left off.

Forgive me that I'm so insistant on this question, but this is important: What 
state that goes beyond the data settable with wireless ioctls/iwconfig (that 
is kept anyway) needs to be saved by the stack? Last association info is 
worthless, the assocation can be restored using the ESSID/BSSID/channel set 
with iwconfig or by wpa_supplicant. Important is that userspace is notified 
about the connection loss. Is there _any_ other information not recreatable 
from iwconfig settings that needs to be kept?

Stefan

Re: Suspending 802.11 drivers

[Luis R. Rodriguez]

On 6/21/06, Stefan Rompf <stefan@loplof.de> wrote:
> Am Mittwoch 21 Juni 2006 17:08 schrieb Luis R. Rodriguez:
>
> > Since d80211 is already being patched for sysfs how about we use sysfs
> > (and kobjects) to maintain the state at suspend() and resume(). This
> > would allow userspace tools like supplicant running in the background
> > to pick up from sysfs where it left off and for our drivers to save
> > where we left off.
>
> Forgive me that I'm so insistant on this question, but this is important: What
> state that goes beyond the data settable with wireless ioctls/iwconfig (that
> is kept anyway) needs to be saved by the stack? Last association info is
> worthless, the assocation can be restored using the ESSID/BSSID/channel set
> with iwconfig or by wpa_supplicant. Important is that userspace is notified
> about the connection loss. Is there _any_ other information not recreatable
> from iwconfig settings that needs to be kept?
>
> Stefan

Stefan, this is an excellent and valid question. Let me elaborate --
Its exactly those settings you mention I'm suggesting get saved onto
sysfs by the driver and later get picked up by userspace. There are,
however, other settings which could get saved when suspending too
though, settings for example, which otherwise would get set by current
private wireless ioctls. There are too many here to describe really,
each device has their own set of of private attributes.

More on this in another e-mail I'm about to send to netdev.

  Luis