Re: rfkill rewrite

[Johannes Berg <johannes@sipsolutions.net>]

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

> >> I just realized or remembered something non-obvious.  This means _all_
> >> rfkill drivers need a resume handler.  They don't at the moment, so
> >> this would need to be fixed and documented.  In which case, it's
> >> probably simpler for the core to do it.
> >
> > Only those that have a hard-rfkill line, which I think isn't all.
> 
> My scenario quoted below affects soft-rfkill only.

Ah, you're thinking of that.

> > But yes. However, how would the core handle it?
> 
> I was thinking of calling set_block() on resume to restore the
> pre-suspend state.  That's what the old rfkill does, and why
> eeepc-laptop got away without a resume handler.

That makes sense.

> > So we would need to add a query_resume() method like query that is
> > called at resume time, and needs to call rfkill_set{,_hw,_sw}_state as
> > appopriate. Thoughts? We can enforce that much easier by making it a
> > required method.
> 
> That would certainly follow your existing model.  (BTW the kerneldoc
> for "query" is out of sync in v8; it says "return true for blocked"
> even though the prototype returns void :-).

Yeah, I noticed already and fixed it yesterday but didn't post v9 yet
(will also amend v9 with the outcome of this discussion)

> It's debatable as to what behaviour is more user-friendly for my nasty
> corner-case.  query_resume() would allow the radio to always come back
> in the same state as it was in the moment the laptop went to sleep, if
> the hardware supports it.  But the _global_ rfkill state will then be
> out of sync, and that means the next time you press the wireless
> toggle key it does nothing, which is disconcerting.  Plus, it means
> the corner-case behaviour varies depending on whether the soft-rfkill
> line state survives over hibernation - which may even vary on the same
> machine (S5 versus S4? whether you remove the laptop's battery? weird
> firmware bugs?).
> 
> All I'm trying to do is selfishly preserve eeepc-laptop across this
> re-write, for which purpose it seems easier to have set_block() called
> on resume :-).  I don't know if that makes rfkill more awkward in
> wireless drivers (as opposed to platform drivers), or drivers which
> have a hardware rfkill line.

No, should be fine. I can add that and remove the resume code from
eeepc.

johannes

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