On Wednesday 10 December 2008 19:29:50 Dan Williams wrote: > On Wed, 2008-12-10 at 19:05 +0100, Johannes Berg wrote: > > On Wed, 2008-12-10 at 17:51 +0000, Matthew Garrett wrote: > > > > > They may not be physical buttons, but we can often control this anyway. > > > For instance, my HP has a button that will perform a hardware disable of > > > the wifi card. However, I can control that button's state through > > > software with the hp-wmi driver. > > > > That's indeed a complication I wasn't aware of. > > > > > The way we currently handle that (and, > > > I think, the only way we *can* handle that) is to provide two separate > > > rfkill interfaces - one tied to the wireless device, one tied to the > > > platform device. > > > > Yes, but how do we currently do this? > > > > 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?
I don't see the problem. If userspace wants to enable wifi, it should simply _try_ to do so: Userspace sees hw-block and sw-block state: - Unblock the sw state - Re-fetch hw-block and sw-block state - If either one is blocked, we can't enable the radio. - Notify user. -- Greetings, Michael. _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
