On Tue, Jun 10, 2008 at 7:11 AM, Henrique de Moraes Holschuh <hmh@xxxxxxxxxx> 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). Not that I cannot read the code, but what this rkill class actually should do according your vision? Does it implement radio-state state machine....notification hub for rfkill switches ... > > 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. > iwl4965 has actually one more rf kill switch. It switches itself off if it goes over critical temperature. For NIC it looks like temporal rfkill. Tomas > 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
