[rt2x00-users] Last mcu request Indirect offset fail and wpdma busy (on rfkill)

[Ivo van Doorn]

Hi,

> >> The last issue regarding mcu error is when rfkill 0 . In this case the
> >> eeepc turn off the power of the pci device before calling the remove
> >> operation.
> >>
> >> Thus the radio off and led unregister in rt2x00lib_remove_dev fails with
> >> the above errors.
> >>
> >> It is minor though could lead to bug reports . I wonder if
> >> rt2x00lib_remove_dev should take care of not calling those (radio off
> >> and leds) in case of rfkill on the eeepc ... .
> >>     
> >
> > If rfkill support is enabled, then rfkill should have disabled the radio,
> > and when that happens then during shutdown the radio won't be disabled
> > twice.
> >   
> It does not . Or did you mean for it to disable it via hw (that is 
> shutting of the power of the pci device). In the later case the issue is 
> that the presence flag is not cleared before the call to disable_radio 
> .... thus my asking whether it was worth trying to workaround rt2x00 
> attempting to turn off radio in sw when it was turned down in pci hw 
> before it.

The method of how the wireless interface is disabled completely depends
on the rfkill listener. rt2x00 only sends out the signal to disable the radio,
it does not disable the radio itself.

> Here is my trace with  a lot of debugging printk about the process 
> (about mac80211 I still have only traced ieee80211_* calls calling 
> rt2x00mac_config. Though all the functions  inside rt2x000  have an ">>> 
> ENTER" and an "<<< EXIT" except rt2xqueue and interrupts (only rx . 
> Nothing is ever transmitted . That s another issue) because otherwise 
> the trace is too long.

I have mentioned before that your mailclient is breaking off lines which
makes the logfile hard to read. Please fix your mailclient, or send stuff
like debuglogs as attachment.

> johill explained me that when eeepc notify about rfkill status it 
> already have shutoff the power from the pci device. Thus all the 
> registry equals ffffffff.

Not sure if I understand you. When the switch is set to "blocked" the
hardware is truly blocked and doesn't actually need a listener?

> If rfkill is  supposed to trigger  mac80211 stop before this 
> notification , here it does not .-(

That depends on the listener, which in your case would be eeepc-laptop.

> I am still investigating the mcu issue . Though as it relates a lot to 
> the rfkill type (I have been unable till now to get the device to 
> respond after an input_register_polled_device with EV_SW and sw bit at 
> SW_RFKILL_ALL.

Ok so that means the GPIO bit isn't changes when the switch is moved.
Perhaps we are reading the wrong GPIO bit?

> I only get ffff GPIO status when using EV_SW and only at first phy0 
> attempt . I ll investigate this one back again as it could be that this 
> ff1f means not sw off . In which case it would explains why I get no 
> real transmissions (only rx interrupts are raised and none reach 
> wireshark). This would mean the bit for the status is not "0x4" but "0x10".

Could you try this change in rt2800pci_rfkill_poll()
and see if it works better then?

Ivo