[ath9k-devel] About rfkill racing issue.

[ath9k-devel] About rfkill racing issue.

[Matt Chen]

Hi list,
It is found by notebook that rfkill doesn't work very right. I don't
know where to post this discussion, so I choose here to start the
talk.
Basically we found the input handler in net/rfkill/input.c , because
the nature of stateless key events, it can only toggle the saved
state.  This screws up when started as blocked at
boot, as already suspected.
Now we thought Synchronizing to the
hard block state looks as if working, but it's also dangerous because
the operation is racy. The hard block check on ath9k driver is done
in a poll basis, for example. Thus, the polling might happen just
before the key event is handled, and it might happen after the key
event.
Another option would be to get synchronize the soft block state at the
driver initialization time.  But, this doesn't work always because we
never know whether ther rfkill key event is generated.  The rfkill key
event depends on BIOS. Thus, if we set the soft block as same as the
hard block at the init time (and set as blocked), the soft block will
be never unblocked if some BIOS version doesn't emit a key event.

So we would like to discuss with the all experts here for this issue.
Do you have a good idea to fix the rfkill for the issue ?

Thanks for all your advice. :)

-- 
Thank you.

About rfkill racing issue.

[Matt Chen]

Hi list,
It is found by notebook that rfkill doesn't work very right. I don't
know where to post this discussion, so I choose here to start the
talk.
Basically we found the input handler in net/rfkill/input.c , because
the nature of stateless key events, it can only toggle the saved
state.  This screws up when started as blocked at
boot, as already suspected.
Now we thought Synchronizing to the
hard block state looks as if working, but it's also dangerous because
the operation is racy. The hard block check on ath9k driver is done
in a poll basis, for example. Thus, the polling might happen just
before the key event is handled, and it might happen after the key
event.
Another option would be to get synchronize the soft block state at the
driver initialization time.  But, this doesn't work always because we
never know whether ther rfkill key event is generated.  The rfkill key
event depends on BIOS. Thus, if we set the soft block as same as the
hard block at the init time (and set as blocked), the soft block will
be never unblocked if some BIOS version doesn't emit a key event.

So we would like to discuss with the all experts here for this issue.
Do you have a good idea to fix the rfkill for the issue ?

Thanks for all your advice. :)

-- 
Thank you.

[ath9k-devel] About rfkill racing issue.

[Johannes Berg]

On 4/11/2012 11:15 PM, Matt Chen wrote:
> Hi list,
> It is found by notebook that rfkill doesn't work very right. I don't
> know where to post this discussion, so I choose here to start the
> talk.
> Basically we found the input handler in net/rfkill/input.c , because
> the nature of stateless key events, it can only toggle the saved
> state.  This screws up when started as blocked at
> boot, as already suspected.
> Now we thought Synchronizing to the
> hard block state looks as if working, but it's also dangerous because
> the operation is racy. The hard block check on ath9k driver is done
> in a poll basis, for example. Thus, the polling might happen just
> before the key event is handled, and it might happen after the key
> event.
> Another option would be to get synchronize the soft block state at the
> driver initialization time.  But, this doesn't work always because we
> never know whether ther rfkill key event is generated.  The rfkill key
> event depends on BIOS. Thus, if we set the soft block as same as the
> hard block at the init time (and set as blocked), the soft block will
> be never unblocked if some BIOS version doesn't emit a key event.
>
> So we would like to discuss with the all experts here for this issue.
> Do you have a good idea to fix the rfkill for the issue ?

How is hard rfkill related to input handling? It shouldn't be.

I don't understand what you're saying I think.

johannes

Re: About rfkill racing issue.

[Johannes Berg]

On 4/11/2012 11:15 PM, Matt Chen wrote:
> Hi list,
> It is found by notebook that rfkill doesn't work very right. I don't
> know where to post this discussion, so I choose here to start the
> talk.
> Basically we found the input handler in net/rfkill/input.c , because
> the nature of stateless key events, it can only toggle the saved
> state.  This screws up when started as blocked at
> boot, as already suspected.
> Now we thought Synchronizing to the
> hard block state looks as if working, but it's also dangerous because
> the operation is racy. The hard block check on ath9k driver is done
> in a poll basis, for example. Thus, the polling might happen just
> before the key event is handled, and it might happen after the key
> event.
> Another option would be to get synchronize the soft block state at the
> driver initialization time.  But, this doesn't work always because we
> never know whether ther rfkill key event is generated.  The rfkill key
> event depends on BIOS. Thus, if we set the soft block as same as the
> hard block at the init time (and set as blocked), the soft block will
> be never unblocked if some BIOS version doesn't emit a key event.
>
> So we would like to discuss with the all experts here for this issue.
> Do you have a good idea to fix the rfkill for the issue ?

How is hard rfkill related to input handling? It shouldn't be.

I don't understand what you're saying I think.

johannes

[ath9k-devel] About rfkill racing issue.

[Takashi Iwai]

At Mon, 16 Apr 2012 10:34:14 -0700,
Johannes Berg wrote:
> 
> On 4/11/2012 11:15 PM, Matt Chen wrote:
> > Hi list,
> > It is found by notebook that rfkill doesn't work very right. I don't
> > know where to post this discussion, so I choose here to start the
> > talk.
> > Basically we found the input handler in net/rfkill/input.c , because
> > the nature of stateless key events, it can only toggle the saved
> > state.  This screws up when started as blocked at
> > boot, as already suspected.
> > Now we thought Synchronizing to the
> > hard block state looks as if working, but it's also dangerous because
> > the operation is racy. The hard block check on ath9k driver is done
> > in a poll basis, for example. Thus, the polling might happen just
> > before the key event is handled, and it might happen after the key
> > event.
> > Another option would be to get synchronize the soft block state at the
> > driver initialization time.  But, this doesn't work always because we
> > never know whether ther rfkill key event is generated.  The rfkill key
> > event depends on BIOS. Thus, if we set the soft block as same as the
> > hard block at the init time (and set as blocked), the soft block will
> > be never unblocked if some BIOS version doesn't emit a key event.
> >
> > So we would like to discuss with the all experts here for this issue.
> > Do you have a good idea to fix the rfkill for the issue ?
> 
> How is hard rfkill related to input handling? It shouldn't be.
> 
> I don't understand what you're saying I think.

The probblem we faced was that the hardware changes the hard rfkill
_and_ sends the WLAN key at the same time.  Since the rfkill input
handler toggles the soft rfkill at each WLAN key, if the rfkill
state at boot is like
	hard: block
	soft: unblock
then it'll change like
	hard: unblock
	soft: block
so the WLAN is never activated.

In the end, we fixed the problem by disabling the keymap for WLAN
key.  But this is also assuming that BIOS does always rfkill.  If BIOS
behavior suddenly changes, you'll loose the rfkill behavior.

Also, another drawback is that now rfkill isn't triggered immediately
with WLAN key but it waits for some seconds until hard block is
polled.  Ideally, it'd be good if the rfkill hard state can be checked
immediately when WLAN key is issued (but without touching soft
block).


thanks,

Takashi

Re: About rfkill racing issue.

[Takashi Iwai]

At Mon, 16 Apr 2012 10:34:14 -0700,
Johannes Berg wrote:
> 
> On 4/11/2012 11:15 PM, Matt Chen wrote:
> > Hi list,
> > It is found by notebook that rfkill doesn't work very right. I don't
> > know where to post this discussion, so I choose here to start the
> > talk.
> > Basically we found the input handler in net/rfkill/input.c , because
> > the nature of stateless key events, it can only toggle the saved
> > state.  This screws up when started as blocked at
> > boot, as already suspected.
> > Now we thought Synchronizing to the
> > hard block state looks as if working, but it's also dangerous because
> > the operation is racy. The hard block check on ath9k driver is done
> > in a poll basis, for example. Thus, the polling might happen just
> > before the key event is handled, and it might happen after the key
> > event.
> > Another option would be to get synchronize the soft block state at the
> > driver initialization time.  But, this doesn't work always because we
> > never know whether ther rfkill key event is generated.  The rfkill key
> > event depends on BIOS. Thus, if we set the soft block as same as the
> > hard block at the init time (and set as blocked), the soft block will
> > be never unblocked if some BIOS version doesn't emit a key event.
> >
> > So we would like to discuss with the all experts here for this issue.
> > Do you have a good idea to fix the rfkill for the issue ?
> 
> How is hard rfkill related to input handling? It shouldn't be.
> 
> I don't understand what you're saying I think.

The probblem we faced was that the hardware changes the hard rfkill
_and_ sends the WLAN key at the same time.  Since the rfkill input
handler toggles the soft rfkill at each WLAN key, if the rfkill
state at boot is like
	hard: block
	soft: unblock
then it'll change like
	hard: unblock
	soft: block
so the WLAN is never activated.

In the end, we fixed the problem by disabling the keymap for WLAN
key.  But this is also assuming that BIOS does always rfkill.  If BIOS
behavior suddenly changes, you'll loose the rfkill behavior.

Also, another drawback is that now rfkill isn't triggered immediately
with WLAN key but it waits for some seconds until hard block is
polled.  Ideally, it'd be good if the rfkill hard state can be checked
immediately when WLAN key is issued (but without touching soft
block).


thanks,

Takashi

[ath9k-devel] About rfkill racing issue.

[Johannes Berg]

Hi,

> The probblem we faced was that the hardware changes the hard rfkill
> _and_ sends the WLAN key at the same time.  Since the rfkill input
> handler toggles the soft rfkill at each WLAN key, if the rfkill
> state at boot is like
> 	hard: block
> 	soft: unblock
> then it'll change like
> 	hard: unblock
> 	soft: block
> so the WLAN is never activated.

Heh, funky.

> In the end, we fixed the problem by disabling the keymap for WLAN
> key.  But this is also assuming that BIOS does always rfkill.  If BIOS
> behavior suddenly changes, you'll loose the rfkill behavior.

Yeah, this is kinda dumb. But really it needs to be encapsulated in the
rfkill platform driver I think? Or is the WLAN key just a regular key on
the keyboard? Maybe the platform driver on this platform could bind it
and eat it?

> Also, another drawback is that now rfkill isn't triggered immediately
> with WLAN key but it waits for some seconds until hard block is
> polled.  Ideally, it'd be good if the rfkill hard state can be checked
> immediately when WLAN key is issued (but without touching soft
> block).

This has been talked about before I think, but I'm not sure it'd be good
generic behaviour?

johannes

Re: About rfkill racing issue.

[Johannes Berg]

Hi,

> The probblem we faced was that the hardware changes the hard rfkill
> _and_ sends the WLAN key at the same time.  Since the rfkill input
> handler toggles the soft rfkill at each WLAN key, if the rfkill
> state at boot is like
> 	hard: block
> 	soft: unblock
> then it'll change like
> 	hard: unblock
> 	soft: block
> so the WLAN is never activated.

Heh, funky.

> In the end, we fixed the problem by disabling the keymap for WLAN
> key.  But this is also assuming that BIOS does always rfkill.  If BIOS
> behavior suddenly changes, you'll loose the rfkill behavior.

Yeah, this is kinda dumb. But really it needs to be encapsulated in the
rfkill platform driver I think? Or is the WLAN key just a regular key on
the keyboard? Maybe the platform driver on this platform could bind it
and eat it?

> Also, another drawback is that now rfkill isn't triggered immediately
> with WLAN key but it waits for some seconds until hard block is
> polled.  Ideally, it'd be good if the rfkill hard state can be checked
> immediately when WLAN key is issued (but without touching soft
> block).

This has been talked about before I think, but I'm not sure it'd be good
generic behaviour?

johannes

[ath9k-devel] About rfkill racing issue.

[Takashi Iwai]

At Tue, 17 Apr 2012 18:27:56 -0700,
Johannes Berg wrote:
> 
> Hi,
> 
> > The probblem we faced was that the hardware changes the hard rfkill
> > _and_ sends the WLAN key at the same time.  Since the rfkill input
> > handler toggles the soft rfkill at each WLAN key, if the rfkill
> > state at boot is like
> > 	hard: block
> > 	soft: unblock
> > then it'll change like
> > 	hard: unblock
> > 	soft: block
> > so the WLAN is never activated.
> 
> Heh, funky.
> 
> > In the end, we fixed the problem by disabling the keymap for WLAN
> > key.  But this is also assuming that BIOS does always rfkill.  If BIOS
> > behavior suddenly changes, you'll loose the rfkill behavior.
> 
> Yeah, this is kinda dumb. But really it needs to be encapsulated in the
> rfkill platform driver I think? Or is the WLAN key just a regular key on
> the keyboard? Maybe the platform driver on this platform could bind it
> and eat it?

In our case, it was a regular key on HP laptops.  I also thought of
the platform WMI or ACPI, but surprisingly it wasn't.

> > Also, another drawback is that now rfkill isn't triggered immediately
> > with WLAN key but it waits for some seconds until hard block is
> > polled.  Ideally, it'd be good if the rfkill hard state can be checked
> > immediately when WLAN key is issued (but without touching soft
> > block).
> 
> This has been talked about before I think, but I'm not sure it'd be good
> generic behaviour?

It really depends on the machine.
This rfkill-sync behavior assumes that the hard rfkill is really
implemented.  Otherwise it's broken.  So, it's not safe as a global
behavior, indeed.  It must be chosend very selectively.

Changing WLAN key behavior globally also has another problem, too.  If
user has an external USB "multimedia" keyboard with a WLAN key, it
can't work as expected.

Maybe it'd be good to have a new key code for rfkill-sync, and change
the key to it if BIOS does hard rfkill (either via module option, DMI
matching, whatever).  Then still the external keyboard can send the
normal WLAN key to toggle soft rfkill.


thanks,

Takashi

Re: About rfkill racing issue.

[Takashi Iwai]

At Tue, 17 Apr 2012 18:27:56 -0700,
Johannes Berg wrote:
> 
> Hi,
> 
> > The probblem we faced was that the hardware changes the hard rfkill
> > _and_ sends the WLAN key at the same time.  Since the rfkill input
> > handler toggles the soft rfkill at each WLAN key, if the rfkill
> > state at boot is like
> > 	hard: block
> > 	soft: unblock
> > then it'll change like
> > 	hard: unblock
> > 	soft: block
> > so the WLAN is never activated.
> 
> Heh, funky.
> 
> > In the end, we fixed the problem by disabling the keymap for WLAN
> > key.  But this is also assuming that BIOS does always rfkill.  If BIOS
> > behavior suddenly changes, you'll loose the rfkill behavior.
> 
> Yeah, this is kinda dumb. But really it needs to be encapsulated in the
> rfkill platform driver I think? Or is the WLAN key just a regular key on
> the keyboard? Maybe the platform driver on this platform could bind it
> and eat it?

In our case, it was a regular key on HP laptops.  I also thought of
the platform WMI or ACPI, but surprisingly it wasn't.

> > Also, another drawback is that now rfkill isn't triggered immediately
> > with WLAN key but it waits for some seconds until hard block is
> > polled.  Ideally, it'd be good if the rfkill hard state can be checked
> > immediately when WLAN key is issued (but without touching soft
> > block).
> 
> This has been talked about before I think, but I'm not sure it'd be good
> generic behaviour?

It really depends on the machine.
This rfkill-sync behavior assumes that the hard rfkill is really
implemented.  Otherwise it's broken.  So, it's not safe as a global
behavior, indeed.  It must be chosend very selectively.

Changing WLAN key behavior globally also has another problem, too.  If
user has an external USB "multimedia" keyboard with a WLAN key, it
can't work as expected.

Maybe it'd be good to have a new key code for rfkill-sync, and change
the key to it if BIOS does hard rfkill (either via module option, DMI
matching, whatever).  Then still the external keyboard can send the
normal WLAN key to toggle soft rfkill.


thanks,

Takashi