Re: rfkill rewrite

[Johannes Berg <johannes@sipsolutions.net>]

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

Hi,

Sorry for the long wait.

> > I could make the rfkill core do that at resume, but I'm not really sure
> > it's what we want -- there are too many cases imho:
> >  * hard rfkill might have changed
> >  * soft rfkill might still be ok in hw
> >  * soft rfkill might need reconfiguring
> > etc. I think generally it's saner to let the driver sort it out -- it
> > can always ask for the current state by using set_hw_state() or so.
> 
> 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. But
yes. However, how would the core handle it?

> You need this to handle hibernation.  If the rfkill state persists
> across hibernation (which mine does, even in S5), you can always cause
> the state to change, by pressing the wireless toggle key _while the
> hibernation image is being written to disk_.  At that stage, all
> devices are active, so that s2disk can interact with the user and
> write the image wherever it chooses.  The kernel will not "remember"
> the state change on resume, since it happened after the kernel image
> was snapshotted.

Good scenario, yes, it's definitely possible.

> If the rfkill state does _not_ persist over hibernation, then clearly
> the state can change on resume and you will again need a resume
> handler,
> 
> On my EeePC, this is just more dramatic because it can de-power a PCI
> device without notifying the driver.  But the new rfkill design will
> require all devices to have a resume method, because there is no
> get_state() callback.  Otherwise, reading  of
> /sys/class/rfkill/rfkill*/state after resume from hibernation may
> return an incorrect result.  I don't think we should allow that to
> happen.

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.

johannes

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