Comment # 69 on bug 944978 from Larry Finger

(In reply to Takashi Iwai from comment #68)
> (In reply to Larry Finger from comment #55)
> > There is an error in the logic of this parameter. To handle the critical
> > cases, the logic should enable clear interrupts, and allow the user to
> > disable them if that works OK. The problem is that the code makes the wrong
> > test. At this point, I'm not sure what change I should make.
> 
> Let's start from the clear definition of the flag and the parameter :)
> 
> In one place:
> MODULE_PARM_DESC(int_clear, "Set to 1 to disable interrupt clear before set
> (default 0)\n");
> 
> In another place:
> struct rtl_mod_params {
> .... 
>        /* default 0: 1 means do not disable interrupts */
>        bool int_clear;
> 
> and yet it's evaluated like:
>        if (!rtlpci->int_clear)
>                rtl8821ae_clear_interrupt(hw);/*clear it here first*/
> 
> IMO, what "int_clear" implies is to clear int -- so if it's 1, it should do
> clear interrupts.  The description should be aligned with it.
> 
> One thing I'm not sure is about your intention of the default int_clear
> behavior.  Should it clear as default (for fixing this kind of bugs with
> risk of other breakage), or not clear (keeping 4.0 behavior as is but just
> provide an option to fix)?

The interrupt clear change proposal came from Realtek, where they found that
clearing the interrupts caused pauses in transmissions when using iperf. When
it was reported that this commit caused a regression that led to this lockup
for a few rtl8821ae units, reversion of the entire patch was proposed. I NACKed
that request and came up with this change. As you noted, I botched it. For
maximum availability, the default value of int_clear should enable the clearing
of interrupts. Then if a user complains of the TX pauses, then we suggest that
they change the parameter. The parameter should be set to 1 (true) and
interrupts should be cleared under that option.

I will be submitting a patch through the normal wireless channels. Once it hits
wireless-drivers-next, I will report the commit here.

Just for the record, this problem affects very few systems. Neither Realtek's
or my setup have this problem, which complicates the debugging.