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