On Mon, 2009-03-30 at 18:02 -0300, Henrique de Moraes Holschuh wrote: > > > It is probably a good idea to have the rfkill core sanitize the > > > attempt to set the default state, and force it to "block" if EPO is > > > active (I don't recall if I checked for this failure mode in the old > > > code). > > > > No, but it rejects any calls to set the default state when any rfkill > > struct has been registered already. So this isn't a concern. > > Suppose something entirely different (an input device) issued SW_RFKILL_ALL, > and EPO is in effect. It happened right at boot because the user turned the > laptop on with the rfkill switch active, and that driver loaded first. > > Now another driver is loading, and is registering the first rfkill struct of > type foo (say, for an USB 'foo' dongle that has no idea whatsoever of any > platform rfkill switches), and that USB 'foo' dongle is a really well-made > device that even has NVRAM with lots of state pertaining to 'foo', including > a bit used to keep persistent on/off state. > > It will try to set the default state for type 'foo' (which might well be > unblock) while EPO is active. This attempt to set the default for 'foo' to > ubblock can succeed or not (whatever is easier on the rfkill core code), but > either way it must _not_ cause any switches to be unblocked, and that > includes any subsequent rfkill_register (because EPO _is_ active)... Interesting scenario -- I'll have to think about that, but you're probably right and it needs some stuff to check for epo when setting default. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
