Re: [PATCH 01/12] rfkill: clarify meaning of rfkill states

[Dan Williams <dcbw@redhat.com>]

On Tue, 2008-06-10 at 01:11 -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 08 Jun 2008, Matthew Garrett wrote:
> > On Fri, Jun 06, 2008 at 11:14:19AM -0300, Henrique de Moraes Holschuh wrote:
> > > 1. Every transmitter shall have ONE, and just ONE (not zero, not two,
> > > not more) rfkill class attached.  For those transmitters lacking support
> > > in hardware to make it block, the drivers shall quiesce them and avoid
> > > doing anything to cause transmissions, or even use bus tricks to power
> > > the device down (i.e. the driver will emulate a switch capable of doing
> > > the blocking).
> > 
> > How do we enforce this? iwl4965 provides an rfkill device, but hp-wmi 
> > will also provide one for the wifi. If I swap out the wireless card for 
> > something else, I may lose the card-specific rfkill device.
> 
> Let's define some very STRICT terminology to avoid confusion.
> 
> rfkill class:  the sysfs rfkill class, related to struct rfkill.
> 
> rfkill class attached [to a Linux struct device]: a device whose
>   struct device was given to rfkill_allocate() as the parent.
> 
> transmitter:  part of a wireless device.  So far, every wireless device
> I have seen has only one transmitter from the kernel PoV.  A device
> with two transmitters would be able to transmit two different information
> streams at the same time, with different parameters (such as frequency,
> power).
> 
> transmitter != switch, so hp-wmi, thinkpad-acpi, and anything else that is
> not an actual wireless hardware device IS NOT INCLUDED in that "one and just
> one" constraint.  In fact, thinkpad-acpi has two rfkill classes attached to
> its main platform device, one for the bluetooth softswitch, and another for
> the wwan softswitch.
> 
> So, "Every transmitter shall have ONE and just ONE rfkill class attached."
> just means that you call rfkill_allocate with that device as the parent just
> ONCE per transmitter (and everything I have seen so far has just one
> transmitter).
> 
> Which also means that, for wireless drivers (which have transmitters), you
> need to synthesize the "device rfkill state" to give to that rfkill class.
> THE TRANSMITTER MIGHT BE UNDER THE EFFECT OF MORE THAN ONE RFKILL LINE.
> 
> And if the device [transmitter] has NO rfkill capabilities by itself, we
> emulate the minimum of one in software [per transmitter].   If the device
> has one input pin for rfkill, that one is also taken into account when
> generating the state for the ONLY ONE rfkill class attached to that device
> [per transmitter], etc.
> 
> Now, firmware switches are different, and something for another email that
> I haven't typed in yet (busy in real life right now).
> 
> An example:
> 
> ipw4965 probably has two rfkill controls in itself (an input pin for a
> hardkill line, and an R/W IO register to help its driver (ilw4965) implement
> a rfkill softswitch).  Those TWO rfkill inputs are to be combined into just
> ONE rfkill class which will be attached to the Linux device provided by
> ilw4965.  This is the end of the story from the PoC of the ilw4965 module.
> 
> hp-wmi probably has one softswitch it controls, that ends up connected to
> that input pin in the ipw4965 card so you end up being able to use a hp-wmi
> softswitch to hardkill the ipw4965 card.  This IS expected, and it will not
> matter or break anything.  In the current rfkill incarnation, rfkill doesn't
> understand or know or want to know about rfkill switch topology as it
> stands.
> 
> Did I manage to get the idea across, this time?  Remember, I am not
> describing the rfkill class interactions for switches in that email, JUST
> for wireless drivers, which hp-wmi, thinkpad-acpi, etc are not...
> 
> What happens on the hp-wmi side when the ipw4965 card is removed, is to be
> explained in the other email about switches, but it is not much.  Basically,
> hp-wmi has to be written in such a way that it won't matter for the user,
> and THERE is the real reason why one must never confuse the softswitch
> control with input devices.  Remember that as long as rfkill-input is
> loaded, if anything sends a "change all WLAN rfkill switches" input event,
> all WLAN rfkill switches WILL be changed, regardless of whether they are
> wired among themselves, or completely independent.

As you've explained it, I believe this will work IFF we take your
suggestion and add a 3rd state RADIO_SW_BLOCKED to go along with
RADIO_HW_BLOCKED and RADIO_UNBLOCKED.

In this system, if NM wants to softblock a wifi device for example, it
would likely just turn off the transmitter with 'SIOCSIWTXPOW', thus the
wifi device itself would report it's rfkill state as RADIO_SW_BLOCKED.
NM would then be aware that it could be re-enabled at any time through
software.

If the user then hits the hardkill switch, the wifi device would report
RADIO_HW_BLOCKED, and NM would be aware that the user must unkill the
transmitter with a physical switch.

It gets a bit interesting when unrelated killswitches like hp-wmi and
thinkpad-acpi are used, because if those just softkill the radio, you
could end up in the situation where the radio itself is RADIO_UNBLOCKED
but the struct rfkill created by hp-wmi is RADIO_SW_BLOCKED if BIOS
doesn't track the actual state of the radio too.  How do we fix that?

Dan