Re: [RFC] b43: rework rfkill code

Dan Williams
2008-12-10T19:00:14Z

On Wed, 2008-12-10 at 19:33 +0100, Johannes Berg wrote:
> On Wed, 2008-12-10 at 13:29 -0500, Dan Williams wrote:
>
> > > Does the wireless driver get the notification about this from the
> > > hardware, like it would if this was a real physical switch? Then it's
> > > probably pretty simple: provide a rfkill struct from the driver that
> > > updates hard-kill and provide a second rfkill struct for the platform
> > > device that doesn't get hard-killed, but also provide a soft-kill input
> > > form the platform device. That way, you can toggle that button, but you
> > > can also software-enable the platform rfkill device and that in turn
> > > re-enables the wifi-rfkill "hw" switch device.
> >
> > This sort of sucks for userspace, because we see the actual wifi card as
> > hardblocked, but some other random button as softblocked. There's no
> > indication that changing the softblock one will affect the hardblocked
> > one. What are userspace processes supposed to do here, assume that if a
> > non-radio-associated softblocked switch exists, that it can re-enable a
> > hardblocked radio of some random wifi card?
>
> The other question is whether we actually care? So what if the hardware
> can only be enabled with the button, why does that matter?

I guess it doesn't, as long as in Matthew's case, the actual radio
rfkill state is only ever softblocked, because it actually *can* be
re-enabled with the platform button or something.

Dan