On Fri, 2009-04-24 at 09:24 +0300, Kalle Valo wrote: > Johannes Berg <johannes@xxxxxxxxxxxxxxxx> 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:
signature.asc
Description: This is a digitally signed message part
