Re: [RFC] rfkill: rewrite

Johannes Berg
2009-03-30T21:20:57Z

[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]