wpi0: radio is disabled by hardware switch

[Manuel Bouyer]

Hello,
on a laptop with a wpi interface, dcpcd brings automatically the interface
up, which leads to an endless stream of "wpi0: radio is disabled by hardware
switch" on console when the radio is turned off.

Is there a way to get status and notifications (other than watching dmesg)
of the radio hardware switch, in order to e.g. enable or disable
wpa_supplicant and dhcpcd on the interface when the switch is used to turn
the radio on or off ?

[Ignatios Souvatzis]

Hi,

Post by Manuel Bouyer
Is there a way to get status and notifications (other than watching dmesg)
of the radio hardware switch, in order to e.g. enable or disable
wpa_supplicant and dhcpcd on the interface when the switch is used to turn
the radio on or off ?

On Thinkpads (at least T61) you can check for ubt, which is switched off
by the same switch, to the point of vanishing off the USB. I can send you
the exact script I'm using tonight.

-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

There is a pmf event for it, maybe the wpi driver should handle it
similar to athn:

http://nxr.netbsd.org/xref/src/sys/dev/ic/athn.c#184

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Martin Husemann
There is a pmf event for it, maybe the wpi driver should handle it
http://nxr.netbsd.org/xref/src/sys/dev/ic/athn.c#184

it seems that this cause athn to go down when it gets a radio off event,
but it doesn't seem to generate itself such and event. Or did I miss
something ?

[Martin Husemann]

Post by Manuel Bouyer
it seems that this cause athn to go down when it gets a radio off event,
but it doesn't seem to generate itself such and event. Or did I miss
something ?

Yes, and that shuts up dhcpcd.

The event is generated elsewhere, e.g. here:
http://nxr.netbsd.org/xref/src/sys/dev/ic/arn5008.c#1258

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Martin Husemann

Post by Manuel Bouyer
it seems that this cause athn to go down when it gets a radio off event,
but it doesn't seem to generate itself such and event. Or did I miss
something ?

Yes, and that shuts up dhcpcd.

I can't see where dhcpcd looks at the event. I guess it shuts up because the
interface goes down.

Post by Martin Husemann
http://nxr.netbsd.org/xref/src/sys/dev/ic/arn5008.c#1258

thanks, will have a look.

[Martin Husemann]

Post by Manuel Bouyer
I can't see where dhcpcd looks at the event. I guess it shuts up because the
interface goes down.

Exactly.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Manuel Bouyer

Post by Martin Husemann

Post by Manuel Bouyer
it seems that this cause athn to go down when it gets a radio off event,
but it doesn't seem to generate itself such and event. Or did I miss
something ?

Yes, and that shuts up dhcpcd.

I can't see where dhcpcd looks at the event. I guess it shuts up because the
interface goes down.

Correct.

dhcpcd only cares about the interface status (up/down/unknown) as
reported by kernel events.

Should turning the radio on trigger an interface up event?
My iwi(4) doesn't do this sadly, and there doesn't seem to be any way to
hook into it either which is annoying.

Roy


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Roy Marples
Should turning the radio on trigger an interface up event?
My iwi(4) doesn't do this sadly, and there doesn't seem to be any way to
hook into it either which is annoying.

I couldn't figure out how to recognize that event with athn either, sadly.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

the wpi driver also turns off IFF_UP when the radio switch is off,
exept in one case. The attached patch fixes it.
The stream of console message was generated by wpa_supplicant, which
is automatically started by dhcpcd. wpa_supplicant tries to bring the
interface up once per second. Stopping it stops the messages too.
There's no way to get the radio button events up to userland, execpt with
ad-hoc mechanisms (wpi(4) provides a hw.wpi0.radio sysctl, but a userland
script has to pool it to get radio button events).
It looks like this should be hooked up to powerd(4), which already has
notifications for various switches.
I can look at this, with an implementation for wpi(4), unless someone
objects to the concept.

iwi(4) provides hw.iwi0.radio sysctl as well, not that it works when I
toggle the switch.

Roy


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Roy Marples

the wpi driver also turns off IFF_UP when the radio switch is off,
exept in one case. The attached patch fixes it.
The stream of console message was generated by wpa_supplicant, which
is automatically started by dhcpcd. wpa_supplicant tries to bring the
interface up once per second. Stopping it stops the messages too.
There's no way to get the radio button events up to userland, execpt with
ad-hoc mechanisms (wpi(4) provides a hw.wpi0.radio sysctl, but a userland
script has to pool it to get radio button events).
It looks like this should be hooked up to powerd(4), which already has
notifications for various switches.
I can look at this, with an implementation for wpi(4), unless someone
objects to the concept.

iwi(4) provides hw.iwi0.radio sysctl as well, not that it works when I
toggle the switch.

For wpi it does, I did check

[Manuel Bouyer]

Some update on this topic:
the wpi driver also turns off IFF_UP when the radio switch is off,
exept in one case. The attached patch fixes it.
The stream of console message was generated by wpa_supplicant, which
is automatically started by dhcpcd. wpa_supplicant tries to bring the
interface up once per second. Stopping it stops the messages too.

There's no way to get the radio button events up to userland, execpt with
ad-hoc mechanisms (wpi(4) provides a hw.wpi0.radio sysctl, but a userland
script has to pool it to get radio button events).
It looks like this should be hooked up to powerd(4), which already has
notifications for various switches.

I can look at this, with an implementation for wpi(4), unless someone
objects to the concept.

[Greg Troxel]

the wpi driver also turns off IFF_UP when the radio switch is off,
exept in one case. The attached patch fixes it.
The stream of console message was generated by wpa_supplicant, which
is automatically started by dhcpcd. wpa_supplicant tries to bring the
interface up once per second. Stopping it stops the messages too.
There's no way to get the radio button events up to userland, execpt with
ad-hoc mechanisms (wpi(4) provides a hw.wpi0.radio sysctl, but a userland
script has to pool it to get radio button events).
It looks like this should be hooked up to powerd(4), which already has
notifications for various switches.
I can look at this, with an implementation for wpi(4), unless someone
objects to the concept.

I don't object, but I'm a little unclear on the conceptual model.

Is the user pushing the button supposed to be like unplugging a USB
interface or removing a PCI device from the bus? Or is it supposed to
be like unplugging a cable?

The use of IFF_UP feels abusive; historically that's an internal flag
that the drive users to signify (to itself) that initialization has been
done.

It seems to me that when the user pushes the button, the interface
should disappear, as if it were a USB interface that was disconnected.
Then there's no need for either IFF_UP hackery or special handling. If
that's what you mean, sounds good.

[Martin Husemann]

There's no way to get the radio button events up to userland

The pmf_inject_event() is the right way to do this.

It looks like this should be hooked up to powerd(4), which already has
notifications for various switches.

And this is the userland part for it.

I agree that handling IFF_UP in the driver is hackish, but back then was
the simplest solution. Leaving this part to a powerd script is fine.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Martin Husemann

There's no way to get the radio button events up to userland

The pmf_inject_event() is the right way to do this.

It looks like this should be hooked up to powerd(4), which already has
notifications for various switches.

And this is the userland part for it.
I agree that handling IFF_UP in the driver is hackish, but back then was
the simplest solution. Leaving this part to a powerd script is fine.

Now I'm confused; does powerd gets notifications from pmf_inject_event() ?
I though it gets only envsys(4) events.

Can you point me to the code which gets pmf(4) events in userland ?
All references I can find are in kernel.

[Martin Husemann]

Post by Manuel Bouyer
Now I'm confused; does powerd gets notifications from pmf_inject_event() ?
I though it gets only envsys(4) events.

I thought pmf would (or could) forward them to envsys, but it is the
other way around: sysmon forwards some events to pmf:

sysmon_power.c: pmf_event_inject(NULL, PMFE_CHASSIS_LID_CLOSE);

We could do the same for the new event you are considering and replace
the current pmf_event_inject() calls with the new equivalent (I guess there
are only two or so of them).

But somehow this all sounds messy and could use a clearer design; something
like all in-kernel events are converted to pmf_event_inject() and sysmon
listens for them and forwards the relevant ones to powerd.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Martin Husemann

Post by Manuel Bouyer
Now I'm confused; does powerd gets notifications from pmf_inject_event() ?
I though it gets only envsys(4) events.

I thought pmf would (or could) forward them to envsys, but it is the
sysmon_power.c: pmf_event_inject(NULL, PMFE_CHASSIS_LID_CLOSE);
We could do the same for the new event you are considering and replace
the current pmf_event_inject() calls with the new equivalent (I guess there
are only two or so of them).
But somehow this all sounds messy and could use a clearer design; something
like all in-kernel events are converted to pmf_event_inject() and sysmon
listens for them and forwards the relevant ones to powerd.

As I understand it, pmf_event_inject() is for communications between
kernel components; and the way athn uses PMFE_RADIO_OFF is for communication
between the driver core and a frontend (the event is not broadcasted to all
listeners). For the wpi this would be different because the button status
in read in the driver core itself.

I'm not sure it would be a good idea to mix the two.

[Martin Husemann]

Post by Manuel Bouyer
As I understand it, pmf_event_inject() is for communications between
kernel components

Sometimes messages make sense to both kernel and userland (some
only if there is no powerd listening). Having a single event injection
interface would be great.

The hack in athn is just there since no easy other solution was available
at that time: the hardware powers off some parts of the chip when the toggle
is pressed, independently of what the driver does. If the driver ignores
the change, it will run into lots of timeouts accesing the chip later.

If we defer the final decision via powerd/userland and an event script, the
driver will need to grow an internal "I am actually off" flag, but that is ok.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Martin Husemann

Post by Manuel Bouyer
As I understand it, pmf_event_inject() is for communications between
kernel components

Sometimes messages make sense to both kernel and userland (some
only if there is no powerd listening). Having a single event injection
interface would be great.
The hack in athn is just there since no easy other solution was available
at that time: the hardware powers off some parts of the chip when the toggle
is pressed, independently of what the driver does. If the driver ignores
the change, it will run into lots of timeouts accesing the chip later.
If we defer the final decision via powerd/userland and an event script, the
driver will need to grow an internal "I am actually off" flag, but that is ok.

I'm not sure that the final descision to power off needs to be defered.
In the case of athn, the various frontends can pass a pmf events to the
MI Backend, and the MI backend send the envsys event.

I want to report radio button events to userland not to power off the
interface, but to configure it when the button is turned on

[Manuel Bouyer]

Post by Greg Troxel

the wpi driver also turns off IFF_UP when the radio switch is off,
exept in one case. The attached patch fixes it.
The stream of console message was generated by wpa_supplicant, which
is automatically started by dhcpcd. wpa_supplicant tries to bring the
interface up once per second. Stopping it stops the messages too.
There's no way to get the radio button events up to userland, execpt with
ad-hoc mechanisms (wpi(4) provides a hw.wpi0.radio sysctl, but a userland
script has to pool it to get radio button events).
It looks like this should be hooked up to powerd(4), which already has
notifications for various switches.
I can look at this, with an implementation for wpi(4), unless someone
objects to the concept.

I don't object, but I'm a little unclear on the conceptual model.
Is the user pushing the button supposed to be like unplugging a USB
interface or removing a PCI device from the bus? Or is it supposed to
be like unplugging a cable?
The use of IFF_UP feels abusive; historically that's an internal flag
that the drive users to signify (to itself) that initialization has been
done.
It seems to me that when the user pushes the button, the interface
should disappear, as if it were a USB interface that was disconnected.
Then there's no need for either IFF_UP hackery or special handling. If
that's what you mean, sounds good.

No, I'm not planning to make the interface dissapear, although it could be
a way to do it. What I had in mind is powerd(4) getting a new event
type, RADIO_EVENT_SWITCH_STATE_CHANGE

[Greg Troxel]

Post by Manuel Bouyer
No, I'm not planning to make the interface dissapear, although it could be
a way to do it. What I had in mind is powerd(4) getting a new event
type, RADIO_EVENT_SWITCH_STATE_CHANGE

So the interface will still be there, and presumably can be ifconfig'd
up or down, and will never actually radiate, and never show anything
other than "no carrier", but programs shouldn't try to use it?

So it seems like you are providing a hook so that people can write
scripts that start and stop things when the button is pushed. I wonder
if there should be some larger enable/disable concept for interfaces
that essentially does the button in software for interfaces that don't
have this feature. Sort of like turning wifi off on a mac.

[Manuel Bouyer]

Post by Greg Troxel

Post by Manuel Bouyer
No, I'm not planning to make the interface dissapear, although it could be
a way to do it. What I had in mind is powerd(4) getting a new event
type, RADIO_EVENT_SWITCH_STATE_CHANGE

So the interface will still be there, and presumably can be ifconfig'd
up or down, and will never actually radiate, and never show anything
other than "no carrier", but programs shouldn't try to use it?

No, it can't be ifconfig'd up. The driver doesn't allow it
in the wpi case (I haven't looked at other drivers).

Note that I don't know if the button really does prevent the wifi
from working. It could just be a button connected to a gpio pin, and
everything is handled in software (again for wpi I guess it really
turns the radio off, because button status is reported by the adapter's
firmware. For e.g. athn it may just be a gpio pin).

Post by Greg Troxel
So it seems like you are providing a hook so that people can write
scripts that start and stop things when the button is pushed.

Yes