I did, and just replied to it.
But only now do I think I realised what you meant: That even if the driver
tries to keep set txpower off separate from rfkill, if it uses the hardware
soft-rfkill bit to implement both, it cannot use that to feed information to
rfkill_force_state() directly.
Argh.
Well, there is no intended change in interpretation, but I don't know how to
word it in a way that means "the real current hardware state as far as
rfkill is concerned".
Because suppose it is a driver doing txpower off AND software rfkill using
the *same* hardware bit (a sigle software rfkill bit).
Now it must do something like this in pseudo-code:
1. if (the bit is disabled (i.e. SW rfkill is NOT ACTIVE)) {
rfkill-SW-status = disabled;
} else if (the bit is enabled (i.e. SW rfkill is ACTIVE)) {
if (tx power off is NOT ACTIVE)
rfkill-SW-status = enabled;
else
rfkill-SW-status = whatever the user asked
}
THEN, it should use rfkill-sw-status, along with the hw rfkill line status,
to synthesize the state it must pass to rfkill_force_status().
ICK. Of course, if the driver has another way to implement txpower off that
does not clash with sw rfkill, the above is unneeded.
How would you put that into words for the rfkill documentation?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
