Re: wpi0: radio is disabled by hardware switch

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Tue, Dec 02, 2014 at 03:36:51PM -0500, Greg Troxel wrote:
> 
> Manuel Bouyer <bouyer%antioche.eu.org@localhost> writes:
> 
> > 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.
> 
> 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

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--