Re: Suspending 802.11 drivers

2006-06-22 Thread Luis R. Rodriguez
On 6/21/06, Stefan Rompf <[EMAIL PROTECTED]> 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 supplic

Re: Suspending 802.11 drivers

2006-06-21 Thread Luis R. Rodriguez
On 6/21/06, Michael Buesch <[EMAIL PROTECTED]> wrote: On Wednesday 21 June 2006 17:08, Luis R. Rodriguez wrote: > On 6/16/06, Stefan Rompf <[EMAIL PROTECTED]> wrote: > > Am Donnerstag 15 Juni 2006 21:58 schrieb Michael Buesch: > > > > I think the most important question is how a suspend/resume ac

Re: Suspending 802.11 drivers

2006-06-21 Thread 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

Re: Suspending 802.11 drivers

2006-06-21 Thread Michael Buesch
On Wednesday 21 June 2006 17:08, Luis R. Rodriguez wrote: > On 6/16/06, Stefan Rompf <[EMAIL PROTECTED]> 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

Re: Suspending 802.11 drivers

2006-06-21 Thread Luis R. Rodriguez
On 6/16/06, Stefan Rompf <[EMAIL PROTECTED]> 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/of

Re: Suspending 802.11 drivers

2006-06-21 Thread 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 - T

Re: Suspending 802.11 drivers

2006-06-16 Thread 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 su

Re: Suspending 802.11 drivers

2006-06-15 Thread 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

Re: Suspending 802.11 drivers

2006-06-15 Thread Ivo van Doorn
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

Suspending 802.11 drivers

2006-06-15 Thread 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 doin