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? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
