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