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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxx> 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
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel




[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux