[BUG] staging: r8822be: RTL8822be can't find any wireless AP

[BUG] staging: r8822be: RTL8822be can't find any wireless AP

[Jian-Hong Pan]

Hi,

We have an ASUS X530UN (Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz)
laptop equipped with Realtek rtl8822be wireless which cannot find any
access point after WiFi is launched.

Realtek rtl8822be wireless' information:
dev@endless:~/linux-eos$ sudo lspci -nnvs 02:00.0
02:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd.
Device [10ec:b822] (rev ff) (prog-if ff)
!!! Unknown header type 7f
Kernel driver in use: r8822be
Kernel modules: r8822be

System always hits the error: "halmac_init_hal failed" in dmesg after
WiFi is launched.

[ 8.591333] r8822be: module is from the staging directory, the quality
is unknown, you have been warned.
[ 8.593122] r8822be 0000:02:00.0: enabling device (0000 -> 0003)
[ 8.669163] r8822be: Using firmware rtlwifi/rtl8822befw.bin
[ 9.289939] r8822be: rtlwifi: wireless switch is on
[ 10.056426] r8822be 0000:02:00.0 wlp2s0: renamed from wlan0
...
[ 11.952534] r8822be: halmac_init_hal failed
[ 11.955933] r8822be: halmac_init_hal failed
[ 11.956227] r8822be: halmac_init_hal failed
[ 22.007942] r8822be: halmac_init_hal failed

We noticed the r8822be module parameter "aspm"'s default value is 1.
Here is the parameter list of r8822be:
dev@endless:~$ sudo grep "" /sys/module/r8822be/parameters/*
/sys/module/r8822be/parameters/aspm:1
/sys/module/r8822be/parameters/debug_level:0
/sys/module/r8822be/parameters/debug_mask:0
/sys/module/r8822be/parameters/disable_watchdog:N
/sys/module/r8822be/parameters/dma64:N
/sys/module/r8822be/parameters/fwlps:Y
/sys/module/r8822be/parameters/ips:Y
/sys/module/r8822be/parameters/msi:Y
/sys/module/r8822be/parameters/swenc:N
/sys/module/r8822be/parameters/swlps:N

If I make a module options like "options r8822be aspm=0" which
disables ASPM and reboot, the WiFi works correctly.  It can find the
access points, then connects.
Here is the parameter list of r8822be:
dev@endless:~$ sudo grep "" /sys/module/r8822be/parameters/*
/sys/module/r8822be/parameters/aspm:0
/sys/module/r8822be/parameters/debug_level:0
/sys/module/r8822be/parameters/debug_mask:0
/sys/module/r8822be/parameters/disable_watchdog:N
/sys/module/r8822be/parameters/dma64:N
/sys/module/r8822be/parameters/fwlps:Y
/sys/module/r8822be/parameters/ips:Y
/sys/module/r8822be/parameters/msi:Y
/sys/module/r8822be/parameters/swenc:N
/sys/module/r8822be/parameters/swlps:N

This issue can be reproduced on Linux stable 4.16.17, 4.17.2 and
4.18.0-rc3. (I list versions that we have tried)

Besides, I also notice there is a comment in
drivers/staging/rtlwifi/rtl8822be/sw.c rtl8822be_init_aspm_vars
function.

/*
 * This setting works for those device with
 * backdoor ASPM setting such as EPHY setting.
 * 0 - Not support ASPM,
 * 1 - Support ASPM,
 * 2 - According to chipset.
 */

The value 2 for ASPM interests me.  It says "Enable or disable ASPM
according to chipset."
I tried the setting value 2 for ASPM.  Here is the parameter list of r8822be:
dev@endless:~$ sudo grep "" /sys/module/r8822be/parameters/*
/sys/module/r8822be/parameters/aspm:2
/sys/module/r8822be/parameters/debug_level:0
/sys/module/r8822be/parameters/debug_mask:0
/sys/module/r8822be/parameters/disable_watchdog:N
/sys/module/r8822be/parameters/dma64:N
/sys/module/r8822be/parameters/fwlps:Y
/sys/module/r8822be/parameters/ips:Y
/sys/module/r8822be/parameters/msi:Y
/sys/module/r8822be/parameters/swenc:N
/sys/module/r8822be/parameters/swlps:N

The value 2 for ASPM also works correctly on ASUS X530UN.

Jian-Hong Pan

Re: [BUG] staging: r8822be: RTL8822be can't find any wireless AP

[Dan Carpenter]

On Wed, Jul 04, 2018 at 04:03:33PM +0800, Jian-Hong Pan wrote:
> Hi,
> 
> We have an ASUS X530UN (Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz)
> laptop equipped with Realtek rtl8822be wireless which cannot find any
> access point after WiFi is launched.
> 
> Realtek rtl8822be wireless' information:
> dev@endless:~/linux-eos$ sudo lspci -nnvs 02:00.0
> 02:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd.
> Device [10ec:b822] (rev ff) (prog-if ff)
> !!! Unknown header type 7f
> Kernel driver in use: r8822be
> Kernel modules: r8822be
> 
> System always hits the error: "halmac_init_hal failed" in dmesg after
> WiFi is launched.
> 
> [ 8.591333] r8822be: module is from the staging directory, the quality
> is unknown, you have been warned.
> [ 8.593122] r8822be 0000:02:00.0: enabling device (0000 -> 0003)
> [ 8.669163] r8822be: Using firmware rtlwifi/rtl8822befw.bin
> [ 9.289939] r8822be: rtlwifi: wireless switch is on
> [ 10.056426] r8822be 0000:02:00.0 wlp2s0: renamed from wlan0
> ...
> [ 11.952534] r8822be: halmac_init_hal failed
> [ 11.955933] r8822be: halmac_init_hal failed
> [ 11.956227] r8822be: halmac_init_hal failed
> [ 22.007942] r8822be: halmac_init_hal failed

I really prefer to see the whole dmesg instead of an edited ... in the
middle.

I agree that it feels like the default aspm setting should be 2 (use
what the chip says).  Although I don't know the device well enough to
say if that will break anyone's system.  Perhaps someone who knows
better will be able to respond.

regards,
dan carpenter

Re: [BUG] staging: r8822be: RTL8822be can't find any wireless AP

[Daniel Drake]

On Wed, Jul 4, 2018 at 8:04 AM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> I really prefer to see the whole dmesg instead of an edited ... in the
> middle.

Full log:
https://gist.github.com/dsd/20c05f0c6d66ee2ef9bfbb17f93f18ba

> I agree that it feels like the default aspm setting should be 2 (use
> what the chip says).  Although I don't know the device well enough to
> say if that will break anyone's system.  Perhaps someone who knows
> better will be able to respond.

Looking at the code for _rtl_pci_update_default_setting(), the meaning
of value 2 actually seems to be "enable ASPM on Intel platforms, and
disable on others".

But I suspect that code is not working right, because the system we
are using here is Intel-based and so my expectation would be that
value 2 leaves ASPM on and we would continue seeing the issue.
However, Jian-Hong reports it as working.

There are also some other reports that this driver doesn't work until
aspm is disabled:
https://bugzilla.redhat.com/show_bug.cgi?id=1464731#c21
https://ubuntuforums.org/showthread.php?t=2364383&page=4&p=13748721#post13748721
https://bugzilla.kernel.org/show_bug.cgi?id=199651

Daniel

Re: [BUG] staging: r8822be: RTL8822be can't find any wireless AP

[Larry Finger]

On 07/04/2018 03:03 AM, Jian-Hong Pan wrote:
> Hi,
> 
> We have an ASUS X530UN (Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz)
> laptop equipped with Realtek rtl8822be wireless which cannot find any
> access point after WiFi is launched.
> 
> Realtek rtl8822be wireless' information:
> dev@endless:~/linux-eos$ sudo lspci -nnvs 02:00.0
> 02:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd.
> Device [10ec:b822] (rev ff) (prog-if ff)
> !!! Unknown header type 7f
> Kernel driver in use: r8822be
> Kernel modules: r8822be
> 
> System always hits the error: "halmac_init_hal failed" in dmesg after
> WiFi is launched.
> 
> [ 8.591333] r8822be: module is from the staging directory, the quality
> is unknown, you have been warned.
> [ 8.593122] r8822be 0000:02:00.0: enabling device (0000 -> 0003)
> [ 8.669163] r8822be: Using firmware rtlwifi/rtl8822befw.bin
> [ 9.289939] r8822be: rtlwifi: wireless switch is on
> [ 10.056426] r8822be 0000:02:00.0 wlp2s0: renamed from wlan0
> ...
> [ 11.952534] r8822be: halmac_init_hal failed
> [ 11.955933] r8822be: halmac_init_hal failed
> [ 11.956227] r8822be: halmac_init_hal failed
> [ 22.007942] r8822be: halmac_init_hal failed
> 
> We noticed the r8822be module parameter "aspm"'s default value is 1.
> Here is the parameter list of r8822be:
> dev@endless:~$ sudo grep "" /sys/module/r8822be/parameters/*
> /sys/module/r8822be/parameters/aspm:1
> /sys/module/r8822be/parameters/debug_level:0
> /sys/module/r8822be/parameters/debug_mask:0
> /sys/module/r8822be/parameters/disable_watchdog:N
> /sys/module/r8822be/parameters/dma64:N
> /sys/module/r8822be/parameters/fwlps:Y
> /sys/module/r8822be/parameters/ips:Y
> /sys/module/r8822be/parameters/msi:Y
> /sys/module/r8822be/parameters/swenc:N
> /sys/module/r8822be/parameters/swlps:N
> 
> If I make a module options like "options r8822be aspm=0" which
> disables ASPM and reboot, the WiFi works correctly.  It can find the
> access points, then connects.
> Here is the parameter list of r8822be:
> dev@endless:~$ sudo grep "" /sys/module/r8822be/parameters/*
> /sys/module/r8822be/parameters/aspm:0
> /sys/module/r8822be/parameters/debug_level:0
> /sys/module/r8822be/parameters/debug_mask:0
> /sys/module/r8822be/parameters/disable_watchdog:N
> /sys/module/r8822be/parameters/dma64:N
> /sys/module/r8822be/parameters/fwlps:Y
> /sys/module/r8822be/parameters/ips:Y
> /sys/module/r8822be/parameters/msi:Y
> /sys/module/r8822be/parameters/swenc:N
> /sys/module/r8822be/parameters/swlps:N
> 
> This issue can be reproduced on Linux stable 4.16.17, 4.17.2 and
> 4.18.0-rc3. (I list versions that we have tried)
> 
> Besides, I also notice there is a comment in
> drivers/staging/rtlwifi/rtl8822be/sw.c rtl8822be_init_aspm_vars
> function.
> 
> /*
>   * This setting works for those device with
>   * backdoor ASPM setting such as EPHY setting.
>   * 0 - Not support ASPM,
>   * 1 - Support ASPM,
>   * 2 - According to chipset.
>   */
> 
> The value 2 for ASPM interests me.  It says "Enable or disable ASPM
> according to chipset."
> I tried the setting value 2 for ASPM.  Here is the parameter list of r8822be:
> dev@endless:~$ sudo grep "" /sys/module/r8822be/parameters/*
> /sys/module/r8822be/parameters/aspm:2
> /sys/module/r8822be/parameters/debug_level:0
> /sys/module/r8822be/parameters/debug_mask:0
> /sys/module/r8822be/parameters/disable_watchdog:N
> /sys/module/r8822be/parameters/dma64:N
> /sys/module/r8822be/parameters/fwlps:Y
> /sys/module/r8822be/parameters/ips:Y
> /sys/module/r8822be/parameters/msi:Y
> /sys/module/r8822be/parameters/swenc:N
> /sys/module/r8822be/parameters/swlps:N
> 
> The value 2 for ASPM also works correctly on ASUS X530UN.

I do not think this is a bug. Most motherboards work with the default value of 1 
for aspm. A few, such as yours need a value of 0. This reason is why the module 
parameter exists. You need to create the options file that you mention, and you 
will be fine. If we were to change the default in the driver to 0, we would 
break many more devices than would be fixed.

For anyone that might read this, the options file should be named 
/etc/modprobe.d/50-rtl8822be.conf and contain a single line "options rtl8822be 
aspm=0".

Larry

Re: [BUG] staging: r8822be: RTL8822be can't find any wireless AP

[Dan Carpenter]

On Wed, Jul 04, 2018 at 08:55:00AM -0500, Larry Finger wrote:
> I do not think this is a bug.

It's obviously a bug.  The driver should just work by default.

As a last resort, we would do something like add quirk or something.  I
haven't looked at how quirks would be handled for this driver but grep
for quirk to see how other drivers do it.

regards,
dan carpenter

Re: [BUG] staging: r8822be: RTL8822be can't find any wireless AP

[Larry Finger]

On 07/04/2018 09:09 AM, Dan Carpenter wrote:
> On Wed, Jul 04, 2018 at 08:55:00AM -0500, Larry Finger wrote:
>> I do not think this is a bug.
> 
> It's obviously a bug.  The driver should just work by default.
> 
> As a last resort, we would do something like add quirk or something.  I
> haven't looked at how quirks would be handled for this driver but grep
> for quirk to see how other drivers do it.

We will have to agree to disagree.

I have no idea what the vendors are doing that cause some motherboards to need a 
different aspm value. What I do know is that we have had to live with the idiocy 
of some vendors saving a few pennies by only including a single antenna, rather 
than two, and then making a problem by miscoding the EFUSE bit that indicates 
which connector is actually in use. As we have no means that I know about to 
detect which boxes have the problem, a module parameter was created, just as in 
this case.

I agree that drivers should work "out of the box", but finite resources and lack 
of vendor cooperation make this a goal that may not be attainable.

Larry

Re: [BUG] staging: r8822be: RTL8822be can't find any wireless AP

[Daniel Drake]

On Wed, Jul 4, 2018 at 10:13 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> We will have to agree to disagree.
>
> I have no idea what the vendors are doing that cause some motherboards to
> need a different aspm value. What I do know is that we have had to live with
> the idiocy of some vendors saving a few pennies by only including a single
> antenna, rather than two, and then making a problem by miscoding the EFUSE
> bit that indicates which connector is actually in use. As we have no means
> that I know about to detect which boxes have the problem, a module parameter
> was created, just as in this case.
>
> I agree that drivers should work "out of the box", but finite resources and
> lack of vendor cooperation make this a goal that may not be attainable.

As you touched on, the ideal situation is that Realtek solve the
issue. Ping-Ke Shih is on CC and I am adding a few more contacts from
the commit log. The context is that the r8822 driver fails on several
platforms unless setting aspm=0 (the default is 1).

https://gist.github.com/dsd/20c05f0c6d66ee2ef9bfbb17f93f18ba
https://bugzilla.kernel.org/show_bug.cgi?id=199651


If we don't get a timely fix from Realtek though, I think there is a
key difference between the antenna selection headache and this one. In
the antenna case, there isn't a good value that you can set that will
work on all systems. If you change the default behaviour you will
solve the issue for some users while simultanously introducing the
problem on other systems that were previously fine.

However in this case, it's highly likely that setting aspm=0 (off) by
default would work for everyone. It has the disadvantage of using a
bit more power, but especially with the indications that this issue
affects a significant number of systems, I think that having the
driver working out of the box everywhere is more important. The module
parameter can be left in place so that unaffected users that want to
save power can set aspm=1.

Daniel

Re: [BUG] staging: r8822be: RTL8822be can't find any wireless AP

[Pkshih]

T24gV2VkLCAyMDE4LTA3LTA0IGF0IDEwOjMzIC0wNTAwLCBEYW5pZWwgRHJha2Ugd3JvdGU6DQo+
IE9uIFdlZCwgSnVsIDQsIDIwMTggYXQgMTA6MTMgQU0sIExhcnJ5IEZpbmdlciA8TGFycnkuRmlu
Z2VyQGx3ZmluZ2VyLm5ldD4gd3JvdGU6DQo+ID4gV2Ugd2lsbCBoYXZlIHRvIGFncmVlIHRvIGRp
c2FncmVlLg0KPiA+DQo+ID4gSSBoYXZlIG5vIGlkZWEgd2hhdCB0aGUgdmVuZG9ycyBhcmUgZG9p
bmcgdGhhdCBjYXVzZSBzb21lIG1vdGhlcmJvYXJkcyB0bw0KPiA+IG5lZWQgYSBkaWZmZXJlbnQg
YXNwbSB2YWx1ZS4gV2hhdCBJIGRvIGtub3cgaXMgdGhhdCB3ZSBoYXZlIGhhZCB0byBsaXZlIHdp
dGgNCj4gPiB0aGUgaWRpb2N5IG9mIHNvbWUgdmVuZG9ycyBzYXZpbmcgYSBmZXcgcGVubmllcyBi
eSBvbmx5IGluY2x1ZGluZyBhIHNpbmdsZQ0KPiA+IGFudGVubmEsIHJhdGhlciB0aGFuIHR3bywg
YW5kIHRoZW4gbWFraW5nIGEgcHJvYmxlbSBieSBtaXNjb2RpbmcgdGhlIEVGVVNFDQo+ID4gYml0
IHRoYXQgaW5kaWNhdGVzIHdoaWNoIGNvbm5lY3RvciBpcyBhY3R1YWxseSBpbiB1c2UuIEFzIHdl
IGhhdmUgbm8gbWVhbnMNCj4gPiB0aGF0IEkga25vdyBhYm91dCB0byBkZXRlY3Qgd2hpY2ggYm94
ZXMgaGF2ZSB0aGUgcHJvYmxlbSwgYSBtb2R1bGUgcGFyYW1ldGVyDQo+ID4gd2FzIGNyZWF0ZWQs
IGp1c3QgYXMgaW4gdGhpcyBjYXNlLg0KPiA+DQo+ID4gSSBhZ3JlZSB0aGF0IGRyaXZlcnMgc2hv
dWxkIHdvcmsgIm91dCBvZiB0aGUgYm94IiwgYnV0IGZpbml0ZSByZXNvdXJjZXMgYW5kDQo+ID4g
bGFjayBvZiB2ZW5kb3IgY29vcGVyYXRpb24gbWFrZSB0aGlzIGEgZ29hbCB0aGF0IG1heSBub3Qg
YmUgYXR0YWluYWJsZS4NCj4gDQo+IEFzIHlvdSB0b3VjaGVkIG9uLCB0aGUgaWRlYWwgc2l0dWF0
aW9uIGlzIHRoYXQgUmVhbHRlayBzb2x2ZSB0aGUNCj4gaXNzdWUuIFBpbmctS2UgU2hpaCBpcyBv
biBDQyBhbmQgSSBhbSBhZGRpbmcgYSBmZXcgbW9yZSBjb250YWN0cyBmcm9tDQo+IHRoZSBjb21t
aXQgbG9nLiBUaGUgY29udGV4dCBpcyB0aGF0IHRoZSByODgyMiBkcml2ZXIgZmFpbHMgb24gc2V2
ZXJhbA0KPiBwbGF0Zm9ybXMgdW5sZXNzIHNldHRpbmcgYXNwbT0wICh0aGUgZGVmYXVsdCBpcyAx
KS4NCg0KSXQncyBoYXJkIHRvIGhhdmUgYWxsIGxhcHRvcCBvciBtb3RoZXJib2FyZHMgYW5kIGFs
bCBydGw4ODIyYmUgbW9kdWxlcyBpbiBteSBzaWRlLA0Kc28gd2hhdCBJIGNhbiBkbyBpcyB0byBh
bmFseXplIHRoZSBpc3N1ZSB3aGVuIHVzZXIgZW5jb3VudGVyZWQuDQoNCj4gDQo+IGh0dHBzOi8v
Z2lzdC5naXRodWIuY29tL2RzZC8yMGMwNWYwYzZkNjZlZTJlZjliZmJiMTdmOTNmMThiYQ0KPiBo
dHRwczovL2J1Z3ppbGxhLmtlcm5lbC5vcmcvc2hvd19idWcuY2dpP2lkPTE5OTY1MQ0KPiANCj4g
DQo+IElmIHdlIGRvbid0IGdldCBhIHRpbWVseSBmaXggZnJvbSBSZWFsdGVrIHRob3VnaCwgSSB0
aGluayB0aGVyZSBpcyBhDQo+IGtleSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIGFudGVubmEgc2Vs
ZWN0aW9uIGhlYWRhY2hlIGFuZCB0aGlzIG9uZS4gSW4NCj4gdGhlIGFudGVubmEgY2FzZSwgdGhl
cmUgaXNuJ3QgYSBnb29kIHZhbHVlIHRoYXQgeW91IGNhbiBzZXQgdGhhdCB3aWxsDQo+IHdvcmsg
b24gYWxsIHN5c3RlbXMuIElmIHlvdSBjaGFuZ2UgdGhlIGRlZmF1bHQgYmVoYXZpb3VyIHlvdSB3
aWxsDQo+IHNvbHZlIHRoZSBpc3N1ZSBmb3Igc29tZSB1c2VycyB3aGlsZSBzaW11bHRhbm91c2x5
IGludHJvZHVjaW5nIHRoZQ0KPiBwcm9ibGVtIG9uIG90aGVyIHN5c3RlbXMgdGhhdCB3ZXJlIHBy
ZXZpb3VzbHkgZmluZS4NCj4gDQo+IEhvd2V2ZXIgaW4gdGhpcyBjYXNlLCBpdCdzIGhpZ2hseSBs
aWtlbHkgdGhhdCBzZXR0aW5nIGFzcG09MCAob2ZmKSBieQ0KPiBkZWZhdWx0IHdvdWxkIHdvcmsg
Zm9yIGV2ZXJ5b25lLiBJdCBoYXMgdGhlIGRpc2FkdmFudGFnZSBvZiB1c2luZyBhDQo+IGJpdCBt
b3JlIHBvd2VyLCBidXQgZXNwZWNpYWxseSB3aXRoIHRoZSBpbmRpY2F0aW9ucyB0aGF0IHRoaXMg
aXNzdWUNCj4gYWZmZWN0cyBhIHNpZ25pZmljYW50IG51bWJlciBvZiBzeXN0ZW1zLCBJIHRoaW5r
IHRoYXQgaGF2aW5nIHRoZQ0KPiBkcml2ZXIgd29ya2luZyBvdXQgb2YgdGhlIGJveCBldmVyeXdo
ZXJlIGlzIG1vcmUgaW1wb3J0YW50LiBUaGUgbW9kdWxlDQo+IHBhcmFtZXRlciBjYW4gYmUgbGVm
dCBpbiBwbGFjZSBzbyB0aGF0IHVuYWZmZWN0ZWQgdXNlcnMgdGhhdCB3YW50IHRvDQo+IHNhdmUg
cG93ZXIgY2FuIHNldCBhc3BtPTEuDQo+IA0KDQpJIHRoaW5rIHRoaXMgaXNzdWUgbWF5IGJlIGR1
ZSB0byBMMSBsYXRlbmN5LCBzbyBiZWxvdyBwYXRjaCB3b3VsZCBiZQ0KaGVscGZ1bCBidXQgbm90
IHN1cmUgYmVjYXVzZSBJIGRvbid0IGhhdmUgdGhlIHNhbWUgbGFwdG9wLg0KSXMgdGhlcmUgYW55
b25lIGNhbiBoZWxwIHRvIHRlc3Q/DQoNCg0KZGlmZiAtLWdpdCBhL2RyaXZlcnMvc3RhZ2luZy9y
dGx3aWZpL3J0bDg4MjJiZS9ody5jIGIvZHJpdmVycy9zdGFnaW5nL3J0bHdpZmkvcnRsODgyMmJl
L2h3LmMNCmluZGV4IDc5NDdlZGIyMzlhMS4uODhiYTViMmZlYTZhIDEwMDY0NA0KLS0tIGEvZHJp
dmVycy9zdGFnaW5nL3J0bHdpZmkvcnRsODgyMmJlL2h3LmMNCisrKyBiL2RyaXZlcnMvc3RhZ2lu
Zy9ydGx3aWZpL3J0bDg4MjJiZS9ody5jDQpAQCAtODAzLDcgKzgwMyw3IEBAIHN0YXRpYyB2b2lk
IF9ydGw4ODIyYmVfZW5hYmxlX2FzcG1fYmFja19kb29yKHN0cnVjdCBpZWVlODAyMTFfaHcgKmh3
KQ0KwqAJCXJldHVybjsNCsKgDQrCoAlwY2lfcmVhZF9jb25maWdfYnl0ZShydGxwY2ktPnBkZXYs
IDB4NzBmLCAmdG1wKTsNCi0JcGNpX3dyaXRlX2NvbmZpZ19ieXRlKHJ0bHBjaS0+cGRldiwgMHg3
MGYsIHRtcCB8IEJJVCg3KSk7DQorCXBjaV93cml0ZV9jb25maWdfYnl0ZShydGxwY2ktPnBkZXYs
IDB4NzBmLCB0bXAgfCBBU1BNX0wxX0xBVEVOQ1kgPDwgMyk7DQrCoA0KwqAJcGNpX3JlYWRfY29u
ZmlnX2J5dGUocnRscGNpLT5wZGV2LCAweDcxOSwgJnRtcCk7DQrCoAlwY2lfd3JpdGVfY29uZmln
X2J5dGUocnRscGNpLT5wZGV2LCAweDcxOSwgdG1wIHwgQklUKDMpIHwgQklUKDQpKTsNCmRpZmYg
LS1naXQgYS9kcml2ZXJzL3N0YWdpbmcvcnRsd2lmaS93aWZpLmggYi9kcml2ZXJzL3N0YWdpbmcv
cnRsd2lmaS93aWZpLmgNCmluZGV4IDAxMmZiNjE4ODQwYi4uYTQ1ZjBlYjY5ZDNmIDEwMDY0NA0K
LS0tIGEvZHJpdmVycy9zdGFnaW5nL3J0bHdpZmkvd2lmaS5oDQorKysgYi9kcml2ZXJzL3N0YWdp
bmcvcnRsd2lmaS93aWZpLmgNCkBAIC04OCw2ICs4OCw3IEBADQrCoCNkZWZpbmUgUlRMX1VTQl9N
QVhfUlhfQ09VTlQJCQkxMDANCsKgI2RlZmluZSBRQlNTX0xPQURfU0laRQkJCQk1DQrCoCNkZWZp
bmUgTUFYX1dNTUVMRV9MRU5HVEgJCQk2NA0KKyNkZWZpbmUgQVNQTV9MMV9MQVRFTkNZCQkJCTcN
CsKgDQrCoCNkZWZpbmUgVE9UQUxfQ0FNX0VOVFJZCQkJCTMyDQrCoA0KDQotLS0NClBLDQoNCg==

Re: [BUG] staging: r8822be: RTL8822be can't find any wireless AP

[Pkshih]

On Wed, 2018-07-04 at 10:33 -0500, Daniel Drake wrote:
> On Wed, Jul 4, 2018 at 10:13 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> > We will have to agree to disagree.
> >
> > I have no idea what the vendors are doing that cause some motherboards to
> > need a different aspm value. What I do know is that we have had to live with
> > the idiocy of some vendors saving a few pennies by only including a single
> > antenna, rather than two, and then making a problem by miscoding the EFUSE
> > bit that indicates which connector is actually in use. As we have no means
> > that I know about to detect which boxes have the problem, a module parameter
> > was created, just as in this case.
> >
> > I agree that drivers should work "out of the box", but finite resources and
> > lack of vendor cooperation make this a goal that may not be attainable.
> 
> As you touched on, the ideal situation is that Realtek solve the
> issue. Ping-Ke Shih is on CC and I am adding a few more contacts from
> the commit log. The context is that the r8822 driver fails on several
> platforms unless setting aspm=0 (the default is 1).

It's hard to have all laptop or motherboards and all rtl8822be modules in my side,
so what I can do is to analyze the issue when user encountered.

> 
> https://gist.github.com/dsd/20c05f0c6d66ee2ef9bfbb17f93f18ba
> https://bugzilla.kernel.org/show_bug.cgi?id=199651
> 
> 
> If we don't get a timely fix from Realtek though, I think there is a
> key difference between the antenna selection headache and this one. In
> the antenna case, there isn't a good value that you can set that will
> work on all systems. If you change the default behaviour you will
> solve the issue for some users while simultanously introducing the
> problem on other systems that were previously fine.
> 
> However in this case, it's highly likely that setting aspm=0 (off) by
> default would work for everyone. It has the disadvantage of using a
> bit more power, but especially with the indications that this issue
> affects a significant number of systems, I think that having the
> driver working out of the box everywhere is more important. The module
> parameter can be left in place so that unaffected users that want to
> save power can set aspm=1.
> 

I think this issue may be due to L1 latency, so below patch would be
helpful but not sure because I don't have the same laptop.
Is there anyone can help to test?


diff --git a/drivers/staging/rtlwifi/rtl8822be/hw.c b/drivers/staging/rtlwifi/rtl8822be/hw.c
index 7947edb239a1..88ba5b2fea6a 100644
--- a/drivers/staging/rtlwifi/rtl8822be/hw.c
+++ b/drivers/staging/rtlwifi/rtl8822be/hw.c
@@ -803,7 +803,7 @@ static void _rtl8822be_enable_aspm_back_door(struct ieee80211_hw *hw)
 		return;
 
 	pci_read_config_byte(rtlpci->pdev, 0x70f, &tmp);
-	pci_write_config_byte(rtlpci->pdev, 0x70f, tmp | BIT(7));
+	pci_write_config_byte(rtlpci->pdev, 0x70f, tmp | ASPM_L1_LATENCY << 3);
 
 	pci_read_config_byte(rtlpci->pdev, 0x719, &tmp);
 	pci_write_config_byte(rtlpci->pdev, 0x719, tmp | BIT(3) | BIT(4));
diff --git a/drivers/staging/rtlwifi/wifi.h b/drivers/staging/rtlwifi/wifi.h
index 012fb618840b..a45f0eb69d3f 100644
--- a/drivers/staging/rtlwifi/wifi.h
+++ b/drivers/staging/rtlwifi/wifi.h
@@ -88,6 +88,7 @@
 #define RTL_USB_MAX_RX_COUNT			100
 #define QBSS_LOAD_SIZE				5
 #define MAX_WMMELE_LENGTH			64
+#define ASPM_L1_LATENCY				7
 
 #define TOTAL_CAM_ENTRY				32
 

---
PK

Re: [BUG] staging: r8822be: RTL8822be can't find any wireless AP

[Jian-Hong Pan]

2018-07-05 15:36 GMT+08:00 Pkshih <pkshih@realtek.com>:
> On Wed, 2018-07-04 at 10:33 -0500, Daniel Drake wrote:
>> On Wed, Jul 4, 2018 at 10:13 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> > We will have to agree to disagree.
>> >
>> > I have no idea what the vendors are doing that cause some motherboards to
>> > need a different aspm value. What I do know is that we have had to live with
>> > the idiocy of some vendors saving a few pennies by only including a single
>> > antenna, rather than two, and then making a problem by miscoding the EFUSE
>> > bit that indicates which connector is actually in use. As we have no means
>> > that I know about to detect which boxes have the problem, a module parameter
>> > was created, just as in this case.
>> >
>> > I agree that drivers should work "out of the box", but finite resources and
>> > lack of vendor cooperation make this a goal that may not be attainable.
>>
>> As you touched on, the ideal situation is that Realtek solve the
>> issue. Ping-Ke Shih is on CC and I am adding a few more contacts from
>> the commit log. The context is that the r8822 driver fails on several
>> platforms unless setting aspm=0 (the default is 1).
>
> It's hard to have all laptop or motherboards and all rtl8822be modules in my side,
> so what I can do is to analyze the issue when user encountered.
>
>>
>> https://gist.github.com/dsd/20c05f0c6d66ee2ef9bfbb17f93f18ba
>> https://bugzilla.kernel.org/show_bug.cgi?id=199651
>>
>>
>> If we don't get a timely fix from Realtek though, I think there is a
>> key difference between the antenna selection headache and this one. In
>> the antenna case, there isn't a good value that you can set that will
>> work on all systems. If you change the default behaviour you will
>> solve the issue for some users while simultanously introducing the
>> problem on other systems that were previously fine.
>>
>> However in this case, it's highly likely that setting aspm=0 (off) by
>> default would work for everyone. It has the disadvantage of using a
>> bit more power, but especially with the indications that this issue
>> affects a significant number of systems, I think that having the
>> driver working out of the box everywhere is more important. The module
>> parameter can be left in place so that unaffected users that want to
>> save power can set aspm=1.
>>
>
> I think this issue may be due to L1 latency, so below patch would be
> helpful but not sure because I don't have the same laptop.
> Is there anyone can help to test?

I do not know why I cannot apply this patch directly.  So, I apply
each line manually.

However, here is a good news.  I tested this fix, and it works
correctly on ASUS X530UN.  System can scan and get the access points
list.  Finally, it also connects to the access point.
Maybe, you can have a formal patch for this.

Thanks,
Jian-Hong Pan

>
> diff --git a/drivers/staging/rtlwifi/rtl8822be/hw.c b/drivers/staging/rtlwifi/rtl8822be/hw.c
> index 7947edb239a1..88ba5b2fea6a 100644
> --- a/drivers/staging/rtlwifi/rtl8822be/hw.c
> +++ b/drivers/staging/rtlwifi/rtl8822be/hw.c
> @@ -803,7 +803,7 @@ static void _rtl8822be_enable_aspm_back_door(struct ieee80211_hw *hw)
>                 return;
>
>         pci_read_config_byte(rtlpci->pdev, 0x70f, &tmp);
> -       pci_write_config_byte(rtlpci->pdev, 0x70f, tmp | BIT(7));
> +       pci_write_config_byte(rtlpci->pdev, 0x70f, tmp | ASPM_L1_LATENCY << 3);
>
>         pci_read_config_byte(rtlpci->pdev, 0x719, &tmp);
>         pci_write_config_byte(rtlpci->pdev, 0x719, tmp | BIT(3) | BIT(4));
> diff --git a/drivers/staging/rtlwifi/wifi.h b/drivers/staging/rtlwifi/wifi.h
> index 012fb618840b..a45f0eb69d3f 100644
> --- a/drivers/staging/rtlwifi/wifi.h
> +++ b/drivers/staging/rtlwifi/wifi.h
> @@ -88,6 +88,7 @@
>  #define RTL_USB_MAX_RX_COUNT                   100
>  #define QBSS_LOAD_SIZE                         5
>  #define MAX_WMMELE_LENGTH                      64
> +#define ASPM_L1_LATENCY                                7
>
>  #define TOTAL_CAM_ENTRY                                32
>
>
> ---
> PK
>

Re: [BUG] staging: r8822be: RTL8822be can't find any wireless AP

[Dan Carpenter]

On Thu, Jul 05, 2018 at 05:26:28PM +0800, Jian-Hong Pan wrote:
> 2018-07-05 15:36 GMT+08:00 Pkshih <pkshih@realtek.com>:
> > On Wed, 2018-07-04 at 10:33 -0500, Daniel Drake wrote:
> >> On Wed, Jul 4, 2018 at 10:13 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> >> > We will have to agree to disagree.
> >> >
> >> > I have no idea what the vendors are doing that cause some motherboards to
> >> > need a different aspm value. What I do know is that we have had to live with
> >> > the idiocy of some vendors saving a few pennies by only including a single
> >> > antenna, rather than two, and then making a problem by miscoding the EFUSE
> >> > bit that indicates which connector is actually in use. As we have no means
> >> > that I know about to detect which boxes have the problem, a module parameter
> >> > was created, just as in this case.
> >> >
> >> > I agree that drivers should work "out of the box", but finite resources and
> >> > lack of vendor cooperation make this a goal that may not be attainable.
> >>
> >> As you touched on, the ideal situation is that Realtek solve the
> >> issue. Ping-Ke Shih is on CC and I am adding a few more contacts from
> >> the commit log. The context is that the r8822 driver fails on several
> >> platforms unless setting aspm=0 (the default is 1).
> >
> > It's hard to have all laptop or motherboards and all rtl8822be modules in my side,
> > so what I can do is to analyze the issue when user encountered.
> >
> >>
> >> https://gist.github.com/dsd/20c05f0c6d66ee2ef9bfbb17f93f18ba
> >> https://bugzilla.kernel.org/show_bug.cgi?id=199651
> >>
> >>
> >> If we don't get a timely fix from Realtek though, I think there is a
> >> key difference between the antenna selection headache and this one. In
> >> the antenna case, there isn't a good value that you can set that will
> >> work on all systems. If you change the default behaviour you will
> >> solve the issue for some users while simultanously introducing the
> >> problem on other systems that were previously fine.
> >>
> >> However in this case, it's highly likely that setting aspm=0 (off) by
> >> default would work for everyone. It has the disadvantage of using a
> >> bit more power, but especially with the indications that this issue
> >> affects a significant number of systems, I think that having the
> >> driver working out of the box everywhere is more important. The module
> >> parameter can be left in place so that unaffected users that want to
> >> save power can set aspm=1.
> >>
> >
> > I think this issue may be due to L1 latency, so below patch would be
> > helpful but not sure because I don't have the same laptop.
> > Is there anyone can help to test?
> 
> I do not know why I cannot apply this patch directly.  So, I apply
> each line manually.
> 
> However, here is a good news.  I tested this fix, and it works
> correctly on ASUS X530UN.  System can scan and get the access points
> list.  Finally, it also connects to the access point.
> Maybe, you can have a formal patch for this.
>

That's good news.  What does the "dmesg | grep r8822be" say now?

regards,
dan carpenter

Re: [BUG] staging: r8822be: RTL8822be can't find any wireless AP

[Jian-Hong Pan]

2018-07-05 17:32 GMT+08:00 Dan Carpenter <dan.carpenter@oracle.com>:
> On Thu, Jul 05, 2018 at 05:26:28PM +0800, Jian-Hong Pan wrote:
>> 2018-07-05 15:36 GMT+08:00 Pkshih <pkshih@realtek.com>:
>> > On Wed, 2018-07-04 at 10:33 -0500, Daniel Drake wrote:
>> >> On Wed, Jul 4, 2018 at 10:13 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> >> > We will have to agree to disagree.
>> >> >
>> >> > I have no idea what the vendors are doing that cause some motherboards to
>> >> > need a different aspm value. What I do know is that we have had to live with
>> >> > the idiocy of some vendors saving a few pennies by only including a single
>> >> > antenna, rather than two, and then making a problem by miscoding the EFUSE
>> >> > bit that indicates which connector is actually in use. As we have no means
>> >> > that I know about to detect which boxes have the problem, a module parameter
>> >> > was created, just as in this case.
>> >> >
>> >> > I agree that drivers should work "out of the box", but finite resources and
>> >> > lack of vendor cooperation make this a goal that may not be attainable.
>> >>
>> >> As you touched on, the ideal situation is that Realtek solve the
>> >> issue. Ping-Ke Shih is on CC and I am adding a few more contacts from
>> >> the commit log. The context is that the r8822 driver fails on several
>> >> platforms unless setting aspm=0 (the default is 1).
>> >
>> > It's hard to have all laptop or motherboards and all rtl8822be modules in my side,
>> > so what I can do is to analyze the issue when user encountered.
>> >
>> >>
>> >> https://gist.github.com/dsd/20c05f0c6d66ee2ef9bfbb17f93f18ba
>> >> https://bugzilla.kernel.org/show_bug.cgi?id=199651
>> >>
>> >>
>> >> If we don't get a timely fix from Realtek though, I think there is a
>> >> key difference between the antenna selection headache and this one. In
>> >> the antenna case, there isn't a good value that you can set that will
>> >> work on all systems. If you change the default behaviour you will
>> >> solve the issue for some users while simultanously introducing the
>> >> problem on other systems that were previously fine.
>> >>
>> >> However in this case, it's highly likely that setting aspm=0 (off) by
>> >> default would work for everyone. It has the disadvantage of using a
>> >> bit more power, but especially with the indications that this issue
>> >> affects a significant number of systems, I think that having the
>> >> driver working out of the box everywhere is more important. The module
>> >> parameter can be left in place so that unaffected users that want to
>> >> save power can set aspm=1.
>> >>
>> >
>> > I think this issue may be due to L1 latency, so below patch would be
>> > helpful but not sure because I don't have the same laptop.
>> > Is there anyone can help to test?
>>
>> I do not know why I cannot apply this patch directly.  So, I apply
>> each line manually.
>>
>> However, here is a good news.  I tested this fix, and it works
>> correctly on ASUS X530UN.  System can scan and get the access points
>> list.  Finally, it also connects to the access point.
>> Maybe, you can have a formal patch for this.
>>
>
> That's good news.  What does the "dmesg | grep r8822be" say now?

dev@endless:~/linux-eos$ dmesg | grep r8822be
[    8.538404] r8822be: module is from the staging directory, the
quality is unknown, you have been warned.
[    8.541706] r8822be 0000:02:00.0: enabling device (0000 -> 0003)
[    8.571568] r8822be: Using firmware rtlwifi/rtl8822befw.bin
[    8.572370] r8822be: rtlwifi: wireless switch is on
[    8.573338] r8822be 0000:02:00.0 wlp2s0: renamed from wlan0
[   11.346560] Modules linked in: nouveau(+) snd_hda_codec_hdmi
snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel mxm_wmi
snd_hda_codec r8822be(C) x86_pkg_temp_thermal snd_hwdep snd_hda_core
efivarfs i915

The warning message comes from nouveau.  That is no matter.

Here is the full dmesg
https://gist.github.com/starnight/29b1ead5659868fcfb7f172e51a96535#file-gistfile1-txt

Regards,
Jian-Hong Pan

Re: [BUG] staging: r8822be: RTL8822be can't find any wireless AP

[Larry Finger]

On 07/05/2018 02:36 AM, Pkshih wrote:
> On Wed, 2018-07-04 at 10:33 -0500, Daniel Drake wrote:
>> On Wed, Jul 4, 2018 at 10:13 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>>> We will have to agree to disagree.
>>>
>>> I have no idea what the vendors are doing that cause some motherboards to
>>> need a different aspm value. What I do know is that we have had to live with
>>> the idiocy of some vendors saving a few pennies by only including a single
>>> antenna, rather than two, and then making a problem by miscoding the EFUSE
>>> bit that indicates which connector is actually in use. As we have no means
>>> that I know about to detect which boxes have the problem, a module parameter
>>> was created, just as in this case.
>>>
>>> I agree that drivers should work "out of the box", but finite resources and
>>> lack of vendor cooperation make this a goal that may not be attainable.
>>
>> As you touched on, the ideal situation is that Realtek solve the
>> issue. Ping-Ke Shih is on CC and I am adding a few more contacts from
>> the commit log. The context is that the r8822 driver fails on several
>> platforms unless setting aspm=0 (the default is 1).
> 
> It's hard to have all laptop or motherboards and all rtl8822be modules in my side,
> so what I can do is to analyze the issue when user encountered.
> 
>>
>> https://gist.github.com/dsd/20c05f0c6d66ee2ef9bfbb17f93f18ba
>> https://bugzilla.kernel.org/show_bug.cgi?id=199651
>>
>>
>> If we don't get a timely fix from Realtek though, I think there is a
>> key difference between the antenna selection headache and this one. In
>> the antenna case, there isn't a good value that you can set that will
>> work on all systems. If you change the default behaviour you will
>> solve the issue for some users while simultanously introducing the
>> problem on other systems that were previously fine.
>>
>> However in this case, it's highly likely that setting aspm=0 (off) by
>> default would work for everyone. It has the disadvantage of using a
>> bit more power, but especially with the indications that this issue
>> affects a significant number of systems, I think that having the
>> driver working out of the box everywhere is more important. The module
>> parameter can be left in place so that unaffected users that want to
>> save power can set aspm=1.
>>
> 
> I think this issue may be due to L1 latency, so below patch would be
> helpful but not sure because I don't have the same laptop.
> Is there anyone can help to test?
> 
> 
> diff --git a/drivers/staging/rtlwifi/rtl8822be/hw.c b/drivers/staging/rtlwifi/rtl8822be/hw.c
> index 7947edb239a1..88ba5b2fea6a 100644
> --- a/drivers/staging/rtlwifi/rtl8822be/hw.c
> +++ b/drivers/staging/rtlwifi/rtl8822be/hw.c
> @@ -803,7 +803,7 @@ static void _rtl8822be_enable_aspm_back_door(struct ieee80211_hw *hw)
>   		return;
>   
>   	pci_read_config_byte(rtlpci->pdev, 0x70f, &tmp);
> -	pci_write_config_byte(rtlpci->pdev, 0x70f, tmp | BIT(7));
> +	pci_write_config_byte(rtlpci->pdev, 0x70f, tmp | ASPM_L1_LATENCY << 3);

This patch loses the BIT(7). Did you really mean to do that?

I now agree that this is a bug. A similar problem had been found in a few boxes 
with RTL8723BE or RTL8821AE cards, but that it might apply here completely 
slipped through the ever larger cracks in my mind.

Larry

Re: [BUG] staging: r8822be: RTL8822be can't find any wireless AP

[Pkshih]

T24gVGh1LCAyMDE4LTA3LTA1IGF0IDEyOjA2IC0wNTAwLCBMYXJyeSBGaW5nZXIgd3JvdGU6DQo+
IE9uIDA3LzA1LzIwMTggMDI6MzYgQU0sIFBrc2hpaCB3cm90ZToNCj4gPiBPbiBXZWQsIDIwMTgt
MDctMDQgYXQgMTA6MzMgLTA1MDAsIERhbmllbCBEcmFrZSB3cm90ZToNCj4gPj4gT24gV2VkLCBK
dWwgNCwgMjAxOCBhdCAxMDoxMyBBTSwgTGFycnkgRmluZ2VyIDxMYXJyeS5GaW5nZXJAbHdmaW5n
ZXIubmV0PiB3cm90ZToNCj4gPj4+IFdlIHdpbGwgaGF2ZSB0byBhZ3JlZSB0byBkaXNhZ3JlZS4N
Cj4gPj4+DQo+ID4+PiBJIGhhdmUgbm8gaWRlYSB3aGF0IHRoZSB2ZW5kb3JzIGFyZSBkb2luZyB0
aGF0IGNhdXNlIHNvbWUgbW90aGVyYm9hcmRzIHRvDQo+ID4+PiBuZWVkIGEgZGlmZmVyZW50IGFz
cG0gdmFsdWUuIFdoYXQgSSBkbyBrbm93IGlzIHRoYXQgd2UgaGF2ZSBoYWQgdG8gbGl2ZSB3aXRo
DQo+ID4+PiB0aGUgaWRpb2N5IG9mIHNvbWUgdmVuZG9ycyBzYXZpbmcgYSBmZXcgcGVubmllcyBi
eSBvbmx5IGluY2x1ZGluZyBhIHNpbmdsZQ0KPiA+Pj4gYW50ZW5uYSwgcmF0aGVyIHRoYW4gdHdv
LCBhbmQgdGhlbiBtYWtpbmcgYSBwcm9ibGVtIGJ5IG1pc2NvZGluZyB0aGUgRUZVU0UNCj4gPj4+
IGJpdCB0aGF0IGluZGljYXRlcyB3aGljaCBjb25uZWN0b3IgaXMgYWN0dWFsbHkgaW4gdXNlLiBB
cyB3ZSBoYXZlIG5vIG1lYW5zDQo+ID4+PiB0aGF0IEkga25vdyBhYm91dCB0byBkZXRlY3Qgd2hp
Y2ggYm94ZXMgaGF2ZSB0aGUgcHJvYmxlbSwgYSBtb2R1bGUgcGFyYW1ldGVyDQo+ID4+PiB3YXMg
Y3JlYXRlZCwganVzdCBhcyBpbiB0aGlzIGNhc2UuDQo+ID4+Pg0KPiA+Pj4gSSBhZ3JlZSB0aGF0
IGRyaXZlcnMgc2hvdWxkIHdvcmsgIm91dCBvZiB0aGUgYm94IiwgYnV0IGZpbml0ZSByZXNvdXJj
ZXMgYW5kDQo+ID4+PiBsYWNrIG9mIHZlbmRvciBjb29wZXJhdGlvbiBtYWtlIHRoaXMgYSBnb2Fs
IHRoYXQgbWF5IG5vdCBiZSBhdHRhaW5hYmxlLg0KPiA+Pg0KPiA+PiBBcyB5b3UgdG91Y2hlZCBv
biwgdGhlIGlkZWFsIHNpdHVhdGlvbiBpcyB0aGF0IFJlYWx0ZWsgc29sdmUgdGhlDQo+ID4+IGlz
c3VlLiBQaW5nLUtlIFNoaWggaXMgb24gQ0MgYW5kIEkgYW0gYWRkaW5nIGEgZmV3IG1vcmUgY29u
dGFjdHMgZnJvbQ0KPiA+PiB0aGUgY29tbWl0IGxvZy4gVGhlIGNvbnRleHQgaXMgdGhhdCB0aGUg
cjg4MjIgZHJpdmVyIGZhaWxzIG9uIHNldmVyYWwNCj4gPj4gcGxhdGZvcm1zIHVubGVzcyBzZXR0
aW5nIGFzcG09MCAodGhlIGRlZmF1bHQgaXMgMSkuDQo+ID7CoA0KPiA+IEl0J3MgaGFyZCB0byBo
YXZlIGFsbCBsYXB0b3Agb3IgbW90aGVyYm9hcmRzIGFuZCBhbGwgcnRsODgyMmJlIG1vZHVsZXMg
aW4gbXkgc2lkZSwNCj4gPiBzbyB3aGF0IEkgY2FuIGRvIGlzIHRvIGFuYWx5emUgdGhlIGlzc3Vl
IHdoZW4gdXNlciBlbmNvdW50ZXJlZC4NCj4gPsKgDQo+ID4+DQo+ID4+IGh0dHBzOi8vZ2lzdC5n
aXRodWIuY29tL2RzZC8yMGMwNWYwYzZkNjZlZTJlZjliZmJiMTdmOTNmMThiYQ0KPiA+PiBodHRw
czovL2J1Z3ppbGxhLmtlcm5lbC5vcmcvc2hvd19idWcuY2dpP2lkPTE5OTY1MQ0KPiA+Pg0KPiA+
Pg0KPiA+PiBJZiB3ZSBkb24ndCBnZXQgYSB0aW1lbHkgZml4IGZyb20gUmVhbHRlayB0aG91Z2gs
IEkgdGhpbmsgdGhlcmUgaXMgYQ0KPiA+PiBrZXkgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBhbnRl
bm5hIHNlbGVjdGlvbiBoZWFkYWNoZSBhbmQgdGhpcyBvbmUuIEluDQo+ID4+IHRoZSBhbnRlbm5h
IGNhc2UsIHRoZXJlIGlzbid0IGEgZ29vZCB2YWx1ZSB0aGF0IHlvdSBjYW4gc2V0IHRoYXQgd2ls
bA0KPiA+PiB3b3JrIG9uIGFsbCBzeXN0ZW1zLiBJZiB5b3UgY2hhbmdlIHRoZSBkZWZhdWx0IGJl
aGF2aW91ciB5b3Ugd2lsbA0KPiA+PiBzb2x2ZSB0aGUgaXNzdWUgZm9yIHNvbWUgdXNlcnMgd2hp
bGUgc2ltdWx0YW5vdXNseSBpbnRyb2R1Y2luZyB0aGUNCj4gPj4gcHJvYmxlbSBvbiBvdGhlciBz
eXN0ZW1zIHRoYXQgd2VyZSBwcmV2aW91c2x5IGZpbmUuDQo+ID4+DQo+ID4+IEhvd2V2ZXIgaW4g
dGhpcyBjYXNlLCBpdCdzIGhpZ2hseSBsaWtlbHkgdGhhdCBzZXR0aW5nIGFzcG09MCAob2ZmKSBi
eQ0KPiA+PiBkZWZhdWx0IHdvdWxkIHdvcmsgZm9yIGV2ZXJ5b25lLiBJdCBoYXMgdGhlIGRpc2Fk
dmFudGFnZSBvZiB1c2luZyBhDQo+ID4+IGJpdCBtb3JlIHBvd2VyLCBidXQgZXNwZWNpYWxseSB3
aXRoIHRoZSBpbmRpY2F0aW9ucyB0aGF0IHRoaXMgaXNzdWUNCj4gPj4gYWZmZWN0cyBhIHNpZ25p
ZmljYW50IG51bWJlciBvZiBzeXN0ZW1zLCBJIHRoaW5rIHRoYXQgaGF2aW5nIHRoZQ0KPiA+PiBk
cml2ZXIgd29ya2luZyBvdXQgb2YgdGhlIGJveCBldmVyeXdoZXJlIGlzIG1vcmUgaW1wb3J0YW50
LiBUaGUgbW9kdWxlDQo+ID4+IHBhcmFtZXRlciBjYW4gYmUgbGVmdCBpbiBwbGFjZSBzbyB0aGF0
IHVuYWZmZWN0ZWQgdXNlcnMgdGhhdCB3YW50IHRvDQo+ID4+IHNhdmUgcG93ZXIgY2FuIHNldCBh
c3BtPTEuDQo+ID4+DQo+ID7CoA0KPiA+IEkgdGhpbmsgdGhpcyBpc3N1ZSBtYXkgYmUgZHVlIHRv
IEwxIGxhdGVuY3ksIHNvIGJlbG93IHBhdGNoIHdvdWxkIGJlDQo+ID4gaGVscGZ1bCBidXQgbm90
IHN1cmUgYmVjYXVzZSBJIGRvbid0IGhhdmUgdGhlIHNhbWUgbGFwdG9wLg0KPiA+IElzIHRoZXJl
IGFueW9uZSBjYW4gaGVscCB0byB0ZXN0Pw0KPiA+wqANCj4gPsKgDQo+ID4gZGlmZiAtLWdpdCBh
L2RyaXZlcnMvc3RhZ2luZy9ydGx3aWZpL3J0bDg4MjJiZS9ody5jIGIvZHJpdmVycy9zdGFnaW5n
L3J0bHdpZmkvcnRsODgyMmJlL2h3LmMNCj4gPiBpbmRleCA3OTQ3ZWRiMjM5YTEuLjg4YmE1YjJm
ZWE2YSAxMDA2NDQNCj4gPiAtLS0gYS9kcml2ZXJzL3N0YWdpbmcvcnRsd2lmaS9ydGw4ODIyYmUv
aHcuYw0KPiA+ICsrKyBiL2RyaXZlcnMvc3RhZ2luZy9ydGx3aWZpL3J0bDg4MjJiZS9ody5jDQo+
ID4gQEAgLTgwMyw3ICs4MDMsNyBAQCBzdGF0aWMgdm9pZCBfcnRsODgyMmJlX2VuYWJsZV9hc3Bt
X2JhY2tfZG9vcihzdHJ1Y3QgaWVlZTgwMjExX2h3ICpodykNCj4gPsKgwqDCoAkJcmV0dXJuOw0K
PiA+wqDCoMKgDQo+ID7CoMKgwqAJcGNpX3JlYWRfY29uZmlnX2J5dGUocnRscGNpLT5wZGV2LCAw
eDcwZiwgJnRtcCk7DQo+ID4gLQlwY2lfd3JpdGVfY29uZmlnX2J5dGUocnRscGNpLT5wZGV2LCAw
eDcwZiwgdG1wIHwgQklUKDcpKTsNCj4gPiArCXBjaV93cml0ZV9jb25maWdfYnl0ZShydGxwY2kt
PnBkZXYsIDB4NzBmLCB0bXAgfCBBU1BNX0wxX0xBVEVOQ1kgPDwgMyk7DQo+IA0KPiBUaGlzIHBh
dGNoIGxvc2VzIHRoZSBCSVQoNykuIERpZCB5b3UgcmVhbGx5IG1lYW4gdG8gZG8gdGhhdD8NCj4g
DQo+IEkgbm93IGFncmVlIHRoYXQgdGhpcyBpcyBhIGJ1Zy4gQSBzaW1pbGFyIHByb2JsZW0gaGFk
IGJlZW4gZm91bmQgaW4gYSBmZXcgYm94ZXPCoA0KPiB3aXRoIFJUTDg3MjNCRSBvciBSVEw4ODIx
QUUgY2FyZHMsIGJ1dCB0aGF0IGl0IG1pZ2h0IGFwcGx5IGhlcmUgY29tcGxldGVsecKgDQo+IHNs
aXBwZWQgdGhyb3VnaCB0aGUgZXZlciBsYXJnZXIgY3JhY2tzIGluIG15IG1pbmQuDQo+IA0KDQpZ
ZXMsIEkgcmVtb3ZlIEJJVCg3KSBpbnRlbnRpb25hbGx5LCBiZWNhdXNlIHRoaXMgaXMgZGVmaW5l
ZCBhcyByZXNlcnZlZCBiaXQgaW4gcnRsODgyMmJlLg0KRm9yIHRoZSBvbGRlciBjaGlwcywgSSBu
ZWVkIHRvIGNoZWNrIHdpdGggbXkgY29sbGVhZ3Vlcy4NCg0KUmVnYXJkcywNClBLDQo=

Re: [BUG] staging: r8822be: RTL8822be can't find any wireless AP

[Pkshih]

On Thu, 2018-07-05 at 12:06 -0500, Larry Finger wrote:
> On 07/05/2018 02:36 AM, Pkshih wrote:
> > On Wed, 2018-07-04 at 10:33 -0500, Daniel Drake wrote:
> >> On Wed, Jul 4, 2018 at 10:13 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> >>> We will have to agree to disagree.
> >>>
> >>> I have no idea what the vendors are doing that cause some motherboards to
> >>> need a different aspm value. What I do know is that we have had to live with
> >>> the idiocy of some vendors saving a few pennies by only including a single
> >>> antenna, rather than two, and then making a problem by miscoding the EFUSE
> >>> bit that indicates which connector is actually in use. As we have no means
> >>> that I know about to detect which boxes have the problem, a module parameter
> >>> was created, just as in this case.
> >>>
> >>> I agree that drivers should work "out of the box", but finite resources and
> >>> lack of vendor cooperation make this a goal that may not be attainable.
> >>
> >> As you touched on, the ideal situation is that Realtek solve the
> >> issue. Ping-Ke Shih is on CC and I am adding a few more contacts from
> >> the commit log. The context is that the r8822 driver fails on several
> >> platforms unless setting aspm=0 (the default is 1).
> > 
> > It's hard to have all laptop or motherboards and all rtl8822be modules in my side,
> > so what I can do is to analyze the issue when user encountered.
> > 
> >>
> >> https://gist.github.com/dsd/20c05f0c6d66ee2ef9bfbb17f93f18ba
> >> https://bugzilla.kernel.org/show_bug.cgi?id=199651
> >>
> >>
> >> If we don't get a timely fix from Realtek though, I think there is a
> >> key difference between the antenna selection headache and this one. In
> >> the antenna case, there isn't a good value that you can set that will
> >> work on all systems. If you change the default behaviour you will
> >> solve the issue for some users while simultanously introducing the
> >> problem on other systems that were previously fine.
> >>
> >> However in this case, it's highly likely that setting aspm=0 (off) by
> >> default would work for everyone. It has the disadvantage of using a
> >> bit more power, but especially with the indications that this issue
> >> affects a significant number of systems, I think that having the
> >> driver working out of the box everywhere is more important. The module
> >> parameter can be left in place so that unaffected users that want to
> >> save power can set aspm=1.
> >>
> > 
> > I think this issue may be due to L1 latency, so below patch would be
> > helpful but not sure because I don't have the same laptop.
> > Is there anyone can help to test?
> > 
> > 
> > diff --git a/drivers/staging/rtlwifi/rtl8822be/hw.c b/drivers/staging/rtlwifi/rtl8822be/hw.c
> > index 7947edb239a1..88ba5b2fea6a 100644
> > --- a/drivers/staging/rtlwifi/rtl8822be/hw.c
> > +++ b/drivers/staging/rtlwifi/rtl8822be/hw.c
> > @@ -803,7 +803,7 @@ static void _rtl8822be_enable_aspm_back_door(struct ieee80211_hw *hw)
> >   		return;
> >   
> >   	pci_read_config_byte(rtlpci->pdev, 0x70f, &tmp);
> > -	pci_write_config_byte(rtlpci->pdev, 0x70f, tmp | BIT(7));
> > +	pci_write_config_byte(rtlpci->pdev, 0x70f, tmp | ASPM_L1_LATENCY << 3);
> 
> This patch loses the BIT(7). Did you really mean to do that?
> 
> I now agree that this is a bug. A similar problem had been found in a few boxes 
> with RTL8723BE or RTL8821AE cards, but that it might apply here completely 
> slipped through the ever larger cracks in my mind.
> 

Yes, I remove BIT(7) intentionally, because this is defined as reserved bit in rtl8822be.
For the older chips, I need to check with my colleagues.

Regards,
PK