On Wed, 2008-12-10 at 19:33 +0100, Johannes Berg wrote: > On Wed, 2008-12-10 at 13:29 -0500, Dan Williams wrote: > > > > 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? > > The other question is whether we actually care? So what if the hardware > can only be enabled with the button, why does that matter? I guess it doesn't, as long as in Matthew's case, the actual radio rfkill state is only ever softblocked, because it actually *can* be re-enabled with the platform button or something. Dan -- 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
