Re: Suspending 802.11 drivers

[Michael Buesch <mb@bu3sch.de>]

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.