Re: [RFC] rfkill: rewrite

Johannes Berg
2009-03-30T17:46:17Z

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

On Mon, 2009-03-30 at 10:39 -0700, Inaky Perez-Gonzalez wrote:
> On Monday 30 March 2009, Johannes Berg wrote:
> >
> > * wimax
> > -> need help, seems to report rfkill states to input device?
> > don't understand
>
> Not really.
>
> What it does is if the device exposes a hw rfkill key, export that
> key as an input device, as well as using it to report the state
> change.
>
> So there are three main entry points:
>
> wimax_report_rfkill_hw() -- device driver report to stack
>
> device reports a change in the hw rfkill key; switch the radio to
> whichever state AND report a key event through the input layer

But reporting the key through the input layer is wrong, afaict.

> wimax_report_rfkill_sw() -- device driver report to stack
>
> device reports a change in the sw rfkill state; this is needed for
> cases where the radio is shared amongst different technologies (wifi
> and wimax, for example, in the case of the 5150). When you turn on
> Wifi, WiMAX switches off (and vice versa).
>
> As well, if from SW you flip it off, this gets called back but does
> nothing as the state is updated already.

Shouldn't that be a hard block then? Or can the software turn it back on
(and consequently turn off wifi)?

> wimax_rfkill / wimax_rfkill_toggle_radio -- user interface
>
> The user wants to flip the SW switch on/off

Right.

So let's go back to my first assertion:
"seems to report rfkill states to input device"

wimax_report_rfkill_hw:

enum rfkill_state rfkill_state;

...
input_report_key(wimax_dev->rfkill_input, KEY_WIMAX,
rfkill_state);

??

I don't see why it should have an input device at all, to be honest.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]