Re: howto ignore rfkill switch

[Dan Williams <dcbw redhat com>]

On Thu, 2010-04-22 at 11:10 -0700, Dana Goyette wrote:
> On 04/22/2010 08:44 AM, Dan Williams wrote:
> > On Wed, 2010-04-21 at 18:49 -0600, Jim Cromie wrote:
> >
> > Yes, for a number of reasons.  First, we can't usually figure out which
> > killswitch is for which wifi device.  It's often just not possible, plus
> > "platform" killswitches provided by your laptop BIOS aren't tied to a
> > specific wifi device.
> >
> > Dan
> 
> On a similar vein, I have issues every time I resume from suspend with 
> my HP laptop.  I have both a platform rfkill and a phy0 rfkill, and 
> soft-blocking the platform rfkill hard-blocks the phy0 rfkill.
> 
> Since NetworkManager refuses to try to unblock ANY rfkill if one is 
> hard-blocked, I end up having to manually "rfkill unblock wifi" at 
> resume.  Is there any way to get NetworkManger to ignore the phy0 rfkill?

Not really; because if the phy is hardblocked, it really is *dead* and
it won't be usable at all until that hardblock is removed (by unblocking
the platform device).

NM doesn't actually *write* to rfkill, it simply reads it.  You'll want
to use the hardware killswitch (or the platform one, whatever you have)
to unblock your wifi when needed.

> The assumption that we can't tell what wifi device the platform rfkill 
> applies to, is not quite true, at least for HP: I think it would be a 
> relatively safe bet that the hp-wifi rfkill applies to whatever wifi 
> card is internal (that is, on a non-hotpluggable PCI or PCIe port).

Ah, but how do you know which cards are actually internal?  It's a bit
easier for PCI devices, but we certainly don't know for USB devices (and
not all USB devices are external, especially bluetooth and WWAN, but
also many wifi devices).

Also realize that the platform driver has a huge impact here.  There can
be bugs in the platform driver (hp-wmi, thinkpad-acpi, acer-wmi,
asus-laptop, fujitsu-laptop, etc) that make rfkill perform badly.  It
might also be the case that the autoload magic isn't present in the
platform driver for your specific laptop model.

I have the same setup on my daily machine (HP 2530p).  iwlagn phy
killswitch, and an hp-wmi platform killswitch which hardblocks the phy
one.

There are some ways we can deal with this, but they are complicated and
hard to get right.  They also include UI changes, because to actually
unblock wifi, you have to do something like this:

1) try to unblock each wifi killswitch
2) after doing this, if any killswitches are still blocked, try to
unblock any blocked switches again
3) and try it again
4) if any switches are still blocked, the operation has failed, and you
somehow alert the user
5) if all switches are unblocked, success

This is because the platform killswitch will often hardblock the phy
killswitch, so we can't use a hardblock state in the UI anywhere.  That
also means that we can't tell whether there's actually a hardblock
anywhere that has to be fixed by sliding a switch, because we can't
trust any phy hardblock (there are some ways around this).

Second, not all phy switches are controlled by platform switches.  And
there's simply no way to tell which platform switches control phy
switches, because that's all internal to BIOS and not exposed to the OS.

There are some things we can do here, but everyone needs to realize that
it's complicated and will take some time to get right.  We don't want to
deploy a solution that breaks 50% of laptop.

Dan