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. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
