Re: on radio_enabled

[Johannes Berg <johannes@sipsolutions.net>]

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

On Fri, 2009-04-24 at 09:24 +0300, Kalle Valo wrote:
> Johannes Berg <johannes@sipsolutions.net> writes:
> 
> > Now, if we're going to use radio_enabled more, I wonder whether we
> > should completely deconfigure the hardware when we want to turn off
> > radio_enabled, and then completely reconfigure it once we enable the
> > radio again.
> 
> I assume that you mean op_stop() and op_start() here.

Yes. And all the associated things, see the suspend/resume code.

> > Pros:
> >  * configures all hardware correctly without the driver needing to do
> >    everything by itself
> >  * works with all hardware for sure
> >
> > Cons:
> >  * higher latency
> 
> From stlc45xx and wl12xx perspective I would like to have low latency as
> possible for the radio on/off case. This is what I had in mind:
> 
> interface down:
> 
> o chip is powered off while down
> o ifup uploads firmware and initialises it
> o ifup might take hundreds of milliseconds, at least with 1271
> 
> radio off:
> 
> o chip is powered on
> o firmware possibly sleeping/hibernating
> o radios turned off
> o very low latency (<5 ms) to wakeup
> o small power consuption during radio off
> 
> This way it would be possible to have a bit faster scans when not
> associated (with radio off), but still have a possibility to completely
> turn of chip from user space for a longer periods of time (with
> interface down).

I wonder where the use case for faster scanning is, but I guess the slow
SPI bus really does make for a long delay in initialising due to
firmware upload. I have no trouble with implementing it this way, and
userspace can still set the interfaces down when it wishes to do that,
while we can save a lot of power when userspace doesn't do it that way.


Now, what happens with "iwconfig wlan0 txpower off"? I can't figure out
that one. Should it be completely equivalent to rfkill, regardless of
what rfkill ends up doing?

Thanks,
johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]