on radio_enabled

on radio_enabled

[Johannes Berg]

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

Hi!

So I was looking through various drivers, and not all of them are able
to handle radio_enabled gracefully.

iwlwifi, for instance, turns off the radio but then is unable to fulfil
any configuration requests coming in while the radio is disabled.

The same is true, if I remember correctly what Ivo told me, for rt2x00.

It is not true for b43/legacy, for example, which leaves the MAC running
and thus can configure everything even if the radio is disabled.
Similarly for Atheros hw, I think.

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.

Pros:
 * configures all hardware correctly without the driver needing to do
   everything by itself
 * works with all hardware for sure

Cons:
 * higher latency

Also, sometimes we may want to disable the radio for just short periods
of time, I think, for regulatory compliance? 11h or so? How's that
handled, or rather supposed to be?

johannes

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

Re: on radio_enabled

[Gábor Stefanik]

On Thu, Apr 23, 2009 at 12:39 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> Hi!
>
> So I was looking through various drivers, and not all of them are abl=
e
> to handle radio_enabled gracefully.
>
> iwlwifi, for instance, turns off the radio but then is unable to fulf=
il
> any configuration requests coming in while the radio is disabled.
>
> The same is true, if I remember correctly what Ivo told me, for rt2x0=
0.
>
> It is not true for b43/legacy, for example, which leaves the MAC runn=
ing
> and thus can configure everything even if the radio is disabled.
> Similarly for Atheros hw, I think.
>
> 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.
>
> Pros:
> =A0* configures all hardware correctly without the driver needing to =
do
> =A0 everything by itself
> =A0* works with all hardware for sure
>
> Cons:
> =A0* higher latency
>
> Also, sometimes we may want to disable the radio for just short perio=
ds
> of time, I think, for regulatory compliance? 11h or so? How's that
> handled, or rather supposed to be?
>
> johannes
>

In my opinion, the driver should be able to specify whether it can
handle configuration-while-down correctly or not. Drivers that don't
report as being able to do this should be configuration-cycled.

--G=E1bor

--=20
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: on radio_enabled

[Kalle Valo]

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.

> 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).

-- 
Kalle Valo

Re: on radio_enabled

[Johannes Berg]

[-- 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 --]

Re: on radio_enabled

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> writes:

> I wonder where the use case for faster scanning is

Basically the situation where the device is not connected to any AP but
is periodidally trying to find one, for example by scanning every five
minutes. In that case every mW we can save in scanning improves use
times.

> but I guess the slow SPI bus really does make for a long delay in
> initialising due to firmware upload.

Exactly.

> 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.

Yes.

> 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?

In my opinion should be equivalent to rfkill. NB. I haven't properly
thought about this and I know nothing about rfkill, fortunately :)

-- 
Kalle Valo