Re: rtlwifi/rtl8192cu AP mode broken with PS STA

[Larry Finger]

On 4/18/21 7:32 PM, Pkshih wrote:



-Original Message-
From: Maciej S. Szmigiero [mailto:m...@maciej.szmigiero.name]
Sent: Sunday, April 18, 2021 2:08 AM
To: Pkshih
Cc: linux-wirel...@vger.kernel.org; netdev@vger.kernel.org; 
linux-ker...@vger.kernel.org;
johan...@sipsolutions.net; kv...@codeaurora.org; Larry Finger
Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA

On 08.04.2021 21:04, Maciej S. Szmigiero wrote:

On 08.04.2021 06:42, Pkshih wrote:

-Original Message-
From: Maciej S. Szmigiero [mailto:m...@maciej.szmigiero.name]
Sent: Thursday, April 08, 2021 4:53 AM
To: Larry Finger; Pkshih
Cc: linux-wirel...@vger.kernel.org; netdev@vger.kernel.org; 
linux-ker...@vger.kernel.org;
johan...@sipsolutions.net; kv...@codeaurora.org
Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA


(...)

Maceij,

Does this patch fix the problem?


The beacon seems to be updating now and STAs no longer get stuck in PS
mode.
Although sometimes (every 2-3 minutes with continuous 1s interval pings)
there is around 5s delay in updating the transmitted beacon - don't know
why, maybe the NIC hardware still has the old version in queue?


Since USB device doesn't update every beacon, dtim_count isn't updated neither.
It leads STA doesn't awake properly. Please try to fix dtim_period=1 in
hostapd.conf, which tells STA awakes every beacon interval.


The situation is the same with dtim_period=1.


(...)

Ping-Ke,
are you going to submit your set_tim() patch so at least the AP mode is
usable with PS STAs or are you waiting for a solution to the delayed
beacon update issue?



I'm still trying to get a 8192cu, and then I can reproduce the symptom you
met. However, I'm busy now; maybe I have free time two weeks later.

Do you think I submit the set_tim() patch with your Reported-by and Tested-by 
first?


PK,

I would say yes. Get the fix in as soon as possible.

Larry

Re: rtlwifi/rtl8192cu AP mode broken with PS STA

[Larry Finger]

On 4/6/21 9:48 PM, Pkshih wrote:

On Tue, 2021-04-06 at 11:25 -0500, Larry Finger wrote:

On 4/6/21 7:06 AM, Maciej S. Szmigiero wrote:

On 06.04.2021 12:00, Kalle Valo wrote:

"Maciej S. Szmigiero"  writes:


On 29.03.2021 00:54, Maciej S. Szmigiero wrote:

Hi,

It looks like rtlwifi/rtl8192cu AP mode is broken when a STA is using PS,
since the driver does not update its beacon to account for TIM changes,
so a station that is sleeping will never learn that it has packets
buffered at the AP.

Looking at the code, the rtl8192cu driver implements neither the set_tim()
callback, nor does it explicitly update beacon data periodically, so it
has no way to learn that it had changed.

This results in the AP mode being virtually unusable with STAs that do
PS and don't allow for it to be disabled (IoT devices, mobile phones,
etc.).

I think the easiest fix here would be to implement set_tim() for example
the way rt2x00 driver does: queue a work or schedule a tasklet to update
the beacon data on the device.


Are there any plans to fix this?
The driver is listed as maintained by Ping-Ke.


Yeah, power save is hard and I'm not surprised that there are drivers
with broken power save mode support. If there's no fix available we
should stop supporting AP mode in the driver.

  
https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/api

clearly documents that "For AP mode, it must (...) react to the set_tim()
callback or fetch each beacon from mac80211".
  
The driver isn't doing either so no wonder the beacon it is sending

isn't getting updated.
  
As I have said above, it seems to me that all that needs to be done here

is to queue a work in a set_tim() callback, then call
send_beacon_frame() from rtlwifi/core.c from this work.
  
But I don't know the exact device semantics, maybe it needs some other

notification that the beacon has changed, too, or even tries to
manage the TIM bitmap by itself.
  
It would be a shame to lose the AP mode for such minor thing, though.
  
I would play with this myself, but unfortunately I don't have time

to work on this right now.
  
That's where my question to Realtek comes: are there plans to actually

fix this?


Yes, I am working on this. My only question is "if you are such an expert on the
problem, why do you not fix it?"

The example in rx200 is not particularly useful, and I have not found any other
examples.



Hi Larry,

I have a draft patch that forks a work to do send_beacon_frame(), whose
behavior like Maciej mentioned.
I did test on RTL8821AE; it works well. But, it seems already work well even
I don't apply this patch, and I'm still digging why.

I don't have a rtl8192cu dongle on hand, but I'll try to find one.


Maceij,

Does this patch fix the problem?

Larry

Re: rtlwifi/rtl8192cu AP mode broken with PS STA

[Larry Finger]

On 4/6/21 7:06 AM, Maciej S. Szmigiero wrote:

On 06.04.2021 12:00, Kalle Valo wrote:

"Maciej S. Szmigiero"  writes:


On 29.03.2021 00:54, Maciej S. Szmigiero wrote:

Hi,

It looks like rtlwifi/rtl8192cu AP mode is broken when a STA is using PS,
since the driver does not update its beacon to account for TIM changes,
so a station that is sleeping will never learn that it has packets
buffered at the AP.

Looking at the code, the rtl8192cu driver implements neither the set_tim()
callback, nor does it explicitly update beacon data periodically, so it
has no way to learn that it had changed.

This results in the AP mode being virtually unusable with STAs that do
PS and don't allow for it to be disabled (IoT devices, mobile phones,
etc.).

I think the easiest fix here would be to implement set_tim() for example
the way rt2x00 driver does: queue a work or schedule a tasklet to update
the beacon data on the device.


Are there any plans to fix this?
The driver is listed as maintained by Ping-Ke.


Yeah, power save is hard and I'm not surprised that there are drivers
with broken power save mode support. If there's no fix available we
should stop supporting AP mode in the driver.



https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/api
clearly documents that "For AP mode, it must (...) react to the set_tim()
callback or fetch each beacon from mac80211".

The driver isn't doing either so no wonder the beacon it is sending
isn't getting updated.

As I have said above, it seems to me that all that needs to be done here
is to queue a work in a set_tim() callback, then call
send_beacon_frame() from rtlwifi/core.c from this work.

But I don't know the exact device semantics, maybe it needs some other
notification that the beacon has changed, too, or even tries to
manage the TIM bitmap by itself.

It would be a shame to lose the AP mode for such minor thing, though.

I would play with this myself, but unfortunately I don't have time
to work on this right now.

That's where my question to Realtek comes: are there plans to actually
fix this?


Yes, I am working on this. My only question is "if you are such an expert on the 
problem, why do you not fix it?"


The example in rx200 is not particularly useful, and I have not found any other 
examples.


Larry

Re: [PATCH] rtlwifi: Simplify locking of a skb list accesses

[Larry Finger]

On 4/5/21 2:57 AM, Christophe JAILLET wrote:

The 'c2hcmd_lock' spinlock is only used to protect some __skb_queue_tail()
and __skb_dequeue() calls.
Use the lock provided in the skb itself and call skb_queue_tail() and
skb_dequeue(). These functions already include the correct locking.

Signed-off-by: Christophe JAILLET 
---
  drivers/net/wireless/realtek/rtlwifi/base.c | 15 ++-
  drivers/net/wireless/realtek/rtlwifi/wifi.h |  1 -
  2 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c 
b/drivers/net/wireless/realtek/rtlwifi/base.c
index 6e8bd99e8911..2a7ee90a3f54 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -551,7 +551,6 @@ int rtl_init_core(struct ieee80211_hw *hw)
spin_lock_init(&rtlpriv->locks.rf_lock);
spin_lock_init(&rtlpriv->locks.waitq_lock);
spin_lock_init(&rtlpriv->locks.entry_list_lock);
-   spin_lock_init(&rtlpriv->locks.c2hcmd_lock);
spin_lock_init(&rtlpriv->locks.scan_list_lock);
spin_lock_init(&rtlpriv->locks.cck_and_rw_pagea_lock);
spin_lock_init(&rtlpriv->locks.fw_ps_lock);
@@ -2269,7 +2268,6 @@ static bool rtl_c2h_fast_cmd(struct ieee80211_hw *hw, 
struct sk_buff *skb)
  void rtl_c2hcmd_enqueue(struct ieee80211_hw *hw, struct sk_buff *skb)
  {
struct rtl_priv *rtlpriv = rtl_priv(hw);
-   unsigned long flags;
  
  	if (rtl_c2h_fast_cmd(hw, skb)) {

rtl_c2h_content_parsing(hw, skb);
@@ -2278,11 +2276,7 @@ void rtl_c2hcmd_enqueue(struct ieee80211_hw *hw, struct 
sk_buff *skb)
}
  
  	/* enqueue */

-   spin_lock_irqsave(&rtlpriv->locks.c2hcmd_lock, flags);
-
-   __skb_queue_tail(&rtlpriv->c2hcmd_queue, skb);
-
-   spin_unlock_irqrestore(&rtlpriv->locks.c2hcmd_lock, flags);
+   skb_queue_tail(&rtlpriv->c2hcmd_queue, skb);
  
  	/* wake up wq */

queue_delayed_work(rtlpriv->works.rtl_wq, &rtlpriv->works.c2hcmd_wq, 0);
@@ -2340,16 +2334,11 @@ void rtl_c2hcmd_launcher(struct ieee80211_hw *hw, int 
exec)
  {
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct sk_buff *skb;
-   unsigned long flags;
int i;
  
  	for (i = 0; i < 200; i++) {

/* dequeue a task */
-   spin_lock_irqsave(&rtlpriv->locks.c2hcmd_lock, flags);
-
-   skb = __skb_dequeue(&rtlpriv->c2hcmd_queue);
-
-   spin_unlock_irqrestore(&rtlpriv->locks.c2hcmd_lock, flags);
+   skb = skb_dequeue(&rtlpriv->c2hcmd_queue);
  
  		/* do it */

if (!skb)
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h 
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 9119144bb5a3..877ed6a1589f 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -2450,7 +2450,6 @@ struct rtl_locks {
spinlock_t waitq_lock;
spinlock_t entry_list_lock;
spinlock_t usb_lock;
-   spinlock_t c2hcmd_lock;
spinlock_t scan_list_lock; /* lock for the scan list */
  
  	/*FW clock change */




Acked-by: Larry Finger 

Thanks,

Larry

Re: [PATCH] b43: N-PHY: Fix the update of coef for the PHY revision >= 3case

[Larry Finger]

On 2/15/21 6:05 AM, Colin King wrote:

From: Colin Ian King 

The documentation for the PHY update [1] states:

Loop 4 times with index i

 If PHY Revision >= 3
 Copy table[i] to coef[i]
 Otherwise
 Set coef[i] to 0

the copy of the table to coef is currently implemented the wrong way
around, table is being updated from uninitialized values in coeff.
Fix this by swapping the assignment around.

[1] https://bcm-v4.sipsolutions.net/802.11/PHY/N/RestoreCal/

Fixes: 2f258b74d13c ("b43: N-PHY: implement restoring general configuration")
Addresses-Coverity: ("Uninitialized scalar variable")
Signed-off-by: Colin Ian King 
---
  drivers/net/wireless/broadcom/b43/phy_n.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c 
b/drivers/net/wireless/broadcom/b43/phy_n.c
index b669dff24b6e..665b737fbb0d 100644
--- a/drivers/net/wireless/broadcom/b43/phy_n.c
+++ b/drivers/net/wireless/broadcom/b43/phy_n.c
@@ -5311,7 +5311,7 @@ static void b43_nphy_restore_cal(struct b43_wldev *dev)
  
  	for (i = 0; i < 4; i++) {

if (dev->phy.rev >= 3)
-   table[i] = coef[i];
+   coef[i] = table[i];
else
coef[i] = 0;
    }



Acked-by: Larry Finger 

Good catch, thanks.

Larry

Re: [PATCH] rtw88: 8821c: Add RFE 2 support

[Larry Finger]

On 2/2/21 12:29 AM, Kalle Valo wrote:

Kai-Heng Feng  writes:


On Wed, Aug 5, 2020 at 7:24 PM Kai-Heng Feng
 wrote:


Hi Tony,


On Aug 5, 2020, at 19:18, Tony Chuang  wrote:


8821CE with RFE 2 isn't supported:
[   12.404834] rtw_8821ce :02:00.0: rfe 2 isn't supported
[   12.404937] rtw_8821ce :02:00.0: failed to setup chip efuse info
[   12.404939] rtw_8821ce :02:00.0: failed to setup chip information



NACK

The RFE type 2 should be working with some additional fixes.
Did you tested connecting to AP with BT paired?


No, I only tested WiFi.


The antenna configuration is different with RFE type 0.
I will ask someone else to fix them.
Then the RFE type 2 modules can be supported.


Good to know that, I'll be patient and wait for a real fix.


It's been quite some time, is support for RFE type 2 ready now?


It looks like this patch should add it:

https://patchwork.kernel.org/project/linux-wireless/patch/20210202055012.8296-4-pks...@realtek.com/

New firmware (rtw8821c_fw.bin) is also needed. That is available at 
https://github.com/lwfinger/rtw88.git.


Larry

Re: [PATCH] drivers: net: wireless: rtlwifi: fix bool comparison in expressions

[Larry Finger]

On 1/8/21 9:32 AM, Aditya Srivastava wrote:

There are certain conditional expressions in rtlwifi, where a boolean
variable is compared with true/false, in forms such as (foo == true) or
(false != bar), which does not comply with checkpatch.pl (CHECK:
BOOL_COMPARISON), according to which boolean variables should be
themselves used in the condition, rather than comparing with true/false

E.g., in drivers/net/wireless/realtek/rtlwifi/ps.c,
"if (find_p2p_ie == true)" can be replaced with "if (find_p2p_ie)"

Replace all such expressions with the bool variables appropriately

Signed-off-by: Aditya Srivastava
---
- The changes made are compile tested
- Applies perfecly on next-20210108

  drivers/net/wireless/realtek/rtlwifi/ps.c | 4 ++--
  drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c   | 8 
  drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c   | 4 ++--
  drivers/net/wireless/realtek/rtlwifi/rtl8192c/dm_common.c | 4 ++--
  drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c   | 4 ++--
  drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c  | 8 
  6 files changed, 16 insertions(+), 16 deletions(-)


As has been stated several times, this form of the subject is incorrect. It 
should be: "rtlwifi: : 


I would prefer that there be separate patches for each driver, not that the 
changes be lumped into a single patch as was done here. Such organization makes 
it a lot easier to find the patches for a given driver in case something goes 
wrong.Note: The driver for ps is rtl_pci, and that for rtl8192c is 
rtl8192c-common. The other driver names match their directory.


Larry

Re: [PATCH] drivers: net: wireless: realtek: Fix the word association defautly de-faulty

[Larry Finger]

On 1/5/21 5:55 AM, Joe Perches wrote:

On Tue, 2021-01-05 at 17:11 +0530, Bhaskar Chowdhury wrote:

On 22:24 Tue 05 Jan 2021, Julian Calaby wrote:

Hi Bhaskar,

[]

and your change is just making this comment worse.

really??? Not sure about it.


I agree with Julian.  I'm fairly sure it's worse.
The change you suggest doesn't parse well and is extremely odd.
If you _really_ want to just change this use (and the others),
I repeat his suggestion of "by default".


I agree with Julian and Joe. Your suggested change makes it worse!

To match ALL previous commits/patches for these drivers, the subject should be 
"rtlwifi: : Fix description of usage of own bit in descriptor"


For all drivers, that comment should be written as:
/* By default, a beacon packet will only use the first
 * descriptor and the own bit may not be cleared by the hardware
 */

Larry

Re: [PATCH v2 1/4] rtlwifi: rtl8188ee: avoid accessing the data mapped to streaming DMA

[Larry Finger]

On 11/17/20 7:53 PM, Jia-Ju Bai wrote:

In rtl88ee_tx_fill_cmddesc(), skb->data is mapped to streaming DMA on
line 677:
   dma_addr_t mapping = dma_map_single(..., skb->data, ...);

On line 680, skb->data is assigned to hdr after cast:
   struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)(skb->data);

Then hdr->frame_control is accessed on line 681:
   __le16 fc = hdr->frame_control;

This DMA access may cause data inconsistency between CPU and hardwre.

To fix this bug, hdr->frame_control is accessed before the DMA mapping.

Signed-off-by: Jia-Ju Bai 
---
  drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)


What changed between v1 and v2?

As outlined in Documentation/process/submitting-patches.rst, you should add a 
'---' marker and descrive what was changed. I usually summarize the changes, but 
it is also possible to provide a diffstat of the changes as the above file shows.


Larry



diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
index b9775eec4c54..c948dafa0c80 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
@@ -674,12 +674,12 @@ void rtl88ee_tx_fill_cmddesc(struct ieee80211_hw *hw,
u8 fw_queue = QSLT_BEACON;
__le32 *pdesc = (__le32 *)pdesc8;
  
-	dma_addr_t mapping = dma_map_single(&rtlpci->pdev->dev, skb->data,

-   skb->len, DMA_TO_DEVICE);
-
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)(skb->data);
__le16 fc = hdr->frame_control;
  
+	dma_addr_t mapping = dma_map_single(&rtlpci->pdev->dev, skb->data,

+   skb->len, DMA_TO_DEVICE);
+
if (dma_mapping_error(&rtlpci->pdev->dev, mapping)) {
rtl_dbg(rtlpriv, COMP_SEND, DBG_TRACE,
"DMA mapping error\n");

Re: [PATCH 05/41] rtl8192cu: trx: Demote clear abuse of kernel-doc format

[Larry Finger]

On 11/2/20 5:23 AM, Lee Jones wrote:

Fixes the following W=1 kernel build warning(s):

  drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:455: warning: Function 
parameter or member 'txdesc' not described in '_rtl_tx_desc_checksum'

Cc: Ping-Ke Shih 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: Larry Finger 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
  drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c
index 1ad0cf37f60bb..87f959d5d861d 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c
@@ -448,7 +448,7 @@ static void _rtl_fill_usb_tx_desc(__le32 *txdesc)
set_tx_desc_first_seg(txdesc, 1);
  }
  
-/**

+/*
   *For HW recovery information
   */
  static void _rtl_tx_desc_checksum(__le32 *txdesc)



Did you check this patch with checkpatch.pl? I think you substituted one warning 
for another. The wireless-testing trees previously did not accept a bare "/*", 
which is why "/**" was present.


This particular instance should have
/* For HW recovery information */
as the comment.

Larry

Re: [PATCH -next 7/9] rtlwifi: rtl8192ce: fix comparison to bool warning in hw.c

[Larry Finger]

On 9/18/20 5:25 AM, Zheng Bin wrote:

Fixes coccicheck warning:

drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c:616:14-20: WARNING: 
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c:621:13-19: WARNING: 
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c:626:14-20: WARNING: 
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c:631:13-19: WARNING: 
Comparison to bool

Signed-off-by: Zheng Bin 
---
  drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)


Acked-by: Larry Finger 

Larry



diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
index d4cd186036fd..bb5a0c4aec93 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
@@ -613,22 +613,22 @@ static bool _rtl92ce_llt_table_init(struct ieee80211_hw 
*hw)

for (i = 0; i < (txpktbuf_bndy - 1); i++) {
status = _rtl92ce_llt_write(hw, i, i + 1);
-   if (true != status)
+   if (!status)
return status;
}

status = _rtl92ce_llt_write(hw, (txpktbuf_bndy - 1), 0xFF);
-   if (true != status)
+   if (!status)
return status;

for (i = txpktbuf_bndy; i < maxpage; i++) {
status = _rtl92ce_llt_write(hw, i, (i + 1));
-   if (true != status)
+   if (!status)
return status;
}

status = _rtl92ce_llt_write(hw, maxpage, txpktbuf_bndy);
-   if (true != status)
+   if (!status)
return status;

return true;
--
2.26.0.106.g9fadedd

Re: [PATCH -next 8/9] rtlwifi: rtl8192de: fix comparison to bool warning in hw.c

[Larry Finger]

On 9/18/20 5:25 AM, Zheng Bin wrote:

Fixes coccicheck warning:

drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c:566:14-20: WARNING: 
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c:572:13-19: WARNING: 
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c:581:14-20: WARNING: 
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c:587:13-19: WARNING: 
Comparison to bool

Signed-off-by: Zheng Bin 
---
  drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)


Acked-by: Larry Finger 

Larry



diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c
index 2deadc7339ce..f849291cc587 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c
@@ -563,13 +563,13 @@ static bool _rtl92de_llt_table_init(struct ieee80211_hw 
*hw)
/* 18.  LLT_table_init(Adapter);  */
for (i = 0; i < (txpktbuf_bndy - 1); i++) {
status = _rtl92de_llt_write(hw, i, i + 1);
-   if (true != status)
+   if (!status)
return status;
}

/* end of list */
status = _rtl92de_llt_write(hw, (txpktbuf_bndy - 1), 0xFF);
-   if (true != status)
+   if (!status)
return status;

/* Make the other pages as ring buffer */
@@ -578,13 +578,13 @@ static bool _rtl92de_llt_table_init(struct ieee80211_hw 
*hw)
/* Otherwise used as local loopback buffer.  */
for (i = txpktbuf_bndy; i < maxpage; i++) {
status = _rtl92de_llt_write(hw, i, (i + 1));
-   if (true != status)
+   if (!status)
return status;
}

/* Let last entry point to the start entry of ring buffer */
status = _rtl92de_llt_write(hw, maxpage, txpktbuf_bndy);
-   if (true != status)
+   if (!status)
return status;

return true;
--
2.26.0.106.g9fadedd

Re: [PATCH -next 9/9] rtlwifi: rtl8723be: fix comparison to bool warning in hw.c

[Larry Finger]

On 9/18/20 5:25 AM, Zheng Bin wrote:

Fixes coccicheck warning:

drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c:861:6-35: WARNING: 
Comparison to bool

Signed-off-by: Zheng Bin 
---
  drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Acked-by: Larry Finger 

Larry



diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
index 3c7ba8214daf..0748aedce2ad 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
@@ -858,7 +858,7 @@ static bool _rtl8723be_init_mac(struct ieee80211_hw *hw)
rtl_write_word(rtlpriv, REG_CR, 0x2ff);

if (!rtlhal->mac_func_enable) {
-   if (_rtl8723be_llt_table_init(hw) == false)
+   if (!_rtl8723be_llt_table_init(hw))
return false;
}

--
2.26.0.106.g9fadedd

Re: [PATCH -next 4/9] rtlwifi: rtl8821ae: fix comparison to bool warning in hw.c

[Larry Finger]

On 9/18/20 5:25 AM, Zheng Bin wrote:

Fixes coccicheck warning:

drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c:1897:5-13: WARNING: 
Comparison to bool

Signed-off-by: Zheng Bin 
---
  drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Acked-by: Larry Finger 

Larry



diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
index b2e5b9fda669..33ffc24d3675 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
@@ -1894,7 +1894,7 @@ int rtl8821ae_hw_init(struct ieee80211_hw *hw)
}

rtstatus = _rtl8821ae_init_mac(hw);
-   if (rtstatus != true) {
+   if (!rtstatus) {
pr_err("Init MAC failed\n");
err = 1;
return err;
--
2.26.0.106.g9fadedd

Re: [PATCH -next 6/9] rtlwifi: rtl8192cu: fix comparison to bool warning in hw.c

[Larry Finger]

On 9/18/20 5:25 AM, Zheng Bin wrote:

Fixes coccicheck warning:

drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c:831:14-49: WARNING: 
Comparison to bool

Signed-off-by: Zheng Bin 
---
  drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Acked-by: Larry Finger 

Larry



diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
index 3061bd81f39e..6312fddd9c00 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
@@ -828,7 +828,7 @@ static int _rtl92cu_init_mac(struct ieee80211_hw *hw)
? WMM_CHIP_B_TX_PAGE_BOUNDARY
: WMM_CHIP_A_TX_PAGE_BOUNDARY;
}
-   if (false == rtl92c_init_llt_table(hw, boundary)) {
+   if (!rtl92c_init_llt_table(hw, boundary)) {
pr_err("Failed to init LLT Table!\n");
return -EINVAL;
}
--
2.26.0.106.g9fadedd

Re: [PATCH -next 5/9] rtlwifi: rtl8821ae: fix comparison to bool warning in phy.c

[Larry Finger]

On 9/18/20 5:25 AM, Zheng Bin wrote:

Fixes coccicheck warning:

drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:1816:5-13: WARNING: 
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:1825:5-13: WARNING: 
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:1839:5-13: WARNING: 
Comparison to bool

Signed-off-by: Zheng Bin 
---
  drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)


Acked-by: Larry Finger 

Larry



diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
index 7832fae3d00f..38669b4d6190 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
@@ -1813,7 +1813,7 @@ static bool _rtl8821ae_phy_bb8821a_config_parafile(struct 
ieee80211_hw *hw)

rtstatus = _rtl8821ae_phy_config_bb_with_headerfile(hw,
   BASEBAND_CONFIG_PHY_REG);
-   if (rtstatus != true) {
+   if (!rtstatus) {
pr_err("Write BB Reg Fail!!\n");
return false;
}
@@ -1822,7 +1822,7 @@ static bool _rtl8821ae_phy_bb8821a_config_parafile(struct 
ieee80211_hw *hw)
rtstatus = _rtl8821ae_phy_config_bb_with_pgheaderfile(hw,
BASEBAND_CONFIG_PHY_REG);
}
-   if (rtstatus != true) {
+   if (!rtstatus) {
pr_err("BB_PG Reg Fail!!\n");
return false;
}
@@ -1836,7 +1836,7 @@ static bool _rtl8821ae_phy_bb8821a_config_parafile(struct 
ieee80211_hw *hw)
rtstatus = _rtl8821ae_phy_config_bb_with_headerfile(hw,
BASEBAND_CONFIG_AGC_TAB);

-   if (rtstatus != true) {
+   if (!rtstatus) {
pr_err("AGC Table Fail\n");
return false;
}
--
2.26.0.106.g9fadedd

Re: [PATCH -next 3/9] rtlwifi: rtl8192cu: fix comparison to bool warning in mac.c

[Larry Finger]

On 9/18/20 5:24 AM, Zheng Bin wrote:

Fixes coccicheck warning:

drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c:161:14-17: WARNING: 
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c:168:13-16: WARNING: 
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c:179:14-17: WARNING: 
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c:186:13-16: WARNING: 
Comparison to bool

Signed-off-by: Zheng Bin 
---
  drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)



Acked-by: Larry Finger 

Larry


diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c
index d7afb6a186df..2890a495a23e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c
@@ -158,14 +158,14 @@ bool rtl92c_init_llt_table(struct ieee80211_hw *hw, u32 
boundary)

for (i = 0; i < (boundary - 1); i++) {
rst = rtl92c_llt_write(hw, i , i + 1);
-   if (true != rst) {
+   if (!rst) {
pr_err("===> %s #1 fail\n", __func__);
return rst;
}
}
/* end of list */
rst = rtl92c_llt_write(hw, (boundary - 1), 0xFF);
-   if (true != rst) {
+   if (!rst) {
pr_err("===> %s #2 fail\n", __func__);
return rst;
}
@@ -176,14 +176,14 @@ bool rtl92c_init_llt_table(struct ieee80211_hw *hw, u32 
boundary)
 */
for (i = boundary; i < LLT_LAST_ENTRY_OF_TX_PKT_BUFFER; i++) {
rst = rtl92c_llt_write(hw, i, (i + 1));
-   if (true != rst) {
+   if (!rst) {
pr_err("===> %s #3 fail\n", __func__);
return rst;
}
}
/* Let last entry point to the start entry of ring buffer */
rst = rtl92c_llt_write(hw, LLT_LAST_ENTRY_OF_TX_PKT_BUFFER, boundary);
-   if (true != rst) {
+   if (!rst) {
pr_err("===> %s #4 fail\n", __func__);
return rst;
}
--
2.26.0.106.g9fadedd

Re: [PATCH -next 2/9] rtlwifi: rtl8192c: fix comparison to bool warning in phy_common.c

[Larry Finger]

On 9/18/20 5:24 AM, Zheng Bin wrote:

Fixes coccicheck warning:

drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c:1106:14-18: WARNING: 
Comparison to bool

Signed-off-by: Zheng Bin 
---
  drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Acked-by: Larry Finger 

Larry



diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
index fc6c81291cf5..6a3deca404b9 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/phy_common.c
@@ -1103,7 +1103,7 @@ static void _rtl92c_phy_path_adda_on(struct ieee80211_hw 
*hw,
u32 i;

pathon = is_patha_on ? 0x04db25a4 : 0x0b1b25a4;
-   if (false == is2t) {
+   if (!is2t) {
pathon = 0x0bdb25a0;
rtl_set_bbreg(hw, addareg[0], MASKDWORD, 0x0b1b25a0);
} else {
--
2.26.0.106.g9fadedd

Re: [PATCH] rtlwifi: switch from 'pci_' to 'dma_' API

[Larry Finger]

On 8/20/20 9:46 AM, Christophe JAILLET wrote:

The wrappers in include/linux/pci-dma-compat.h should go away.

The patch has been generated with the coccinelle script below and has been
hand modified to replace GFP_ with a correct flag.
It has been compile tested.

The only file where some GFP_ flags are updated is 'pci.c'.

When memory is allocated in '_rtl_pci_init_tx_ring()' and
'_rtl_pci_init_rx_ring()' GFP_KERNEL can be used because both functions are
called from a probe function and no spinlock is taken.

The call chain is:
   rtl_pci_probe
 --> rtl_pci_init
   --> _rtl_pci_init_trx_ring
 --> _rtl_pci_init_rx_ring
 --> _rtl_pci_init_tx_ring


@@
@@
-PCI_DMA_BIDIRECTIONAL
+DMA_BIDIRECTIONAL

@@
@@
-PCI_DMA_TODEVICE
+DMA_TO_DEVICE

@@
@@
-PCI_DMA_FROMDEVICE
+DMA_FROM_DEVICE

@@
@@
-PCI_DMA_NONE
+DMA_NONE

@@
expression e1, e2, e3;
@@
-pci_alloc_consistent(e1, e2, e3)
+dma_alloc_coherent(&e1->dev, e2, e3, GFP_)

@@
expression e1, e2, e3;
@@
-pci_zalloc_consistent(e1, e2, e3)
+dma_alloc_coherent(&e1->dev, e2, e3, GFP_)

@@
expression e1, e2, e3, e4;
@@
-pci_free_consistent(e1, e2, e3, e4)
+dma_free_coherent(&e1->dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_map_single(e1, e2, e3, e4)
+dma_map_single(&e1->dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_unmap_single(e1, e2, e3, e4)
+dma_unmap_single(&e1->dev, e2, e3, e4)

@@
expression e1, e2, e3, e4, e5;
@@
-pci_map_page(e1, e2, e3, e4, e5)
+dma_map_page(&e1->dev, e2, e3, e4, e5)

@@
expression e1, e2, e3, e4;
@@
-pci_unmap_page(e1, e2, e3, e4)
+dma_unmap_page(&e1->dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_map_sg(e1, e2, e3, e4)
+dma_map_sg(&e1->dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_unmap_sg(e1, e2, e3, e4)
+dma_unmap_sg(&e1->dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_cpu(e1, e2, e3, e4)
+dma_sync_single_for_cpu(&e1->dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_device(e1, e2, e3, e4)
+dma_sync_single_for_device(&e1->dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_cpu(e1, e2, e3, e4)
+dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_device(e1, e2, e3, e4)
+dma_sync_sg_for_device(&e1->dev, e2, e3, e4)

@@
expression e1, e2;
@@
-pci_dma_mapping_error(e1, e2)
+dma_mapping_error(&e1->dev, e2)

@@
expression e1, e2;
@@
-pci_set_dma_mask(e1, e2)
+dma_set_mask(&e1->dev, e2)

@@
expression e1, e2;
@@
-pci_set_consistent_dma_mask(e1, e2)
+dma_set_coherent_mask(&e1->dev, e2)

Signed-off-by: Christophe JAILLET 
---
If needed, see post from Christoph Hellwig on the kernel-janitors ML:
https://marc.info/?l=kernel-janitors&m=158745678307186&w=4
---
  drivers/net/wireless/realtek/rtlwifi/pci.c| 116 +-
  .../wireless/realtek/rtlwifi/rtl8188ee/hw.c   |   9 +-
  .../wireless/realtek/rtlwifi/rtl8188ee/trx.c  |  13 +-
  .../wireless/realtek/rtlwifi/rtl8192ce/trx.c  |  14 +--
  .../wireless/realtek/rtlwifi/rtl8192de/trx.c  |  12 +-
  .../wireless/realtek/rtlwifi/rtl8192ee/trx.c  |  13 +-
  .../wireless/realtek/rtlwifi/rtl8192se/trx.c  |  12 +-
  .../wireless/realtek/rtlwifi/rtl8723ae/trx.c  |  14 +--
  .../wireless/realtek/rtlwifi/rtl8723be/hw.c   |   9 +-
  .../wireless/realtek/rtlwifi/rtl8723be/trx.c  |  13 +-
  .../wireless/realtek/rtlwifi/rtl8821ae/hw.c   |   9 +-
  .../wireless/realtek/rtlwifi/rtl8821ae/trx.c  |  13 +-
  12 files changed, 115 insertions(+), 132 deletions(-)


Tested-by: Larry Finger  for rtl8821ae.

Larry

Re: [PATCH 2/6] rtlwifi: Remove unnecessary parenthese in rtl_dbg uses

[Larry Finger]

On 7/27/20 9:52 AM, Joe Perches wrote:

On Mon, 2020-07-27 at 09:04 +, Pkshih wrote:

So, I think you would like to have parenthesis intentionally.
If so,
test1 ? : (test2 ? :)
would be better.


If not,
test1 ? : test2 ? :
may be what you want (without any parenthesis).


Use whatever style you like, it's unimportant to me
and it's not worth spending any real time on it.


If you are so busy, why did you jump in with patches that you knew I was already 
working on? You knew because you critiqued my first submission.


@Kalle: Please drop my contributions in the sequence "PATCH v2 00/15] rtlwifi: 
Change RT_TRACE into rtl_dbg for all drivers".


Larry

Re: [PATCH -next] net/wireless/rtl8225: Remove unused variable rtl8225z2_tx_power_ofdm

[Larry Finger]

On 5/12/20 6:14 AM, ChenTao wrote:

Fix the following warning:

drivers/net/wireless/realtek/rtl818x/rtl8187/rtl8225.c:609:17: warning:
‘rtl8225z2_tx_power_ofdm’ defined but not used
  static const u8 rtl8225z2_tx_power_ofdm[] = {

Reported-by: Hulk Robot 
Signed-off-by: ChenTao 


The patch is OK, but the subject is wrong. It should be "[PATCH-next] rtl8187: 
Remove "


With that change, ACKed-by: Larry Finger 

Larry

Re: [BUG] rtlwifi: a crash in error handling code of rtl_pci_probe()

[Larry Finger]

On 5/14/19 8:07 AM, Jia-Ju Bai wrote:
In rtl_pci_probe(), when request_irq() in rtl_pci_intr_mode_legacy() in 
rtl_pci_intr_mode_decide() fails, a crash occurs.

The crash information is as follows:

[  108.271155] kasan: CONFIG_KASAN_INLINE enabled
[  108.271163] kasan: GPF could be caused by NULL-ptr deref or user memory 
access
..
[  108.271193] RIP: 0010:cfg80211_get_drvinfo+0xce/0x3b0 [cfg80211]
..
[  108.271235] Call Trace:
[  108.271245]  ethtool_get_drvinfo+0x110/0x640
[  108.271255]  ? cfg80211_get_chan_state+0x7e0/0x7e0 [cfg80211]
[  108.271261]  ? ethtool_get_settings+0x340/0x340
[  108.271268]  ? __read_once_size_nocheck.constprop.7+0x20/0x20
[  108.271279]  ? kasan_check_write+0x14/0x20
[  108.271284]  dev_ethtool+0x272d/0x4c20
[  108.271290]  ? unwind_get_return_address+0x66/0xb0
[  108.271299]  ? __save_stack_trace+0x92/0x100
[  108.271307]  ? ethtool_get_rxnfc+0x3f0/0x3f0
[  108.271316]  ? save_stack+0xa3/0xd0
[  108.271323]  ? save_stack+0x43/0xd0
[  108.271331]  ? ftrace_graph_ret_addr+0x2d/0x170
[  108.271338]  ? ftrace_graph_ret_addr+0x2d/0x170
[  108.271346]  ? ftrace_graph_ret_addr+0x2d/0x170
[  108.271354]  ? update_stack_state+0x3b2/0x670
[  108.271361]  ? update_stack_state+0x3b2/0x670
[  108.271370]  ? __read_once_size_nocheck.constprop.7+0x20/0x20
[  108.271379]  ? unwind_next_frame.part.5+0x19f/0xa60
[  108.271388]  ? bpf_prog_kallsyms_find+0x3e/0x270
[  108.271396]  ? is_bpf_text_address+0x1a/0x30
[  108.271408]  ? kernel_text_address+0x11d/0x130
[  108.271416]  ? __kernel_text_address+0x12/0x40
[  108.271423]  ? unwind_get_return_address+0x66/0xb0
[  108.271431]  ? __save_stack_trace+0x92/0x100
[  108.271440]  ? save_stack+0xa3/0xd0
[  108.271448]  ? udp_ioctl+0x35/0xe0
[  108.271457]  ? inet_ioctl+0x100/0x320
[  108.271466]  ? inet_stream_connect+0xb0/0xb0
[  108.271475]  ? alloc_file+0x60/0x480
[  108.271483]  ? alloc_file_pseudo+0x19d/0x270
[  108.271495]  ? sock_alloc_file+0x51/0x170
[  108.271502]  ? __sys_socket+0x12c/0x1f0
[  108.271510]  ? __x64_sys_socket+0x78/0xb0
[  108.271520]  ? do_syscall_64+0xb1/0x2e0
[  108.271529]  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  108.271538]  ? kasan_check_read+0x11/0x20
[  108.271548]  ? mutex_lock+0x8f/0xe0
[  108.271557]  ? __mutex_lock_slowpath+0x20/0x20
[  108.271568]  dev_ioctl+0x1fb/0xae0
[  108.271576]  ? dev_ioctl+0x1fb/0xae0
[  108.271586]  ? _copy_from_user+0x71/0xd0
[  108.271594]  sock_do_ioctl+0x1e2/0x2f0
[  108.271602]  ? kmem_cache_alloc+0xf9/0x250
[  108.271611]  ? ___sys_recvmsg+0x5a0/0x5a0
[  108.271621]  ? apparmor_file_alloc_security+0x128/0x7e0
[  108.271630]  ? kasan_unpoison_shadow+0x35/0x50
[  108.271638]  ? kasan_kmalloc+0xad/0xe0
[  108.271652]  ? apparmor_file_alloc_security+0x128/0x7e0
[  108.271662]  ? apparmor_file_alloc_security+0x269/0x7e0
[  108.271670]  sock_ioctl+0x361/0x590
[  108.271678]  ? sock_ioctl+0x361/0x590
[  108.271686]  ? routing_ioctl+0x470/0x470
[  108.271695]  ? kasan_check_write+0x14/0x20
[  108.271703]  ? __mutex_init+0xba/0x130
[  108.271713]  ? percpu_counter_add_batch+0xc7/0x120
[  108.271722]  ? alloc_empty_file+0xae/0x150
[  108.271729]  ? routing_ioctl+0x470/0x470
[  108.271738]  do_vfs_ioctl+0x1ae/0xfe0
[  108.271745]  ? do_vfs_ioctl+0x1ae/0xfe0
[  108.271754]  ? alloc_file_pseudo+0x1ad/0x270
[  108.271762]  ? ioctl_preallocate+0x1e0/0x1e0
[  108.271770]  ? alloc_file+0x480/0x480
[  108.271778]  ? kasan_check_read+0x11/0x20
[  108.271786]  ? __fget+0x24d/0x320
[  108.271794]  ? iterate_fd+0x180/0x180
[  108.271802]  ? fd_install+0x52/0x60
[  108.271812]  ? security_file_ioctl+0x8c/0xb0
[  108.271820]  ksys_ioctl+0x99/0xb0
[  108.271829]  __x64_sys_ioctl+0x78/0xb0
[  108.271839]  do_syscall_64+0xb1/0x2e0
[  108.271857]  ? prepare_exit_to_usermode+0xc8/0x160
[  108.271871]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
..

I checked the driver source code, but cannot find the reason, so I only report 
the crash...

Can somebody give an explanation about this crash?

This crash is triggered by a runtime fuzzing tool named FIZZER written by us.


Your backtrace does not include any references to rtlwifi routines, and I have 
no idea what FIZZER does, thus it is not possible for me to debug this. If the 
error situation that you state happens, the code should end up at label "fail3" 
in routine rtl_pci_probe(). Insert printk statements after every line of the 
following, and report the last good point before the error. It is certainly 
possible that something is being torn down that was never erected. The 
likelihood of failure of both MSI and legacy interrupts is not very likely, and 
we probably have never hit those conditions.


fail3:
pci_set_drvdata(pdev, NULL);
rtl_deinit_core(hw);

fail2:
if (rtlpriv->io.pci_mem_start != 0)
pci_iounmap(pdev, (void __iomem *)rtlpriv->io.pci_mem_start);

pci_release_regions(pdev);
complete(&rtlpriv->firmware_loading_complete);

fail1:
if (hw)
ieee80211

Re: Realtek r8822be kernel module does not negotiate 802.11ac connection

[Larry Finger]

On 3/2/19 12:09 PM, David R. Bergstein wrote:

Larry,

I tried using iw but it gives the same reading for bit rate.  In regard
to the firmware, it was not installed via "make install" so I did it
manually.


David,

There was a typo in the Makefile. 'make install' now installs the firmware 
correctly.


Larry

Re: Realtek r8822be kernel module does not negotiate 802.11ac connection

[Larry Finger]

On 3/1/19 9:52 PM, David R. Bergstein wrote:

Larry,

Sorry about all these extra replies.  Shortly after I sent my last
message my access point started recognizing the connection as 802.11ac
with PHY Rate / Modulation Rate of 866.6 Mbps.  What is somewhat
misleading is the information reported by iwconfig (see bit rate below).

$ iwconfig wlo1
wlo1  IEEE 802.11  ESSID:"XX-5G"
   Mode:Managed  Frequency:5.22 GHz  Access Point:
xx:xx:xx:xx:xx:xx
   Bit Rate=6.5 Mb/s   Tx-Power=23 dBm
   Retry short limit:7   RTS thr:off   Fragment thr:off
   Power Management:on
   Link Quality=70/70  Signal level=-40 dBm
   Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
   Tx excessive retries:0  Invalid misc:11   Missed beacon:0


The utility iwconfig is obsolete and not exactly up to date with the latest in 
wireless. I am not an expert on iw, but I think you want 'iw dev wlo1 link'.


I am wondering about the missing firmware stage. Had you not done the 'sudo make 
install' step, or did that step fail to install the firmware?


Larry

Re: Realtek r8822be kernel module does not negotiate 802.11ac connection

[Larry Finger]

On 3/1/19 4:26 PM, David R. Bergstein wrote:

Larry,

Thanks for the response and detailed instructions, which allowed me to
build and install the rtw88 kernel module.  I cannot however seem to get
my system to actually use the module.  Just to recap this is an HP Omen
laptop with secure boot disabled.  Upon boot-up both the new rtw88 and
old r8822be modules are loaded.  If I unload the r8822be module the wifi
network connection gets terminated, even if I unload/reload the rtw88
module.

Is there something else I should be doing prior to invoking rtw88, e.g.,
blacklisting the old module?


Yes, r8822be must be blacklisted. Use the lsmod command to see what modules are 
actually loaded. You load/unload rtw88 using the rtwpci module.


Larry

Re: Realtek r8822be kernel module does not negotiate 802.11ac connection

[Larry Finger]

On 2/28/19 8:32 PM, David R. Bergstein wrote:

Tony,

Thanks for your response.  Can you advise as to the availability of the
new rtw88 driver?  As it appears to be under development, I could not
locate a copy of the code for local compilation.


David,

Use the command 'git clone http://github.com/lwfinger/rtlwifi_new.git -b rtw88' 
to get a copy of the new driver for RTL8822BE and RTL8822CE in a stand-alone 
form. All that is needed is 'cd rtlwifi_new && make && sudo make install'. This 
version will build on kernels v4.4 and newer. As I have time, I will be 
backporting to kernels at least as old as 4.0.


I would appreciate your comments and bug reports.

Larry

[PATCH] rtl_bt: Update firmware for BT part of RTL8822C

[Larry Finger]

The file was sent to me by Max Chou .

Signed-off-by: Larry Finger 
Cc: Max Chou 
---
 WHENCE  |   2 ++
 rtl_bt/rtl8822cu_fw.bin | Bin 22412 -> 41588 bytes
 2 files changed, 2 insertions(+)

diff --git a/WHENCE b/WHENCE
index 853990b..351b312 100644
--- a/WHENCE
+++ b/WHENCE
@@ -3254,6 +3254,8 @@ Files rtl_bt/rtl8822b_* came directly from Realtek. These 
files are
 updated on April 14, 2017.
 Files rtl_bt/rtl8821c_* and rtl_bt/rtl8723d_* came directly from Realtek.
 File rtl_bt/rtl8822cu_fw.bin came directly from Realtek.
+updated on February 24, 2019
+File rtl_bt/rtl8822cu_fw.bin came directly from Realtek.
 
 --
 
diff --git a/rtl_bt/rtl8822cu_fw.bin b/rtl_bt/rtl8822cu_fw.bin
index 
558037c14cb51243528cfb433c6ad4a829b716f7..9a43075277f8a01ab00e9d78a4e33e87d258e8a8
 100644
GIT binary patch
delta 22071
zcmb8X3tUuX{y%=s%$W-?z+nJEyp4bt5R@qhP8VJqysZ&pwRl(w(XqE
z%35sEu{5jiZyeAJ(8U?Bc7L@$0_{TTB6PLwx0F~o3_74@?e}Z^-k&p!+WvO`um2BT
z&+|E#=XuU^`FuXl=k`q9AK6PsRg2eFSfouA<(2WzKBreRETdvL#=nT0ma!z0VHo*V
zWcMRo`@34MDNFU3_oR9YayRG7AEkKBA35vTiQ7-bCkm%$d1rfs)3d#D;13OI>q=jp
zPY$f^+TK0Yar@$#!N
zM)_b5FY|Fmx&3oqUL0wZZ~c^)>!XbF6TQ6rREVkn?HQIq~cvUS5c*>_J}6
zz$Z2PcsUpFHD{J8mVME=M75HA(z{*dRIB>`=AEfcV%g`t`8tun8~Oz*_I>Bq;s3#Q
zIq!|w9`kIPxr@aNXnD2O+$ATz_U`P_{&E%Dx>A=a9b!rE*@
zv6!3vSwgp*IF`j!$cYD){3WM1^7p8BThye9FQu{41dpjZf~S&HX1t_xV^kIUyz{H5
z{AkM@rXp;YzMi?D!OY(5oEzPRPLD*tqGGGO+l
z_r@CTV@;paFlBXeN~%{l{l9Hx-6`JRo=&t0flb}X-bYR+dmlxT1H$Qb&L^g7n!Y;RCwu$A60(_>oQ$;?Ada-z%m
z+{`&)Co|m#Ht&`bPdeY3nY=bx@7d-vf2sEffi@I5nfdCTAaW5Jw78g7hT$3JPez&0
zSK~1U-d0MzG+v6Sxc*KEG}1d~)~t!Qoy=@%8b{Lcx?!Fd_E7tOY0`TzA#T5D0Apr95&nKw(Rmu?
zSeCOg?ZCXSjI0hhF*X2CuS?<2{p&;5#zlIzoA$9P_NLF>nrd97Q6@Pb0njjw5UI#be6(V
zobO~bu$c8lka{YoVVQ^Kl>_JoCO@|osW6>p-+%-
z{q!kbZk=J2qfGCbGffNw$T%OoInjX&ImPs#L=WiYY!m-{n#s(hn_6bfG40B~$;6wf
z%>406R3^)0(q@}xF*&9lN49AuU_Iarz!Jbzz;*U)QwqHYOs4mM|MIy5FQ!vPKoj5x
zfYSiC0!{^71~>(<18_2+3^)nU444GCJ2Kle5pW$~B47_-0$@Gh1i%u&c)$+;;{dk;
z#sV$_Gy*z0a1nzG8IT7w14aXWuF5t=0qzEj1Y8Gb0PF#b0IUZL2P^>$1N;C`54aUj
z2e=GS3)lgu0h9qbKr^74-m}>z6_evIb>M=f0)Pw^U@^TaS`H?F2lcDfL0AJA&Zz3+
ze_#SK;EO-xGEDz`=F3Na!K{%MGL-@oD8utBKWxx~D3t46xSq+Vvqt{5z;EAo+)AUb!!SFbS>QZ&Jda7Dd
zS9n)0ie&ZGB@EMD`?%g|x%Jo12XEDE&*buQz~FMm1%qq|2H767kEzJ^W!9%Fng%a+|>@Uw(s^8ORV<*I}oh4f$XO
z;OE%!D^cO{UPu8DD9!=~Q0d-3@^T}DiRBP5HlXZdfRoptu?CPc4?zTQ5O6M}h*P-!
z0dfWF{qdLgu#<(ijB?^Hf}4-}hW_o#WMyanymii2bDSm>g^HXXnhT?NT*V;8Ayu_I
zlk$HVe#329{x8Bt&=*ZBFPoebvntekFNT4?O?Tc@uuAv#UwHY}LY?!of-KeCKRUw;
zr>aI8z3GL5O3hrJ46b*Z+I%_I`PU^`b6seD!<)fR8OJ{t1!zE`!HzeDF7R@+bMDf|
zArHK<^tSK`c%O)bu8l73Oise(J8z*c;8M4~%E-k?Gy-aZn%{od`RVO{4!;-E7<}yA
zvur+_Kvk}{#LM@G>EtE*c<29ExWt*UVzz_9+Hpw4CBp&7Zi`Wt<-_k7WfKqcgnMgG
zhePfN_db9mAw7CJ{D#?ODz+R#*P3|wFqW$L058X2y^rB~%{#pOU*%zC`ct}|*jDpy
zwRET5>|?8A4zo4I7tAk@U76;vNf)@j&s$Iz{06
zt=1^ZNMT-Kbaw-5-R2WU*LCTr&0Ad<|
zH&@FYnzHK~?}YTIBj)`@L(wT`_lx_N?|)|hf&Jb4`EZx6$mwGcAtLm^~Y^1NF9JjW<^01rdTKu{$}
z!yKe}mE6-GsBrfOwzxY+7`yWjo5)UgzRyl^BzffSq_#;O#wMRm@?igj{5-MEd_0(h
zqt~Ge&saO<%G;w8X;M3X#JajbqEGx!=n$aqd=E$#Fs&^p&{IblC^aUa=ZV80d5|mN
zBoP`YVCpr5d>aqmLi#h(WTZ(*Q=Lz&oTEDXma}Q4l_T15ZYfG-|Kfe4=-2G@BHR-J
z_uqv%r|X3fy8w?Obs%**(^mbOH8`JJWpfaH-ORF#N%O#6&-sJcT-LZ)9Fsm>SvM56
zo)P7tg_8R8P&!Jf!i1@up8A&1T+9rHWpZ#&P~V)!^ncSjq|fh~=YbCerz%X3_*g
zJe9;+L((SA*AIVj9$8)MQ0S}2(5jM{>If8T6{N-%y25A$NVZMGHV|ZsQRs_p5Joe%Css@0*3br-*eTK-^bM~RGOijsmMQ2bdI+c
zol~a)TbFD39FM6948poFtLR*o*W7%QZ*p>`BG~KumMA=;V}z}73|%O?fC|
z<@FMKdIeQ1y0Ba%ZliaaKC&E8TP5GDbZAKp+EjDbbg%i#>B?uPdjvNty)ZO!j?g)+
zb(+Vt$Gn@mV?MW83|_G|t}oK7?bYI;aiWm_n=itVd`Hx2_*z)6Wj_KDIW>
zvcC(-c+Xn($~*lhWv%7|Xr(qw2z^0SYW^VIa=+KyFeb4p>U_BGTJP0cR4^Qr
zDqki>7&Ii@gL_tDtmY3?z~4K8za<_s5JlTt4A?)K2>bX232Xt?;DoQ3I*j>1@^QUSZ^~4Z_IbhAih@hBWpTr^7JOF(1uE`6j35
zdGfsT-|TRk0+(KQjVx|32R1Ye`|Lhad|P}ceG%#NJmw~Sx_*Z?J?uqpt~w(YHPy*;
z(9u~^GTN?gNbxY829GJQvC|aD?PP3_<+`yYHqGA1u4FOcLU#~72|1Yx;-4EFz?Bd#
z5nh%24blZ99%9vme
z*+U3&C`B`8z+l0_2%VSo3Kyp-qoqCOC;N@^1_?DZg3ub1fb%wNJT$VOkJfo4D%D~B
zGBn3T(9CF(+!lpv)!Y2sy<={eeOk^F2M&2MFCIhp!-~KVa_Y4_G>w?+dcaa94)A!j8q>
zC1_^Jc)k?Za-haVmSc%5#~qB-G_tHC-<=kt_!`vd@-&UdxQB6?J0v>
zg51GW-1s3=z~M4m?Y<|(k}gx=cP>-l*BvV5{!ZNgs^eCrVld}yi$D*$U0TQ!9GKJW
zv%FjeG4eqqvhls~70l6~xQC!Q9z>dsv<2GYVW=IC0#-roxX*!$HMm#@>F_d;v;`aN
zSuisWx@Q(d{|u;;_d@h1)iVt`Y9`dqiGY_-?@8cF8>yZ9d3iU;_Z&X36(76{AE-pV
zcc9Y*Ajeh!k{Y@lHdKb{!>&r|>s;tNj!n3T{G6BjsYeiozc>M92o3x<>8NNhQ*V^*
z=-3ng#mEcskymTYvf5!t@M)@(#o5V>Ez9#@cb12()bui7gj|nCl1HajKXoy_
zW-dxyv8Q;-F0FGLV1`X;OT!bDeX0i^ZIVYH?3PC>0Ug-!N3CvobW^8^pXx1X1|yKJ
z*lDjV`G~}*B(J7VBe_PS&}?jtzAvHGJgDu}JGoQZQ(%I46I1=oWlfEF5VdTa$I^MD
zJQcvQ-giJJZ@Jqj=Pm?G09yzLC!Tw=R*nOFBNm3eb$^CtJ;2Lzm+Iu_exa3}{7vhk
zF5&HDNJbKNqB_p`$W2odB2bw$1jeQ

Re: [PATCH] rtlwifi: rtl818x: fix indentation issue

[Larry Finger]

On 1/17/19 1:29 PM, Joe Perches wrote:

On Thu, 2019-01-17 at 15:28 +, Colin King wrote:

From: Colin Ian King 

There is a statement that is indented too deeply. Fix this.


Thanks.


diff --git a/drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c 
b/drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c

[]

@@ -803,7 +803,7 @@ static void rtl8180_config_cardbus(struct ieee80211_hw *dev)
rtl818x_iowrite16(priv, FEMR_SE, 0x);
} else {
reg16 = rtl818x_ioread16(priv, &priv->map->FEMR);
-   reg16 |= (1 << 15) | (1 << 14) | (1 << 4);
+   reg16 |= (1 << 15) | (1 << 14) | (1 << 4);
rtl818x_iowrite16(priv, &priv->map->FEMR, reg16);
}


trivia:

It sure looks as if there could be some rather useful
conversions of magic bits to constants one day.


How much work is warranted for this driver for a device that is not likely in 
use anywhere in the wild? In addition, I'm not sure anyone knows what those bits 
actually do, I certainly do not have a product sheet for that one.


Larry

Re: [PATCH v4 0/4] rtlwifi: Fix issues with rtl8723ae

[Larry Finger]

On 1/8/19 4:49 PM, Bernd Edlinger wrote:

Currently the rtl8723ae driver is broken (since v4.7).

Connection to AP is lost very often, especially when
the signal level is not very good.

The main issue is the power save mode is basically
not working, and seems to trigger a firmware bug.
So I had to take out the FW LPS mode handling.

While debugging the driver I found a couple related issues,
for instance that the signal level in dm.undec_sm_pwdb
is no longer accurate (may be even much too high) when no more
packets are received, and it increases the likelihood to receive
something if the input gain is set to maximum.

The patch was tested with the rtl8723ae PCI card in my laptop
against a FRITZ!Box 7590 AP -- the WiFi connection works now
very reliable for me.

ChangeLog:

v2: Adjusts the defaults of swlps and fwlps module
parameters to match the firmware capabilities instead of removing
the whole code, so it can be easily re-activated once a firmware
update is available.

v3: Make the title of each patch fit in one line.

v4: Try to fix the line endings the message body.
 Which is an exchange server issue.
 The patch does not change at all.

Bernd Edlinger (4):
   rtl8723ae: Take the FW LPS mode handling out
   rtl8723ae: Dont use old data for input gain control
   rtl8723ae: Re-introduce the adaptive rate control
   rtlwifi: Don't clear num_rx_inperiod too early

  drivers/net/wireless/realtek/rtlwifi/base.c|  4 +-
  drivers/net/wireless/realtek/rtlwifi/core.c|  2 +
  .../net/wireless/realtek/rtlwifi/rtl8723ae/dm.c| 95 +-
  .../net/wireless/realtek/rtlwifi/rtl8723ae/sw.c|  8 +-
  4 files changed, 101 insertions(+), 8 deletions(-)


This version applied OK.

Larry

Re: [PATCH v2 0/4] rtlwifi: Fix issues with rtl8723ae

[Larry Finger]

On 1/5/19 12:38 PM, Bernd Edlinger wrote:

Currently the rtl8723ae driver is broken (since v4.7).

Connection to AP is lost very often, especially when
the signal level is not very good.

The main issue is the power save mode is basically
not working, and seems to trigger a firmware bug.
So I had to take out the FW LPS mode handling.

While debugging the driver I found a couple related issues,
for instance that the signal level in dm.undec_sm_pwdb
is no longer accurate (may be even much too high) when no more
packets are received, and it increases the likelihood to receive
something if the input gain is set to maximum.

The patch was tested with the rtl8723ae PCI card in my laptop
against a FRITZ!Box 7590 AP -- the WiFi connection works now
very reliable for me.

V2 of the patch adjusts the defaults of swlps and fwlps module
parameters to match the firmware capabilities instead of removing
the whole code, so it can be easily re-activated once a firmware
update is available.


Bernd Edlinger (4):
   rtlwifi: rtl8723ae: Take the FW LPS mode handling out
   rtlwifi: rtl8723ae: Don't use dm.undec_sm_pwdb for input gain control
when no beacon was received in the connected state
   rtlwifi: rtl8723ae: Re-introduce
 rtl8723e_dm_refresh_rate_adaptive_mask
   rtlwifi: Move the clearing of rtlpriv->link_info.num_rx_inperiod in
  rtl_watchdog_wq_callback a few lines down


The subject on all 4 of these need to be modified. Only the first line will be 
shown as the "subject", which will not make much sense.


In addition, you need to include the changes in the cover letter, and in the 
actual patch after the --- line. In that section, you mention what changes were 
made in each revision, then follow with another --- line. That info is there for 
the maintainers - it will be stripped before the patch is merged.


Larry

Re: [PATCH 1/4] rtlwifi: rtl8723ae: Take the FW LPS mode handling out

[Larry Finger]

On 1/5/19 10:30 AM, Bernd Edlinger wrote:

On 1/5/19 5:13 PM, Larry Finger wrote:

but this works:

modprobe rtl8723ae debug_mask=0x debug_level=5 swlps=1 fwlps=0


Yes, I think that is a better thing to do now. If and when Realtek finds a 
firmware bug, and when the new firmware is readily available, then there will 
not be a lot of code to reinstall.



Okay, my assumption of how the firmware bug "works" is this:

Once the firmware enters power save mode, it will deliver exactly one (or maybe 
two)
Rx interrupts. If one of those triggers the driver to leave the power save mode 
again,
the firmware continues to work.
If those are only beacons, they won't leave the power save mode.  Then the 
firmware
will usually not recover.
Since prior to commit 873ffe154ae0 ("rtlwifi: Fix logic error in enter/exit 
power-save mode")
the power save mode was only activated when there _is_ busy traffic, the next
packet did usually wake the firmware, rarely it did freeze however.
Other things like changing the cck_packet_detection_threshold or 
refresh_rate_adaptive_mask
can also kick the firmware back to life.

Hope this helps to track down the root cause of this bug.


As I know nothing of the firmware, that is outside my expertise, but that 
observation should be of great help to PK Shih, and his colleagues at Realtek.


Larry

Re: [PATCH 1/4] rtlwifi: rtl8723ae: Take the FW LPS mode handling out

[Larry Finger]

On 1/5/19 5:31 AM, Bernd Edlinger wrote:

On 1/5/19 3:44 AM, Larry Finger wrote:

On 1/4/19 6:48 AM, Bernd Edlinger wrote:

This appears to trigger a firmware bug and causes severe
problems with rtl8723ae PCI devices.

When the power save mode is activated for longer periods
of time the firmware stops to receive any packets.

This problem was exposed by commit 873ffe154ae0 ("rtlwifi:
Fix logic error in enter/exit power-save mode").

Previously the power save mode was only active rarely and
only for a short time so that the problem was not noticeable.

Signed-off-by: Bernd Edlinger 
---


While the Realtek firmware group has a chance to look for a bug, I would like 
you to perform a couple of tests on the original code.

The driver has three module parameters that affect power save. The 'modinfo 
rtl8723ae' command lists them as

parm:   ips:Set to 0 to not use link power save (default 1) (bool)
parm:   swlps:Set to 1 to use SW control power save (default 0) (bool)
parm:   fwlps:Set to 1 to use FW control power save (default 1) (bool)

If you were to load rtl8723ae with 'ips=0', does it still fail?
If you were to load the driver with 'swlps=1 fwlps=0', does it still fail?



this does not work:

modprobe rtl8723ae debug_mask=0x debug_level=5 ips=0

tail -f /var/log/syslog|grep "AP off"
Jan  5 11:42:06 w-ed kernel: [ 7267.229713] rtlwifi: :<0> AP off for 2 s
Jan  5 11:42:08 w-ed kernel: [ 7269.276761] rtlwifi: :<0> AP off for 4 s
Jan  5 11:42:10 w-ed kernel: [ 7271.323758] rtlwifi: :<0> AP off for 6 s
Jan  5 11:42:12 w-ed kernel: [ 7273.370759] rtlwifi: :<0> AP off for 8 s
Jan  5 11:42:14 w-ed kernel: [ 7275.417753] rtlwifi: :<0> AP off for 10 s
Jan  5 11:42:14 w-ed kernel: [ 7275.417754] rtlwifi: AP off, try to reconnect 
now
Jan  5 11:42:28 w-ed kernel: [ 7289.746676] rtlwifi: :<0> AP off for 2 s
Jan  5 11:42:40 w-ed kernel: [ 7302.028327] rtlwifi: :<0> AP off for 2 s
Jan  5 11:42:43 w-ed kernel: [ 7304.075327] rtlwifi: :<0> AP off for 4 s
Jan  5 11:42:45 w-ed kernel: [ 7306.122330] rtlwifi: :<0> AP off for 6 s
Jan  5 11:42:47 w-ed kernel: [ 7308.169292] rtlwifi: :<0> AP off for 8 s
Jan  5 11:42:49 w-ed kernel: [ 7310.216236] rtlwifi: :<0> AP off for 10 s
Jan  5 11:42:49 w-ed kernel: [ 7310.216238] rtlwifi: AP off, try to reconnect 
now
Jan  5 11:43:05 w-ed kernel: [ 7326.59] rtlwifi: :<0> AP off for 2 s
Jan  5 11:43:07 w-ed kernel: [ 7328.639076] rtlwifi: :<0> AP off for 4 s
Jan  5 11:43:09 w-ed kernel: [ 7330.686220] rtlwifi: :<0> AP off for 6 s
Jan  5 11:43:11 w-ed kernel: [ 7332.733078] rtlwifi: :<0> AP off for 8 s
Jan  5 11:43:13 w-ed kernel: [ 7334.779988] rtlwifi: :<0> AP off for 10 s
Jan  5 11:43:13 w-ed kernel: [ 7334.779989] rtlwifi: AP off, try to reconnect 
now
Jan  5 11:43:28 w-ed kernel: [ 7349.108839] rtlwifi: :<0> AP off for 2 s
Jan  5 11:43:30 w-ed kernel: [ 7351.155837] rtlwifi: :<0> AP off for 4 s
Jan  5 11:43:32 w-ed kernel: [ 7353.202838] rtlwifi: :<0> AP off for 6 s
Jan  5 11:43:42 w-ed kernel: [ 7363.437779] rtlwifi: :<0> AP off for 2 s
Jan  5 11:43:46 w-ed kernel: [ 7367.531622] rtlwifi: :<0> AP off for 2 s
Jan  5 11:43:48 w-ed kernel: [ 7369.578597] rtlwifi: :<0> AP off for 4 s
Jan  5 11:43:50 w-ed kernel: [ 7371.625694] rtlwifi: :<0> AP off for 6 s
Jan  5 11:43:52 w-ed kernel: [ 7373.672691] rtlwifi: :<0> AP off for 8 s
Jan  5 11:43:54 w-ed kernel: [ 7375.719690] rtlwifi: :<0> AP off for 10 s
Jan  5 11:43:54 w-ed kernel: [ 7375.719691] rtlwifi: AP off, try to reconnect 
now
Jan  5 11:44:09 w-ed kernel: [ 7390.048406] rtlwifi: :<0> AP off for 2 s
Jan  5 11:44:11 w-ed kernel: [ 7392.095678] rtlwifi: :<0> AP off for 4 s
Jan  5 11:44:13 w-ed kernel: [ 7394.142349] rtlwifi: :<0> AP off for 6 s
Jan  5 11:44:15 w-ed kernel: [ 7396.189352] rtlwifi: :<0> AP off for 8 s
Jan  5 11:44:17 w-ed kernel: [ 7398.236352] rtlwifi: :<0> AP off for 10 s
Jan  5 11:44:17 w-ed kernel: [ 7398.236353] rtlwifi: AP off, try to reconnect 
now
Jan  5 11:44:31 w-ed kernel: [ 7412.565079] rtlwifi: :<0> AP off for 2 s
Jan  5 11:44:33 w-ed kernel: [ 7414.612167] rtlwifi: :<0> AP off for 4 s
Jan  5 11:44:35 w-ed kernel: [ 7416.659101] rtlwifi: :<0> AP off for 6 s
Jan  5 11:44:37 w-ed kernel: [ 7418.706035] rtlwifi: :<0> AP off for 8 s
Jan  5 11:44:39 w-ed kernel: [ 7420.753100] rtlwifi: :<0> AP off for 10 s
Jan  5 11:44:39 w-ed kernel: [ 7420.753101] rtlwifi: AP off, try to reconnect 
now
Jan  5 11:44:54 w-ed kernel: [ 7435.081860] rtlwifi: :<0> AP off for 2 s
Jan  5 11:44:56 w-ed kernel: [ 7437.128857] rtlwifi: :<0> AP off for 4 s
Jan  5 11:45:08 w-ed kernel: [ 7449.410653] rtlwifi: :<0> AP off for 2 s
Jan  5 11:45:10 w-ed kernel: [ 7451.457650] rtlwifi: :<0> AP off for 4 s
Jan  5 11:45:12 w-ed kernel: [ 7453.504647] rt

Re: [PATCH 1/4] rtlwifi: rtl8723ae: Take the FW LPS mode handling out

[Larry Finger]

On 1/4/19 6:48 AM, Bernd Edlinger wrote:

This appears to trigger a firmware bug and causes severe
problems with rtl8723ae PCI devices.

When the power save mode is activated for longer periods
of time the firmware stops to receive any packets.

This problem was exposed by commit 873ffe154ae0 ("rtlwifi:
Fix logic error in enter/exit power-save mode").

Previously the power save mode was only active rarely and
only for a short time so that the problem was not noticeable.

Signed-off-by: Bernd Edlinger 
---


While the Realtek firmware group has a chance to look for a bug, I would like 
you to perform a couple of tests on the original code.


The driver has three module parameters that affect power save. The 'modinfo 
rtl8723ae' command lists them as


parm:   ips:Set to 0 to not use link power save (default 1) (bool)
parm:   swlps:Set to 1 to use SW control power save (default 0) (bool)
parm:   fwlps:Set to 1 to use FW control power save (default 1) (bool)

If you were to load rtl8723ae with 'ips=0', does it still fail?
If you were to load the driver with 'swlps=1 fwlps=0', does it still fail?

Thanks for debugging this problem.

Larry

[PATCH 2/2] staging: rtl8188eu: Fix module loading from tasklet for WEP encryption

[Larry Finger]

Commit 2b2ea09e74a5 ("staging:r8188eu: Use lib80211 to decrypt WEP-frames")
causes scheduling while atomic bugs followed by a hard freeze whenever
the driver tries to connect to a WEP-encrypted network. Experimentation
showed that the freezes were eliminated when module lib80211 was
preloaded, which can be forced by calling lib80211_get_crypto_ops()
directly rather than indirectly through try_then_request_module().
With this change, no BUG messages are logged.

Fixes: 2b2ea09e74a5 ("staging:r8188eu: Use lib80211 to decrypt WEP-frames")
Cc: Stable  # v4.17+
Cc: Michael Straube 
Cc: Ivan Safonov 
Signed-off-by: Larry Finger 
---
 drivers/staging/rtl8188eu/core/rtw_security.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c 
b/drivers/staging/rtl8188eu/core/rtw_security.c
index 052656a22821..bab96c870042 100644
--- a/drivers/staging/rtl8188eu/core/rtw_security.c
+++ b/drivers/staging/rtl8188eu/core/rtw_security.c
@@ -154,7 +154,7 @@ void rtw_wep_encrypt(struct adapter *padapter, u8 
*pxmitframe)
 
pframe = ((struct xmit_frame *)pxmitframe)->buf_addr + hw_hdr_offset;
 
-   crypto_ops = try_then_request_module(lib80211_get_crypto_ops("WEP"), 
"lib80211_crypt_wep");
+   crypto_ops = lib80211_get_crypto_ops("WEP");
 
if (!crypto_ops)
return;
@@ -210,7 +210,7 @@ int rtw_wep_decrypt(struct adapter  *padapter, u8 
*precvframe)
void *crypto_private = NULL;
int status = _SUCCESS;
const int keyindex = prxattrib->key_index;
-   struct lib80211_crypto_ops *crypto_ops = 
try_then_request_module(lib80211_get_crypto_ops("WEP"), "lib80211_crypt_wep");
+   struct lib80211_crypto_ops *crypto_ops = 
lib80211_get_crypto_ops("WEP");
char iv[4], icv[4];
 
if (!crypto_ops) {
-- 
2.16.4

[PATCH 1/2] staging: rtl8188eu: Fix module loading from tasklet for CCMP encryption

[Larry Finger]

Commit 6bd082af7e36 ("staging:r8188eu: use lib80211 CCMP decrypt")
causes scheduling while atomic bugs followed by a hard freeze whenever
the driver tries to connect to a CCMP-encrypted network. Experimentation
showed that the freezes were eliminated when module lib80211 was
preloaded, which can be forced by calling lib80211_get_crypto_ops()
directly rather than indirectly through try_then_request_module().
With this change, no BUG messages are logged.

Fixes: 6bd082af7e36 ("staging:r8188eu: use lib80211 CCMP decrypt")
Cc: Stable  # v4.17+
Reported-and-tested-by: Michael Straube 
Cc: Ivan Safonov 
Signed-off-by: Larry Finger 
---
 drivers/staging/rtl8188eu/core/rtw_security.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c 
b/drivers/staging/rtl8188eu/core/rtw_security.c
index f7407632e80b..052656a22821 100644
--- a/drivers/staging/rtl8188eu/core/rtw_security.c
+++ b/drivers/staging/rtl8188eu/core/rtw_security.c
@@ -1291,7 +1291,7 @@ u32 rtw_aes_decrypt(struct adapter *padapter, u8 
*precvframe)
struct sk_buff *skb = ((struct recv_frame 
*)precvframe)->pkt;
void *crypto_private = NULL;
u8 *key, *pframe = skb->data;
-   struct lib80211_crypto_ops *crypto_ops = 
try_then_request_module(lib80211_get_crypto_ops("CCMP"), "lib80211_crypt_ccmp");
+   struct lib80211_crypto_ops *crypto_ops = 
lib80211_get_crypto_ops("CCMP");
struct security_priv *psecuritypriv = 
&padapter->securitypriv;
char iv[8], icv[8];
 
-- 
2.16.4

[PATCH 0/2] Fixes for system freezes for r8188eu

[Larry Finger]

The driver issues "scheduling while atomic" messages and will freeze the
system. These problems are due to attempting to dynamically load library
encryption routines from a tasklet. The fixes are relatively simple. All
that is needed is to replace indirect calls of the try_then_request_module()
macro with a direct call to lib80211_get_crypto_ops(), which forces a load
of the lib80211 module when the wifi driver is loaded.

There will be a similar patch for TKIP encryption; however, the faulty
patch has already been reverted, thus a fix to use the lib80211 routine
directly will be more intrusive. My original attempt failed, thus I am
delaying that fix.

Cc: Michael Straube 
Cc: Ivan Safonov 
Signed-off-by: Larry Finger 
---
Larry Finger (2):
  staging: rtl8188eu: Fix module loading from tasklet for CCMP
encryption
  staging: rtl8188eu: Fix module loading from tasklet for WEP encryption

 drivers/staging/rtl8188eu/core/rtw_security.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.16.4

[PATCH] MAINTAINERS: Add entry for staging driver r8188eu

[Larry Finger]

This entry was missed when the driver was added.

Signed-off-by: Larry Finger 
---
Greg,

Because this driver is in staging, I am sending it to you. I hope that is OK.

Larry
---
 MAINTAINERS | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f4855974f325..b02ec3b0b612 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14108,6 +14108,11 @@ M: Florian Schilhabel 
.
 S: Odd Fixes
 F: drivers/staging/rtl8712/
 
+STAGING - REALTEK RTL8188EU DRIVERS
+M: Larry Finger 
+S: Odd Fixes
+F: drivers/staging/rtl8188eu/
+
 STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER
 M: Sudip Mukherjee 
 M: Teddy Wang 
-- 
2.20.1

Re: [PATCH] rtl818x: fix potential use after free

[Larry Finger]

On 11/29/18 4:48 AM, Pan Bian wrote:

entry is released via usb_put_urb just after calling usb_submit_urb.
However, entry is used if the submission fails, resulting in a use after
free bug. The patch fixes this.

Signed-off-by: Pan Bian 
---
  drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c 
b/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
index cec3778..1a2ea8b 100644
--- a/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
+++ b/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
@@ -444,12 +444,13 @@ static int rtl8187_init_urbs(struct ieee80211_hw *dev)
skb_queue_tail(&priv->rx_queue, skb);
usb_anchor_urb(entry, &priv->anchored);
ret = usb_submit_urb(entry, GFP_KERNEL);
-   usb_put_urb(entry);
if (ret) {
skb_unlink(skb, &priv->rx_queue);
usb_unanchor_urb(entry);
+   usb_put_urb(entry);
goto err;
}
+   usb_put_urb(entry);
}
return ret;


Good catch.

ACKed-by: Larry Finger 

Thanks,
Larry

[PATCH] staging: rtl8723bs: Fix incorrect sense of ether_addr_equal

[Larry Finger]

In commit b37f9e1c3801 ("staging: rtl8723bs: Fix lines too long in
update_recvframe_attrib()."), the refactoring involved replacing
two memcmp() calls with ether_addr_equal() calls. What the author
missed is that memcmp() returns false when the two strings are equal,
whereas ether_addr_equal() returns true when the two addresses are
equal. One side effect of this error is that the strength of an
unassociated AP was much stronger than the same AP after association.
This bug is reported at bko#201611.

Fixes: b37f9e1c3801 ("staging: rtl8723bs: Fix lines too long in 
update_recvframe_attrib().")
Cc: Stable 
Cc: youling257 
Cc: u.srikant.patn...@gmail.com
Reported-and-tested-by: youling257 
Signed-off-by: Larry Finger 
---
 drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c 
b/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
index 85077947b9b8..85aba8a503cd 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723bs_recv.c
@@ -109,12 +109,12 @@ static void update_recvframe_phyinfo(union recv_frame 
*precvframe,
rx_bssid = get_hdr_bssid(wlanhdr);
pkt_info.bssid_match = ((!IsFrameTypeCtrl(wlanhdr)) &&
!pattrib->icv_err && !pattrib->crc_err &&
-   !ether_addr_equal(rx_bssid, my_bssid));
+   ether_addr_equal(rx_bssid, my_bssid));
 
rx_ra = get_ra(wlanhdr);
my_hwaddr = myid(&padapter->eeprompriv);
pkt_info.to_self = pkt_info.bssid_match &&
-   !ether_addr_equal(rx_ra, my_hwaddr);
+   ether_addr_equal(rx_ra, my_hwaddr);
 
 
pkt_info.is_beacon = pkt_info.bssid_match &&
-- 
2.19.1

[PATCH v2 2/2] staging: rtl8712u: Fix compiler warning about strncpy

[Larry Finger]

When strncpy() is called with source and destination strings the same
length, gcc 8 warns that there may be an unterminated string. Using
strlcpy() rather than strncpy() forces a null at the end and quiets the
warning.

Signed-off-by: Larry Finger 
---
v2 - No changes.
---
 drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c 
b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index c3ff7c3e6681..08e1c0957a07 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -1789,7 +1789,7 @@ static int r871x_wx_set_enc_ext(struct net_device *dev,
return -ENOMEM;
param->cmd = IEEE_CMD_SET_ENCRYPTION;
eth_broadcast_addr(param->sta_addr);
-   strncpy((char *)param->u.crypt.alg, alg_name, IEEE_CRYPT_ALG_NAME_LEN);
+   strlcpy((char *)param->u.crypt.alg, alg_name, IEEE_CRYPT_ALG_NAME_LEN);
if (pext->ext_flags & IW_ENCODE_EXT_GROUP_KEY)
param->u.crypt.set_tx = 0;
if (pext->ext_flags & IW_ENCODE_EXT_SET_TX_KEY)
-- 
2.18.0

[PATCH v2 1/2] staging: rtl8192e: Fix compiler warning from strncpy()

[Larry Finger]

When strncpy() is called with source and destination strings the same
length, gcc 8 warns that there may be an unterminated string. This section
is completely reworked to use the known lengths of the strings.

Signed-off-by: Larry Finger 
---
v2 - David Laight's comments are implemented. 
---
 drivers/staging/rtl8192e/rtllib_softmac.c | 18 ++
 drivers/staging/rtl8192e/rtllib_softmac.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c 
b/drivers/staging/rtl8192e/rtllib_softmac.c
index 919231fec09c..287d0c11fa38 100644
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -1680,19 +1680,19 @@ inline void rtllib_softmac_new_net(struct rtllib_device 
*ieee,
   (ssidbroad && !ssidset) || (!ssidbroad && ssidset))) ||
   (!apset && ssidset && ssidbroad && ssidmatch) ||
   (ieee->is_roaming && ssidset && ssidbroad && ssidmatch)) {
-   /* if the essid is hidden replace it with the
-* essid provided by the user.
+   /* Save the essid so that if it is hidden, it is
+* replaced with the essid provided by the user.
 */
if (!ssidbroad) {
-   strncpy(tmp_ssid, ieee->current_network.ssid,
-   IW_ESSID_MAX_SIZE);
+   memcpy(tmp_ssid, ieee->current_network.ssid,
+  ieee->current_network.ssid_len);
tmp_ssid_len = ieee->current_network.ssid_len;
}
-   memcpy(&ieee->current_network, net,
-  sizeof(struct rtllib_network));
+   memcpy(&ieee->current_network, net,
+  sizeof(ieee->current_network));
if (!ssidbroad) {
-   strncpy(ieee->current_network.ssid, tmp_ssid,
-   IW_ESSID_MAX_SIZE);
+   memcpy(ieee->current_network.ssid, tmp_ssid,
+  tmp_ssid_len);
ieee->current_network.ssid_len = tmp_ssid_len;
}
netdev_info(ieee->dev,
-- 
2.18.0

[PATCH v2 0/2] staging: Fix some warnings from strncpy()

[Larry Finger]

When the size argument in a call to strncpy() is the size of the
destimation, gcc8 issues a warning. These patches fix the potential
problem.

Signed-off-by: Larry Finger 

v2 - The code is changed to implement the comments of David Laight.

Larry Finger (2):
  staging: rtl8192e: Fix compiler warning about strncpy
  staging: rtl8712u: Fix compiler warning about strncpy

 drivers/staging/rtl8192e/rtllib_softmac.c | 4 ++--
 drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.18.0

[PATCH 2/2] staging: rtl8712u: Fix compiler warning about strncpy

[Larry Finger]

When strncpy() is called with source and destination strings the same
length, gcc 8 warns that there may be an unterminated string. Using
strlcpy() rather than strncpy() forces a null at the end and quiets the
warning.

Signed-off-by: Larry Finger 
---
 drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c 
b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index c3ff7c3e6681..08e1c0957a07 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -1789,7 +1789,7 @@ static int r871x_wx_set_enc_ext(struct net_device *dev,
return -ENOMEM;
param->cmd = IEEE_CMD_SET_ENCRYPTION;
eth_broadcast_addr(param->sta_addr);
-   strncpy((char *)param->u.crypt.alg, alg_name, IEEE_CRYPT_ALG_NAME_LEN);
+   strlcpy((char *)param->u.crypt.alg, alg_name, IEEE_CRYPT_ALG_NAME_LEN);
if (pext->ext_flags & IW_ENCODE_EXT_GROUP_KEY)
param->u.crypt.set_tx = 0;
if (pext->ext_flags & IW_ENCODE_EXT_SET_TX_KEY)
-- 
2.18.0

[PATCH 1/2] staging: rtl8192e: Fix compiler warning about strncpy

[Larry Finger]

When strncpy() is called with source and destination strings the same
length, gcc 8 warns that there may be an unterminated string. Using
strlcpy() rather than strncpy() forces a null at the end and quiets the
warning.

Signed-off-by: Larry Finger 
---
 drivers/staging/rtl8192e/rtllib_softmac.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c 
b/drivers/staging/rtl8192e/rtllib_softmac.c
index 919231fec09c..95a8390cb7ac 100644
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -1684,14 +1684,14 @@ inline void rtllib_softmac_new_net(struct rtllib_device 
*ieee,
 * essid provided by the user.
 */
if (!ssidbroad) {
-   strncpy(tmp_ssid, ieee->current_network.ssid,
+   strlcpy(tmp_ssid, ieee->current_network.ssid,
IW_ESSID_MAX_SIZE);
tmp_ssid_len = ieee->current_network.ssid_len;
}
memcpy(&ieee->current_network, net,
   sizeof(struct rtllib_network));
if (!ssidbroad) {
-   strncpy(ieee->current_network.ssid, tmp_ssid,
+   strlcpy(ieee->current_network.ssid, tmp_ssid,
IW_ESSID_MAX_SIZE);
ieee->current_network.ssid_len = tmp_ssid_len;
}
-- 
2.18.0

[PATCH 0/2] staging: Fix some warnings from strncpy()

[Larry Finger]

When the size argument in a call to strncpy() is the size of the
destimation, gcc8 issues a warning. These patches fix the potential
problem by replacing the strncpy() with strlcpy().

Signed-off-by: Larry Finger 


Larry Finger (2):
  staging: rtl8192e: Fix compiler warning about strncpy
  staging: rtl8712u: Fix compiler warning about strncpy

 drivers/staging/rtl8192e/rtllib_softmac.c | 4 ++--
 drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.18.0

Re: RTL8723BE performance regression

[Larry Finger]

On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:

On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger  wrote:

(...)


As the antenna selection code changes affected your first bisection, do you
have one of those HP laptops with only one antenna and the incorrect coding
in the FUSE?


Yes, that is why I've been passing ant_sel=1 during my tests -- this
was needed to achieve a good performance in the past, before this
regression. I've also opened the laptop chassis and confirmed the
antenna cable is plugged to the connector labeled with "1" on the
card.


If so, please make sure that you still have the same signal
strength for good and bad cases. I have tried to keep the driver and the
btcoex code in sync, but there may be some combinations of antenna
configuration and FUSE contents that cause the code to fail.



What is the recommended way to monitor the signal strength?


The btcoex code is developed for multiple platforms by a different group than 
the Linux driver. I think they made a change that caused ant_sel to switch from 
1 to 2. At least numerous comments at github.com/lwfinger/rtlwifi_new claimed 
they needed to make that change.


Mhy recommended method is to verify the wifi device name with "iw dev". Then 
using that device


sudo iw dev  scan | egrep "SSID|signal"

Larry

Re: RTL8723BE performance regression

[Larry Finger]

On 04/03/2018 08:51 PM, João Paulo Rechi Vita wrote:

Hello,

I've been trying to track a performance regression on the RTL8723BE
WiFi adapter, which mainly affects the upload bandwidth (although we
can see a decreased download performance as well, the effect on upload
is more drastic). This was first reported by users after upgrading
from our 4.11-based kernel to our 4.13-based kernel, but also
confirmed to affect our development branch (4.15-based kernel) and
wireless-drivers-next at the
wireless-drivers-next-for-davem-2018-03-29 tag. This is happening on
an HP laptop that needs rtl8723be.ant_sel=1 (and all the following
tests have been made with that param).

My first bisect attempt pointed me to the following commit:

bcd37f4a0831 rtlwifi: btcoex: 23b 2ant: let bt transmit when hw
initialisation done

Which I later found to be already fixed by

a33fcba6ec01 rtlwifi: btcoexist: Fix breakage of ant_sel for rtl8723be.

That fix is already included in v4.15 though (and our dev branch as
well), so I did a second bisect, now cherry-picking a33fcba6ec01 at
every step, and it pointed me to the following commit:

7937f02d1953 rtlwifi: btcoex: hook external functions for newer chips

Reverting that commit on top of our development branch fixes the
problem, but on top of v4.15 I get mixed results: a few times getting
a good upload performance (~5-6Mbps) but most of the time just getting
~1-1.5Mpbs (which is still better than the 0.0 then test failure I've
gotten on most bad points of the bisect).

Bisecting the downstream patches we carry on top of v4.15 (we base our
kernel on Ubuntu's, so there are quite a few downstream changes) did
not bring any clarity, as at all bisect points (plus reverting
7937f02d1953) the performance was good, so probably there was some
other difference in the resulting kernels from my initial revert of
that patch on top of v4.15 and each step during the bisect. I've
experimented a bit with fwlps=0, but it did not bring any conclusive
results either. I'll try to look at other things that may have changed
(configuration perhaps?), but I don't have a clear plan yet.

Have you seen anything similar, or have any other ideas or suggestions
to track this problem? Even without crystal clear results, it looks
like 7937f02d1953 is having a negative impact on the RTL8723BE
performance, so perhaps it is worth reverting it and reworking it a
later point?

This are the results (testing with speedtest.net) I got at some key points:

VersionCommitPingDownUp

v4.11a351e9b1225.445.99
v4.11a351e9b131  17.025.89

v4.13569dbb8174  14.080.00
v4.13569dbb8261  8.41  0.00

v4.15+revert d8a5b801923.861.41
v4.15+revert d8a5b80189  18.691.39



As the antenna selection code changes affected your first bisection, do you have 
one of those HP laptops with only one antenna and the incorrect coding in the 
FUSE? If so, please make sure that you still have the same signal strength for 
good and bad cases. I have tried to keep the driver and the btcoex code in sync, 
but there may be some combinations of antenna configuration and FUSE contents 
that cause the code to fail.


Larry

Re: [PATCH] rtlwifi: rtl8821ae: fix spelling mistake: "Aboslute" -> "Absolute"

[Larry Finger]

On 03/19/2018 05:40 AM, Colin King wrote:

From: Colin Ian King 

Trivial fix to spelling mistake in RT_TRACE message text.

Signed-off-by: Colin Ian King 
---
  drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)


Acked-by: Larry Finger 

Re: [RESEND PATCH] rsi: Remove stack VLA usage

[Larry Finger]

On 03/11/2018 08:43 PM, Tobin C. Harding wrote:

The kernel would like to have all stack VLA usage removed[1].  rsi uses
a VLA based on 'blksize'.  Elsewhere in the SDIO code maximum block size
is defined using a magic number.  We can use a pre-processor defined
constant and declare the array to maximum size.  We add a check before
accessing the array in case of programmer error.

[1]: https://lkml.org/lkml/2018/3/7/621

Signed-off-by: Tobin C. Harding 
---

RESEND: add wireless mailing list to CC's (requested by Kalle)

  drivers/net/wireless/rsi/rsi_91x_hal.c  | 13 +++--
  drivers/net/wireless/rsi/rsi_91x_sdio.c |  9 +++--
  2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_hal.c 
b/drivers/net/wireless/rsi/rsi_91x_hal.c
index 1176de646942..839ebdd602df 100644
--- a/drivers/net/wireless/rsi/rsi_91x_hal.c
+++ b/drivers/net/wireless/rsi/rsi_91x_hal.c
@@ -641,7 +641,7 @@ static int ping_pong_write(struct rsi_hw *adapter, u8 cmd, 
u8 *addr, u32 size)
u32 cmd_addr;
u16 cmd_resp, cmd_req;
u8 *str;
-   int status;
+   int status, ret;
  
  	if (cmd == PING_WRITE) {

cmd_addr = PING_BUFFER_ADDRESS;
@@ -655,12 +655,13 @@ static int ping_pong_write(struct rsi_hw *adapter, u8 
cmd, u8 *addr, u32 size)
str = "PONG_VALID";
}
  
-	status = hif_ops->load_data_master_write(adapter, cmd_addr, size,

+   ret = hif_ops->load_data_master_write(adapter, cmd_addr, size,
block_size, addr);
-   if (status) {
-   rsi_dbg(ERR_ZONE, "%s: Unable to write blk at addr %0x\n",
-   __func__, *addr);
-   return status;
+   if (ret) {
+   if (ret != -EINVAL)
+   rsi_dbg(ERR_ZONE, "%s: Unable to write blk at addr 
%0x\n",
+   __func__, *addr);
+   return ret;
}
  
  	status = bl_cmd(adapter, cmd_req, cmd_resp, str);

diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c 
b/drivers/net/wireless/rsi/rsi_91x_sdio.c
index b0cf41195051..b766578b591a 100644
--- a/drivers/net/wireless/rsi/rsi_91x_sdio.c
+++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c
@@ -20,6 +20,8 @@
  #include "rsi_common.h"
  #include "rsi_hal.h"
  
+#define RSI_MAX_BLOCK_SIZE 256

+
  /**
   * rsi_sdio_set_cmd52_arg() - This function prepares cmd 52 read/write arg.
   * @rw: Read/write
@@ -362,7 +364,7 @@ static int rsi_setblocklength(struct rsi_hw *adapter, u32 
length)
rsi_dbg(INIT_ZONE, "%s: Setting the block length\n", __func__);
  
  	status = sdio_set_block_size(dev->pfunction, length);

-   dev->pfunction->max_blksize = 256;
+   dev->pfunction->max_blksize = RSI_MAX_BLOCK_SIZE;
adapter->block_size = dev->pfunction->max_blksize;
  
  	rsi_dbg(INFO_ZONE,

@@ -567,9 +569,12 @@ static int rsi_sdio_load_data_master_write(struct rsi_hw 
*adapter,
  {
u32 num_blocks, offset, i;
u16 msb_address, lsb_address;
-   u8 temp_buf[block_size];
+   u8 temp_buf[RSI_MAX_BLOCK_SIZE];
int status;
  
+	if (block_size > RSI_MAX_BLOCK_SIZE)

+   return -EINVAL;
+
num_blocks = instructions_sz / block_size;
msb_address = base_address >> 16;


I am not giving this patch a negative review, but my solution to the same 
problem has been to change the on-stack array into a u8 pointer, use kmalloc() 
to assign the space, and then free that space at the end. That way large stack 
allocations are avoided, with a minimum of changes.


Larry

  

[PATCH] rtl_bt: Add firmware and configuration files for the Bluetooth parts of RTL8821C and RTL8723D

[Larry Finger]

These devices are new models from Realtek. Updates to driver btrtl will
soon be submitted to the kernel.

These files were provided by the Realtek developer.

Signed-off-by: 陆朱伟 
Signed-off-by: Larry Finger 
---
 WHENCE |   5 +
 rtl_bt/rtl8723d_config.bin | Bin 0 -> 10 bytes
 rtl_bt/rtl8723d_fw.bin | Bin 0 -> 47028 bytes
 rtl_bt/rtl8821c_config.bin | Bin 0 -> 10 bytes
 rtl_bt/rtl8821c_fw.bin | Bin 0 -> 37356 bytes
 5 files changed, 5 insertions(+)
 create mode 100644 rtl_bt/rtl8723d_config.bin
 create mode 100644 rtl_bt/rtl8723d_fw.bin
 create mode 100644 rtl_bt/rtl8821c_config.bin
 create mode 100644 rtl_bt/rtl8821c_fw.bin

diff --git a/WHENCE b/WHENCE
index 368aad1..207cbcf 100644
--- a/WHENCE
+++ b/WHENCE
@@ -3011,6 +3011,10 @@ File: rtl_bt/rtl8812ae_fw.bin
 File: rtl_bt/rtl8821a_fw.bin
 File: rtl_bt/rtl8822b_fw.bin
 File: rtl_bt/rtl8822b_config.bin
+File: rtl_bt/rtl8723d_fw.bin
+File: rtl_bt/rtl8723d_config.bin
+File: rtl_bt/rtl8821c_fw.bin
+File: rtl_bt/rtl8821c_config.bin
 
 Licence: Redistributable. See LICENCE.rtlwifi_firmware.txt for details.
 
@@ -3018,6 +3022,7 @@ Found in vendor driver, 
linux_bt_usb_2.11.20140423_8723be.rar
 From https://github.com/troy-tan/driver_store
 Files rtl_bt/rtl8822b_* came directly from Realtek. These files are
 updated on April 14, 2017.
+Files rtl_bt/rtl8821c_* and rtl_bt/rtl8723d_* came directly from Realtek.
 
 --
 
diff --git a/rtl_bt/rtl8723d_config.bin b/rtl_bt/rtl8723d_config.bin
new file mode 100644
index 
..bb15fcd4312379eb7d2ebc26ad2240dc87031faf
GIT binary patch
literal 10
RcmWGtt=!JSaFc@x0+;{*

literal 0
HcmV?d1

diff --git a/rtl_bt/rtl8723d_fw.bin b/rtl_bt/rtl8723d_fw.bin
new file mode 100644
index 
..57f3a5997a8685fb0ead20d8f79d7c012a264f00
GIT binary patch
literal 47028
zcmd443tSXemIqwbbTp0KMg0%(mky|{nu_T8-GS+j8Tlnmj-s3pL$9ba1@raLicZADa
z9pQB@A-^Wr5q`xb7sv&UP)AsFG1n-~(_VkCP?N
zAP>X&2faaF)4<7D2?kj}UVNZj^DZYh=nV4hICHrF7M{yWGRQ}fuNCP#aNUUf#~X2t
zbL9FMyA+ZwQi!?2E|$6(o5m^^M~bEH$dVG#)X9`FWk&Z@N$6SYH{rO>pN`|p{=qoD
z;xEAQRev&$ulW~Bj9ut?-TySMO8r8Q4dGV^5`qJv0-+M&Nra~mst{KC=?zqOoNW~6
z8`-OIRYROi8$5SV)|(Np?a;(%0*lBz{2J!_0N$b2Q*#l^`Z5r66(
zPQG+~j7{yS4)A$=o+A+FF?I5vQycx($?RinaUTANl6K_&)dqPU0%Mz#uk${29^dgr
zd~;#J`U^rUJ5On$K;ohvE7ebpe7Oiel*TXB9!qsc%Bwry+G8@#9(@DRp*WJ%st2NNipm4
zM|d6Qg>8=q+3X9QhQO>YR(L=}tyfsO*f}`cES-rZ$E}g47@JCn*m47$mv7}f$!6!?
z_s{yS*B89eU3($!p?E9n(0iS&{1Fw$@8w$)HtW{Mqpq4#7T-&CrSGQiFGS!GW+Ft}
z0dFbShoY@8JbQ^)zDKEZFj?uNj_{k9H@jSn@#H0@EWso9aFTPc+P*BH?{;)E##yuV
z-LZC|_q@q62WXC}k5ReRoy=u}M7j2f%;ogH*pR-Mu{WmKtVVs~O1~>jU7B({nVw#u
zTGiS$&B|QW??^n!7%vnho#xLZZcN%-v}=fY&Mp}(`S7moRaz@+AL=%R*Z6<7OUFHe
z6tsrjprowcmF5=wOT;OM*N7^cDO}WIx`MG9KHsw7i1uWXd+pZvO$i%xn;GK+W_4Q}
z#~4@bJ1(YfPFbIf+UPK!sjnHd)nZe$zxnOV!r=mIQ@5qMHEq^LWt>V<;7<!WIo|8WTO`&#Un8QOP+TiBCoOMRS1
zs1y)AtR%O*DKaBZng+KC9#hy`ZwhZhc)EV9SkpDE-O=?^Pe=Wu9-%(w9${~F@G&oqBGYB2LT=QD{up8xe;_`5V7}M+dp_LWka9Bl
z)X-ZP2OstvymWoIG`MXDW?$F%^wY&&XCo`=yKB0c%fl?uQJTJaNbTSa_fd%s<{DEj
zH&%D=5Z$ebo5BU$=A)h5rr@QcmweaHPVb!F9U8Xz>a?RFFM;Nkb8_=LU#g$HU7AwR|
zuOa9-?+e@NH7nJaxp!eiX}Nyd9kSkmr(|ROc)>r-owYU22HKdxuE<9z|KJjOnq1Vn
zj9qQcaSJZ?@zvrj?)4YghfLwYt}P
zf_4#q6B|!d=ATNFmL?ugIA+>@uf0&r4NhJekvQv8*Uxh9_4xL_=$dRV^>cQ6usUe<
zJGas}RY`NX%#|u@rZkgFTUlgfx0>^2=2ZuVnN>IzEQ+^|xz5_=2P~c1%ZyFOr7wyX
zVkxStjIFqnxn|A>N9P~Hjq~s=j4h$+7Ehe@1?lw`HOETD=YAEEThK0`PPFQe@tTbP
zQoxi^KSu14c~T%{ky=P@DMwTsY
zvq#&zJ`u%NOM3U89KyBX6+3&Vv@)*ky}C}T_7oVY##J*_PzzHbwFwK+4Q^XE$G
zu%*W1LywI(Ir7vpQEnV_b(rmqfX4jOt7)rz;W*)QZf*U_=2Zt$POS3s2Pv=;zTs$9
z^OmEVkIH|13Mq_(R$ZcEY3*sXDI4ECXLd2RN4N*hX&O=;>lzw6TV^sCT`;LE6#9dB{QM`P
z{QHNzz6STyP$t
zr<>-!fBN5kIhC!T6n5g7-xM{UIr>Hc>u3zAa_{vrjrVw&);ML9rqunHWo_VXD{EUX
zT0(bw8fS3f0xNrPVTy
zLn32b>5=!cws>wtEoOzW0dsaa0?|;Sr8Hk2$C>Ev5`+?j
zClH9X5{-@WN_-=8RZ|rwFjt3F4Ye}m3J2Dy@8ufHu^wx!9pMG8xNMVg)E#e%{k&no
zs&G!q>?9gO<>}q5o$q*sr(Ls*0GykFzhHZ#WRySQFTK|K6c7Ca*M
zE-{|g=pN=N4cuZiy5+4#&l|yv9Mzto&7-)X-kC+SLc^^-7gmGHS+i$#rdx|HWQNkL
zFYXd{(Vi+4>bR1=I6;`zk?f8uUVoO}6zbeBo*m!Ml`>`Fd(&jvE6qW8cyH#b_v0Kv
z8r6lqA;HTy7~>14$}4oeF@1%$H>T^Y_u}7hash$`A=-|)Zf98QQk!Js&vQU?IoUV|
z=W*_-*xfAkn{Zs_Psg#$KN!d5{sJ6Dw3EADf=!vy7%Ky|C_(1s9{+H
z?R;qeGYkJ8^{A@UR+D5hRz9P0fWr6E<2y_l(lpbbRu`CZQ<$GE
zE?{m+%V!2J&tn89(pkEf&8RQtATM2GbIzqPM#g~aL5zG3VGn{Zf?<9@a3jn_z8TrL
zhp-1hz_ULfxDn_cJD%xcbD7uPqkL1MXLc~k8_dWigc%4c5PpT=LHHaYLV52&o_ml7
z0daW+!mkiK2%jTR9=3%3o>=|-mS6wtf6-rI$V55MF>zLvSYIr{U(fwORipYg}po#CJP@AH7$
z?3Kdk&-BY+WYCj)RMB}h^%G9MD+TfsoH@u#|67n>OosgCb%Vbb8-mJeRu-(!o4Z=NXPY>lbl?FbJN?LoR0H_Lns&b
ze~#!wKZ5#pYHtmjp#>0P3(ix`gHk42Gr#+_Lo$M7FoLh-Q)SLP1
zuBprOS?N9Sc;H2Yj7^SS#iT3Z$Q(*it0b>d)uSy%Xwg?H)Ffo!1&jSai=aXbusZdJpXM}U(<}5d>F?4{8nH|nJw

Re: [PATCH] rtlwifi: rtl8192cu: remove pointless memcpy

[Larry Finger]

On 02/09/2018 07:24 AM, Arnd Bergmann wrote:

gcc-8 points out that source and destination of the memcpy() are
always the same pointer, so the effect of memcpy() is undefined
here (its arguments must not overlap):

drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c: In function 
'_rtl_rx_process':
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:430:2: error: 'memcpy' 
source argument is the same as destination [-Werror=restrict]

Most likely this is harmless, but it's easy to just remove the
line and get rid of the warning.

Signed-off-by: Arnd Bergmann 
---
  drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c
index ac4a82de40c7..9ab56827124e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c
@@ -427,7 +427,6 @@ static void _rtl_rx_process(struct ieee80211_hw *hw, struct 
sk_buff *skb)
 (u32)hdr->addr1[0], (u32)hdr->addr1[1],
 (u32)hdr->addr1[2], (u32)hdr->addr1[3],
 (u32)hdr->addr1[4], (u32)hdr->addr1[5]);
-   memcpy(IEEE80211_SKB_RXCB(skb), rx_status, sizeof(*rx_status));
ieee80211_rx(hw, skb);
  }


Argh. Once again I got tripped up on pointers. Yes, this patch is correct.

Acked-by: Larry Finger 

Sorry about the noise.

Larry

Re: [PATCH] rtlwifi: rtl8192cu: remove pointless memcpy

[Larry Finger]

On 02/09/2018 07:24 AM, Arnd Bergmann wrote:

gcc-8 points out that source and destination of the memcpy() are
always the same pointer, so the effect of memcpy() is undefined
here (its arguments must not overlap):

drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c: In function 
'_rtl_rx_process':
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:430:2: error: 'memcpy' 
source argument is the same as destination [-Werror=restrict]

Most likely this is harmless, but it's easy to just remove the
line and get rid of the warning.

Signed-off-by: Arnd Bergmann 
---
  drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c
index ac4a82de40c7..9ab56827124e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c
@@ -427,7 +427,6 @@ static void _rtl_rx_process(struct ieee80211_hw *hw, struct 
sk_buff *skb)
 (u32)hdr->addr1[0], (u32)hdr->addr1[1],
 (u32)hdr->addr1[2], (u32)hdr->addr1[3],
 (u32)hdr->addr1[4], (u32)hdr->addr1[5]);
-   memcpy(IEEE80211_SKB_RXCB(skb), rx_status, sizeof(*rx_status));
ieee80211_rx(hw, skb);
  }


No, the warning is pointing to the wrong place. The routine in question does the 
following:


1. Loads the rx_status struct from skb->cb.
2. Overwrites the contents with 0.
3. Fills various members of the struct.
4. Writes the revised struct back into skb->cb.

Thus eliminating step 4 negates all the things done in step 3, and is wrong. The 
correct fix is to change step 1 to create a NULL-filled rx_status struct, and 
eliminate step 2.


NACK.

Larry

Re: [PATCH v2] rtlwifi: rtl8192cu: Remove variable self-assignment in rf.c

[Larry Finger]

On 02/08/2018 06:57 PM, Matthias Kaehlcke wrote:

In _rtl92c_get_txpower_writeval_by_regulatory() the variable writeVal
is assigned to itself in an if ... else statement, apparently only to
document that the branch condition is handled and that a previously read
value should be returned unmodified. The self-assignment causes clang to
raise the following warning:

drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c:304:13:
   error: explicitly assigning value of variable of type 'u32'
 (aka 'unsigned int') to itself [-Werror,-Wself-assign]
   writeVal = writeVal;

Delete the branch with the self-assignment.

Signed-off-by: Matthias Kaehlcke 
---
Changes in v2:
- Delete the 'else if' branch entirely

  drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c | 3 ---
  1 file changed, 3 deletions(-)


Acked-by: Larry Finger 




diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c
index 9cff6bc4049c..cf551785eb08 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c
@@ -299,9 +299,6 @@ static void 
_rtl92c_get_txpower_writeval_by_regulatory(struct ieee80211_hw *hw,
writeVal = 0x;
if (rtlpriv->dm.dynamic_txhighpower_lvl == TXHIGHPWRLEVEL_BT1)
writeVal = writeVal - 0x06060606;
-   else if (rtlpriv->dm.dynamic_txhighpower_lvl ==
-TXHIGHPWRLEVEL_BT2)
-   writeVal = writeVal;
*(p_outwriteval + rf) = writeVal;
}
  }

Re: [PATCH] rtlwifi: rtl8192cu: Remove variable self-assignment in rf.c

[Larry Finger]

On 02/07/2018 02:26 PM, Matthias Kaehlcke wrote:

In _rtl92c_get_txpower_writeval_by_regulatory() the variable writeVal
is assigned to itself in an if ... else statement, apparently only to
document that the branch condition is handled and that a previously read
value should be returned unmodified. The self-assignment causes clang to
raise the following warning:

drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c:304:13:
   error: explicitly assigning value of variable of type 'u32'
 (aka 'unsigned int') to itself [-Werror,-Wself-assign]
   writeVal = writeVal;

Replace the self-assignment with a semicolon, which still serves to
document the 'handling' of the branch condition.

Signed-off-by: Matthias Kaehlcke 
---
  drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c
index 9cff6bc4049c..4db92496c122 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c
@@ -301,7 +301,7 @@ static void 
_rtl92c_get_txpower_writeval_by_regulatory(struct ieee80211_hw *hw,
writeVal = writeVal - 0x06060606;
else if (rtlpriv->dm.dynamic_txhighpower_lvl ==
 TXHIGHPWRLEVEL_BT2)
-   writeVal = writeVal;
+   ;
*(p_outwriteval + rf) = writeVal;
}
  }



As the branch condition does nothing, why not remove it and save the compiler's 
optimizer a bit of work? The code looks strange, but it matches the rest of 
Realtek's USB drivers.


Larry

Re: [PATCH] wireless: broadcom: radio_2056: delete duplicated macro definitions

[Larry Finger]

On 01/08/2018 03:26 PM, Rasmus Villemoes wrote:

Ctrl-V was hit twice when these macros were inserted:

$ sed -n '9,527p' ./drivers/net/wireless/broadcom/b43/radio_2056.h | md5sum
4db53450c59d9939e903d4e4ba6bc9b1  -
$ sed -n '528,1046p' ./drivers/net/wireless/broadcom/b43/radio_2056.h | md5sum
4db53450c59d9939e903d4e4ba6bc9b1  -

Signed-off-by: Rasmus Villemoes 


The subject line is wrong here. You should refer to the driver, not the file 
being changed. For historical reasons, wireless is not mentioned, nor is 
broadcom in a subject. Thus the subject should be "b43: Delete duplicated macro 
definitions".


For the commit message, I would not try to state how the error occurred, nor the 
sed command needed to verify the duplication. A simple "A number of macros are 
entered twice." should suffice. If you removed something that was needed, the 
compiler would complain.


NACK

Larry


---
  drivers/net/wireless/broadcom/b43/radio_2056.h | 519 -
  1 file changed, 519 deletions(-)

diff --git a/drivers/net/wireless/broadcom/b43/radio_2056.h 
b/drivers/net/wireless/broadcom/b43/radio_2056.h
index 59297fdce5e3..779b80ea072f 100644
--- a/drivers/net/wireless/broadcom/b43/radio_2056.h
+++ b/drivers/net/wireless/broadcom/b43/radio_2056.h
@@ -525,525 +525,6 @@
  #define B2056_VCM_MASK0x1C
  #define B2056_RSSI_VCM_SHIFT  0x02
  
-#define B2056_SYN			(0x0 << 12)

-#define B2056_TX0  (0x2 << 12)
-#define B2056_TX1  (0x3 << 12)
-#define B2056_RX0  (0x6 << 12)
-#define B2056_RX1  (0x7 << 12)
-#define B2056_ALLTX(0xE << 12)
-#define B2056_ALLRX(0xF << 12)
-
-#define B2056_SYN_RESERVED_ADDR0   0x00
-#define B2056_SYN_IDCODE   0x01
-#define B2056_SYN_RESERVED_ADDR2   0x02
-#define B2056_SYN_RESERVED_ADDR3   0x03
-#define B2056_SYN_RESERVED_ADDR4   0x04
-#define B2056_SYN_RESERVED_ADDR5   0x05
-#define B2056_SYN_RESERVED_ADDR6   0x06
-#define B2056_SYN_RESERVED_ADDR7   0x07
-#define B2056_SYN_COM_CTRL 0x08
-#define B2056_SYN_COM_PU   0x09
-#define B2056_SYN_COM_OVR  0x0A
-#define B2056_SYN_COM_RESET0x0B
-#define B2056_SYN_COM_RCAL 0x0C
-#define B2056_SYN_COM_RC_RXLPF 0x0D
-#define B2056_SYN_COM_RC_TXLPF 0x0E
-#define B2056_SYN_COM_RC_RXHPF 0x0F
-#define B2056_SYN_RESERVED_ADDR16  0x10
-#define B2056_SYN_RESERVED_ADDR17  0x11
-#define B2056_SYN_RESERVED_ADDR18  0x12
-#define B2056_SYN_RESERVED_ADDR19  0x13
-#define B2056_SYN_RESERVED_ADDR20  0x14
-#define B2056_SYN_RESERVED_ADDR21  0x15
-#define B2056_SYN_RESERVED_ADDR22  0x16
-#define B2056_SYN_RESERVED_ADDR23  0x17
-#define B2056_SYN_RESERVED_ADDR24  0x18
-#define B2056_SYN_RESERVED_ADDR25  0x19
-#define B2056_SYN_RESERVED_ADDR26  0x1A
-#define B2056_SYN_RESERVED_ADDR27  0x1B
-#define B2056_SYN_RESERVED_ADDR28  0x1C
-#define B2056_SYN_RESERVED_ADDR29  0x1D
-#define B2056_SYN_RESERVED_ADDR30  0x1E
-#define B2056_SYN_RESERVED_ADDR31  0x1F
-#define B2056_SYN_GPIO_MASTER1 0x20
-#define B2056_SYN_GPIO_MASTER2 0x21
-#define B2056_SYN_TOPBIAS_MASTER   0x22
-#define B2056_SYN_TOPBIAS_RCAL 0x23
-#define B2056_SYN_AFEREG   0x24
-#define B2056_SYN_TEMPPROCSENSE0x25
-#define B2056_SYN_TEMPPROCSENSEIDAC0x26
-#define B2056_SYN_TEMPPROCSENSERCAL0x27
-#define B2056_SYN_LPO  0x28
-#define B2056_SYN_VDDCAL_MASTER0x29
-#define B2056_SYN_VDDCAL_IDAC  0x2A
-#define B2056_SYN_VDDCAL_STATUS0x2B
-#define B2056_SYN_RCAL_MASTER  0x2C
-#define B2056_SYN_RCAL_CODE_OUT0x2D
-#define B2056_SYN_RCCAL_CTRL0  0x2E
-#define B2056_SYN_RCCAL_CTRL1  0x2F
-#define B2056_SYN_RCCAL_CTRL2  0x30
-#define B2056_SYN_RCCAL_CTRL3  0x31
-#define B2056_SYN_RCCAL_CTRL4  0x32
-#define B2056_SYN_RCCAL_CTRL5  0x33
-#define B2056_SYN_RCCAL_CTRL6  0x34
-#define B2056_SYN_RCCAL_CTRL7  0x35
-#define B2056_SYN_RCCAL_CTRL8  0x36
-#define B2056_SYN_RCCAL_CTRL9  0x37
-#define B2056_SYN_RCCAL_CTRL10 0x38
-#define B2056_SYN_RCCAL_CTRL11 0x39
-#define B2056_SYN_ZCAL_SPARE1  0x3A
-#define B2056_SYN_ZCAL_SPARE2  0x3B
-#define B2056_SYN_PLL_MAST10x3C
-#define B2056_SYN_PLL_MAST20x3D
-#define B2056_SYN_PLL_MAST30x3E
-#define B2056_SYN_PLL_BIAS_RESET   0x3F
-#define B2056_SYN_PLL_XTAL00x40
-#define B2056_SYN_PLL_XTAL10x41
-#define B2056_SYN_PLL_XTAL30x42
-#define B2056_SYN_PLL_XTAL40x43
-#define B2056_SYN_PLL_XTAL50x44
-#define B2056_SYN_PLL_XTAL60x45
-#define B2056_SYN_PLL_REFDIV   0x46
-#define B2056_SYN_PLL_PF

Re: [PATCH v2] b43: Replace mdelay with usleep_range in b43_radio_2057_init_post

[Larry Finger]

On 01/08/2018 07:40 PM, Jia-Ju Bai wrote:

b43_radio_2057_init_post is not called in an interrupt handler
nor holding a spinlock.
The function mdelay in it can be replaced with usleep_range,
to reduce busy wait.

Signed-off-by: Jia-Ju Bai 
---
v2:
* Replace mdelay with usleep_range, instead of msleep in v1.
   Thank Larry for good advice.
---


I agree that a sleep of 2-3 ms should be OK here.

Acked-by: Larry Finger 

Larry


  drivers/net/wireless/broadcom/b43/phy_n.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c 
b/drivers/net/wireless/broadcom/b43/phy_n.c
index a5557d7..f2a2f41 100644
--- a/drivers/net/wireless/broadcom/b43/phy_n.c
+++ b/drivers/net/wireless/broadcom/b43/phy_n.c
@@ -1031,7 +1031,7 @@ static void b43_radio_2057_init_post(struct b43_wldev 
*dev)
  
  	b43_radio_set(dev, R2057_RFPLL_MISC_CAL_RESETN, 0x78);

b43_radio_set(dev, R2057_XTAL_CONFIG2, 0x80);
-   mdelay(2);
+   usleep_range(2000, 3000);
b43_radio_mask(dev, R2057_RFPLL_MISC_CAL_RESETN, ~0x78);
b43_radio_mask(dev, R2057_XTAL_CONFIG2, ~0x80);
  

Re: [PATCH][next] rtlwifi: btcoexist: remove redundant variable fw_ps_state

[Larry Finger]

On 01/09/2018 10:43 AM, Colin King wrote:

From: Colin Ian King 

Variable fw_ps_state is assigned a value but it is never read, hence
it is redundant and can be removed.


Acked-by: Larry Finger 

Thanks,

Larry



Cleans up clang warning:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c:736:2:
warning: Value stored to 'fw_ps_state' is never read

Signed-off-by: Colin Ian King 
---
  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index 5f3eda31187a..873bf9303d5d 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -677,7 +677,7 @@ static void halbtc_display_wifi_status(struct btc_coexist 
*btcoexist,
u32 wifi_link_status = 0x0;
bool bt_hs_on = false, under_ips = false, under_lps = false;
bool low_power = false, dc_mode = false;
-   u8 wifi_chnl = 0, wifi_hs_chnl = 0, fw_ps_state;
+   u8 wifi_chnl = 0, wifi_hs_chnl = 0;
u8 ap_num = 0;
  
  	wifi_link_status = halbtc_get_wifi_link_status(btcoexist);

@@ -733,7 +733,6 @@ static void halbtc_display_wifi_status(struct btc_coexist 
*btcoexist,
dc_mode = true; /*TODO*/
under_ips = rtlpriv->psc.inactive_pwrstate == ERFOFF ? 1 : 0;
under_lps = rtlpriv->psc.dot11_psmode == EACTIVE ? 0 : 1;
-   fw_ps_state = 0;
low_power = 0; /*TODO*/
seq_printf(m, "\n %-35s = %s%s%s%s",
   "Power Status",

Re: b43: Replace mdelay with msleep in b43_radio_2057_init_post

[Larry Finger]

On 01/08/2018 10:21 AM, Kalle Valo wrote:

Jia-Ju Bai  wrote:


b43_radio_2057_init_post is not called in an interrupt handler
nor holding a spinlock.
The function mdelay in it can be replaced with msleep, to reduce busy wait.

Signed-off-by: Jia-Ju Bai 


You submitted an identical patch a week earlier:

https://patchwork.kernel.org/patch/10137671/

How is this different? Also always add version number to the patch so that the
maintainers can follow the changes easily:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#patch_version_missing

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#changelog_missing


I had negative comments on one of those due to the possibility of msleep(2) 
extending as long as 20 msec. Until the author, or someone else, can test that 
this is OK, then the mdelay(2) can only be replaced with usleep_range(2000, 3000).


NACK for both.

Larry

[PATCH] rtlwifi: rtl8723de: Add firmware for new driver/device

[Larry Finger]

A driver for the RTL8723DE is nearing submission to staging. This commit 
supplies
the firmware for it.

Signed-off-by: Larry Finger 
Cc: Ping-Ke Shih 
---
 WHENCE  |   9 +
 rtlwifi/rtl8723defw.bin | Bin 0 -> 27726 bytes
 2 files changed, 9 insertions(+)
 create mode 100644 rtlwifi/rtl8723defw.bin

diff --git a/WHENCE b/WHENCE
index 7518a93..a4dc54f 100644
--- a/WHENCE
+++ b/WHENCE
@@ -2469,6 +2469,15 @@ Licence: Redistributable. See 
LICENCE.rtlwifi_firmware.txt for details.
 
 --
 
+Driver: rtl8723de - Realtek 802.11ac WLAN driver for RTL8723DE
+
+Info: Supplied by Vendor at https://github.com/pkshih/rtlwifi_rtl8723de
+File: rtlwifi/rtl8723defw.bin
+
+Licence: Redistributable. See LICENCE.rtlwifi_firmware.txt for details.
+
+--
+
 Driver: r8723au - Realtek 802.11n WLAN driver for RTL8723AU
 
 Info: Taken from Realtek driver rtl8723A_WiFi_linux_v4.1.3_6044.20121224
diff --git a/rtlwifi/rtl8723defw.bin b/rtlwifi/rtl8723defw.bin
new file mode 100644
index 
..6d2c95392a947e454d0365d6d982d393a5dfadf6
GIT binary patch
literal 27726
zcmd_Td0nT{i?a=
zoagM@bDr%S+J>d;F4gIDDd(Mk&8Wu(`2PJ*sPLQ(6ux}m?4VBg;k|RhzYPdGtQ;h~
zt>qJbDEe)Z|2}-48c##)c`AK%CM{&rLg`v4T?<8c3Y`|v_0x*%V>K9b#uN*Et!9IO
zugRd-8T<9Im~__EJ{F_S+P9Ax{=R)o2Kpk6HA74_>e4gB6nq`_i$q&RO*xLSj>ibmWXD5H2>r$-k
zEsA_Rn7Xe%_tIc0)t88l4r>4GWN`6ZmwB&pe2^SLWaaMT=cUT~f~i!G*GNrJ4Cx0`
zy}IlJmh7L5UaRw%bK%EdG&<#}7JEtMD~lz;WsX~)itj(|H3UlJ8h!Mn_*y?M7#Y
z_LnM0ooqj4Z6Cz@5$&4eN=Z31c<_mo6#3}Df%3QA=#0^{*tD2Dc1mq+Kh?c0RoJ|E
zklEbMGYlSlC?(~@VEO1J@;4zz<;iyA$xxON&8j(W4Q16F_v-Au4GB?y+p~E?oX?^m
z!PIS*K2jxG7g;PUosmCES_%IS8dVJ2DT+DW-gEeImvxir(D920%f~huUNH@!Y(Jr3
zo;o_HLZ3z{U(s7Dj1(ojwzvyf`lW0#wV#lW5$MMii~p@5H0(iBwjz8H_~IZ28>4?v
zpC&B5ZM7PR$7piolRGzOpXlecw!8X{JnqWQA0=C|!{)BzuHlOWYqpw>BGL~H>z{ov
z71@ol$ioAioq6aR`s1})L(`XH*ze+VIWuk#T^aA55bGKr?YySP-Wqx_-u*(X>-lKs
z+8+DQtJRI4u2eUU=sCQKzLjbhzDMByY?BK3$WN~su0{_d)ril=sXZNth;3Fo5Z?2V
zI_k6WvB1QhBO6D4K2D9oXAj*M@4h$I_4{b&JqX+y@4hA0b#t`yrXIU;vOzi3p#0jP
zoVF{cx#yI}t_Xp&@dSJrz
z%v_mO91ASc*SOwoh&v}|2UDCwV#w&y_uu1e8LqfC$&^a@LcY04?n`)x5FpmubU|8-&A{ETxB|wAPj+H
zgd@JT9)+?R7nR3qW}z@vQx;y&Y8Hm)vYOiPBdn%QwMUkQkO8=Q2sHr}N?(nNED4OQ
z3cnbaJ{~2mD+{4kX~rnAvu{Y%AWC*{P_Zg@i!XKz7~nLVZZsp4_<}boJ{Gkze_q>o
zrUUM$mYAvF_YSd|LyB80$U_~-F*#d7!@4BB%4!ZL;h2y34in(rfQO%pGym->lD7`X
zR#L>}oy>oSDx2^{bN#m~%wGWa4kZSU65qEze>^YTsgH{DJRByL+!BJvZC2vpuxwJ|
z;-1%0xZ<+#Xp9DO8ddpiW_lpN%XD85r%dhvtRmI+8LRBFeI~wl%(+8#dR2RQJP;Q*
z?qZcuCDx$4YCa_x7wk)K)VH?mWpy`nsmzz7#6G0qz>b}AQ+IeJcbRXz5}WS^B;*!`
zZgj-(J?x0NW;%KR9OdY72~(zYH}^M)o(Czd+vL@YB`xG_HUsG3KBEnFC~=obERrz@
z)G~q>S}C_!_UV)<|9#&6eOZOh_Sp`7vWmh~%Ef`9LOn0x(Vbce&HtA8tVX1sDd^Fi
zyn3U%h*b!-&rpo}e(}kB<$HK*|5t^a-C^S(aly^<0A5IHD)WsNw~fHbBbNRXAo2aB
z>fXK2HQF&(c|yhb#Ndnj+T%`rjQQ4y@3Wa|50*^SX{1Gl6?Bc_jLlTLoYr`!^TfGtBo2
zmD_+)>l1)Y@UQ1}ZRSv_^;MPWCrMT{>J`L=rU3K(po%zKl|f=hN4Ap6Dp$1KTW&<8
zago@0p=86DUZZ3yW0-#mc3%L+n|EPvnLif)=8grTCF$a4$C&ve0)41~#EMMjzfLsf
zQ17)pJ)l9!R4h*Y^g>m}Cc7SkuZoSkneSz#S#M>&H&C>EB@Y^T5WDXp9yIfypvwJt
z&|;>IR+%1M)o0GCw8vIuJico1+*Oy%TQzL{s>|G~Mz&TJeOy(vtEy;s
z)sz3w=~j(yn<^~7m_9LlK21UMlz4+!F<#hvEdZbE@Y!I+XU7ltwEPvHp*`Lb*xXPfxROM-C`z{5N7
z+5eZesZ*TrJUtVig)V#+P+|99g-_XGeB5L3x#<&pN{`~RI}@LRG74tnbN4U!NLBch
zynxRGeev0I5!1IQ({VnaM@+vHhh*JA?0HuCG-2O(WXY}qhUkX>A
zy%_l9H;C=G(eziI!piS2kLKIqd~AnI#VT(3ArR%|QDmBY9`jwLxH8TKr+eq~rLh6~
z#L9~iUzh7bx3uZ=kk(Qd?9PPZ6<=bUM*
z?lN_+LHx5J{2b!MmwIquO6kB9PfC`889;V)Bm*`2OAFd=@`6oV#1Ga$Pc&vP*Y}={
z<3nl#j>pPV;;MVgr}IG+eSc?l6VSEs&H5C@Hc^=lOkg38^K>F5#+L89VE+%Ds>4JS
z$>PXTdsY8XcKb!PFO;Zlf&xtZoU8^;H})5cW!p!#1Cm}Yu>EXQZ9f+Z?n|TxhWF3;
zs}eot5@e&6MeG=5`vU0%`EuLO`_>q82e8UF(Jqu=T*ON-$Z5Yxs&45Yh{lEa#nM~D
z`%^nsMV1CstzEigyA<}^18Rf)tR#wkb#c{GA=^KdsM8yHy2~j?O2h+yi7Wu&6awM&
zq0R*sQZcFjj1&vROPk6T?LF<~-+$)kie-#mG4-w%qaJ*ExZ>a;%t4?g28uf#
zEKb6zB1^l~hLCDcPI>K7vE_B~;Lof!2E<#7DFtN9N38ZZj!g@zJ?Y6(SnVkl!{PL@
z+8&Bm!~>fFjN-5c=!Dwg9?Di+=h+k&JElh2id=EuKSss_bj+`DA&QbeCpK=jEI(B^+jGn0~_3r-6vKc%u2H+VKhmWccIju|t?d2%Mf
zrpr{PXM^pZA+_6WV*1_Gh*O>op0NPX9QPn^3{yQbMtzCfCU&dkdU4i?1cd__t$TfP
zePND^y0Vo^Xz{QWcYCVXir>@cKKk5Gp9ek9t6kX#`e-Tc;Gu&i@#|dyRXp-N&avro
z44!V)E*j?r)CQFjCj539#-mEiPACE6X?M)0iZQWvW?ZI3+^qI~#i#}%Ma*}l5)T%&
z*5?|87iI*Du)HHrh#hsx>?d3Uu?K=r5b?03C>j^%7XywkGj32oALcbEvy0p}0b4)X
z0P6jFm1my)s2c^{ME>BT1k#4aj|LlNq9WTw3>=DmRBgac*;0g^h=P%WR&|m1^*@OE
z`X{;*qW%Pn*or&QJtZ<1^~?(v0k+X`_bF+`IQ7>uJ@dEW3>Q1Tii?H;Sy)-$)8{h!
zq-8}syg`viu~GjRd=z_jPNI%tG~XqBFi@;NMtNUXdG4S(DaK3a7CVM##kgGu>H@dI=IOKtdEMU~OlRM3r`V`8C^(e8;oCOMFjXsMLF=T+|{D=y9
zg6)X}2%VK+J09wxPdV@Ux$b@#1H~;gD114w
z+FKQuSo~xk@yO?an$`

Re: [PATCH] b43: Replace mdelay with msleep in b43_radio_2057_init_post

[Larry Finger]

On 12/30/2017 05:08 AM, Jia-Ju Bai wrote:

b43_radio_2057_init_post is not called in an interrupt handler
nor holding a spinlock.
The function mdelay in it can be replaced with msleep, to reduce busy wait.

Signed-off-by: Jia-Ju Bai 


checkpatch.pl reports the following warning for this patch:

WARNING: msleep < 20ms can sleep for up to 20ms; see 
Documentation/timers/timers-howto.txt

#26: FILE: drivers/net/wireless/broadcom/b43/phy_n.c:1034:
+   msleep(2);

total: 0 errors, 1 warnings, 0 checks, 8 lines checked

Have you tested to verify that a sleep as long as 20 ms will not cause problems? 
The referenced document suggests a usleep_range() call.


In general, delay changes should never be proposed without testing.

Larry

Re: [PATCH 1/1] rtlwifi: always initialize variables given to RT_TRACE()

[Larry Finger]

On 12/10/2017 01:51 PM, Nicolas Iooss wrote:

In rtl_rx_ampdu_apply(), when rtlpriv->cfg->ops->get_btc_status()
returns false, RT_TRACE() is called with the values of variables
reject_agg and agg_size, which have not been initialized.

Always initialize these variables in order to prevent using
uninitialized values.

This issue has been found with clang. The compiler reported:

 drivers/net/wireless/realtek/rtlwifi/base.c:1665:6: error: variable
 'agg_size' is used uninitialized whenever 'if' condition is false
 [-Werror,-Wsometimes-uninitialized]
 if (rtlpriv->cfg->ops->get_btc_status())
 ^~~
 drivers/net/wireless/realtek/rtlwifi/base.c:1671:31: note:
 uninitialized use occurs here
  reject_agg, ctrl_agg_size, agg_size);
 ^~~~

 drivers/net/wireless/realtek/rtlwifi/base.c:1665:6: error: variable
 'reject_agg' is used uninitialized whenever 'if' condition
   is false [-Werror,-Wsometimes-uninitialized]
 if (rtlpriv->cfg->ops->get_btc_status())
 ^~~
 drivers/net/wireless/realtek/rtlwifi/base.c:1671:4: note:
 uninitialized use occurs here
  reject_agg, ctrl_agg_size, agg_size);
  ^~

Fixes: 2635664e6e4a ("rtlwifi: Add rx ampdu cfg for btcoexist.")
Signed-off-by: Nicolas Iooss 


Looks good. Acked-by: Larry Finger 

Thanks,

Larry


---
  drivers/net/wireless/realtek/rtlwifi/base.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c 
b/drivers/net/wireless/realtek/rtlwifi/base.c
index cad2272ae21b..704741d6f495 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -1726,7 +1726,7 @@ int rtl_tx_agg_oper(struct ieee80211_hw *hw,
  void rtl_rx_ampdu_apply(struct rtl_priv *rtlpriv)
  {
struct rtl_btc_ops *btc_ops = rtlpriv->btcoexist.btc_ops;
-   u8 reject_agg, ctrl_agg_size = 0, agg_size;
+   u8 reject_agg = 0, ctrl_agg_size = 0, agg_size = 0;
  
  	if (rtlpriv->cfg->ops->get_btc_status())

btc_ops->btc_get_ampdu_cfg(rtlpriv, &reject_agg,

[PATCH V2] staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID

[Larry Finger]

When not associated with an AP, wifi device drivers should respond to the
SIOCGIWESSID ioctl with a zero-length string for the SSID, which is the
behavior expected by dhcpcd.

Currently, this driver returns an error code (-1) from the ioctl call,
which causes dhcpcd to assume that the device is not a wireless interface
and therefore it fails to work correctly with it thereafter.

This problem was reported and tested at
https://github.com/lwfinger/rtl8188eu/issues/234.

Signed-off-by: Larry Finger 
---

v2 - completed missing subject
 drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c 
b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
index c0664dc80bf2..446310775e90 100644
--- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
@@ -1395,19 +1395,13 @@ static int rtw_wx_get_essid(struct net_device *dev,
if ((check_fwstate(pmlmepriv, _FW_LINKED)) ||
(check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE))) {
len = pcur_bss->Ssid.SsidLength;
-
-   wrqu->essid.length = len;
-
memcpy(extra, pcur_bss->Ssid.Ssid, len);
-
-   wrqu->essid.flags = 1;
} else {
-   ret = -1;
-   goto exit;
+   len = 0;
+   *extra = 0;
}
-
-exit:
-
+   wrqu->essid.length = len;
+   wrqu->essid.flags = 1;
 
return ret;
 }
-- 
2.13.6

[PATCH] staging: rtl8188eu:

[Larry Finger]

When not associated with an AP, wifi device drivers should respond to the
SIOCGIWESSID ioctl with a zero-length string for the SSID, which is the
behavior expected by dhcpcd.

Currently, this driver returns an error code (-1) from the ioctl call,
which causes dhcpcd to assume that the device is not a wireless interface
and therefore it fails to work correctly with it thereafter.

This problem was reported and tested at
https://github.com/lwfinger/rtl8188eu/issues/234.

Signed-off-by: Larry Finger 
---
 drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c 
b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
index c0664dc80bf2..446310775e90 100644
--- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
@@ -1395,19 +1395,13 @@ static int rtw_wx_get_essid(struct net_device *dev,
if ((check_fwstate(pmlmepriv, _FW_LINKED)) ||
(check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE))) {
len = pcur_bss->Ssid.SsidLength;
-
-   wrqu->essid.length = len;
-
memcpy(extra, pcur_bss->Ssid.Ssid, len);
-
-   wrqu->essid.flags = 1;
} else {
-   ret = -1;
-   goto exit;
+   len = 0;
+   *extra = 0;
}
-
-exit:
-
+   wrqu->essid.length = len;
+   wrqu->essid.flags = 1;
 
return ret;
 }
-- 
2.13.6

Re: [PATCH 1/3] rtlwifi: fix uninitialized rtlhal->last_suspend_sec time

[Larry Finger]

On 11/06/2017 07:55 AM, Arnd Bergmann wrote:

We set rtlhal->last_suspend_sec to an uninitialized stack variable,
but unfortunately gcc never warned about this, I only found it
while working on another patch. I opened a gcc bug for this.

Presumably the value of rtlhal->last_suspend_sec is not all that
important, but it does get used, so we probably want the
patch backported to stable kernels.

Cc: sta...@vger.kernel.org
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82839
Signed-off-by: Arnd Bergmann 


For all three of these patches:

Acked-by: Larry Finger 

Thanks,

Larry


---
  drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
index 60c82a5b51cd..20ffe856180e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
@@ -1373,6 +1373,7 @@ static void _rtl8821ae_get_wakeup_reason(struct 
ieee80211_hw *hw)
  
  	ppsc->wakeup_reason = 0;
  
+	do_gettimeofday(&ts);

rtlhal->last_suspend_sec = ts.tv_sec;
  
  	switch (fw_reason) {

Re: [PATCH] rtlwifi: remove redundant initialization to cfg_cmd

[Larry Finger]

On 11/04/2017 02:37 PM, Colin King wrote:

From: Colin Ian King 

cfg_cmd is initialized to zero and this value is never read, instead
it is over-written in the start of a do-while loop. Remove the
redundant initialization. Cleans up clang warning:

drivers/net/wireless/realtek/rtlwifi/core.c:1750:22: warning: Value
stored to 'cfg_cmd' during its initialization is never read

Signed-off-by: Colin Ian King 


Looks OK to me.

Acked-by: Larry Finger 

Thanks,

Larry


---
  drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c 
b/drivers/net/wireless/realtek/rtlwifi/core.c
index 1147327e6f52..7a17cc20c57e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -1748,7 +1748,7 @@ bool rtl_hal_pwrseqcmdparsing(struct rtl_priv *rtlpriv, 
u8 cut_version,
  u8 faversion, u8 interface_type,
  struct wlan_pwr_cfg pwrcfgcmd[])
  {
-   struct wlan_pwr_cfg cfg_cmd = {0};
+   struct wlan_pwr_cfg cfg_cmd;
bool polling_bit = false;
u32 ary_idx = 0;
u8 value = 0;

[PATCH] rtlwifi: Fix typo in if ... else if ... else construct

[Larry Finger]

The kbuild test robot reports two conditions with no effect (if == else).
These are the result of copy and paste typographical errors.

Signed-off-by: Larry Finger 
Cc: Ping-Ke Shih 
Cc: Yan-Hsuan Chuang 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 
Cc: kbuild-...@01.org
Cc: Julia Lawall 
---
 drivers/staging/rtlwifi/base.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtlwifi/base.c b/drivers/staging/rtlwifi/base.c
index b88b0e8edd3d..1a0331cf63ee 100644
--- a/drivers/staging/rtlwifi/base.c
+++ b/drivers/staging/rtlwifi/base.c
@@ -920,7 +920,7 @@ static u8 _rtl_get_vht_highest_n_rate(struct ieee80211_hw 
*hw,
else if ((tx_mcs_map  & 0x000c) >> 2 ==
IEEE80211_VHT_MCS_SUPPORT_0_8)
hw_rate =
-   rtlpriv->cfg->maps[RTL_RC_VHT_RATE_2SS_MCS9];
+   rtlpriv->cfg->maps[RTL_RC_VHT_RATE_2SS_MCS8];
else
hw_rate =
rtlpriv->cfg->maps[RTL_RC_VHT_RATE_2SS_MCS9];
@@ -932,7 +932,7 @@ static u8 _rtl_get_vht_highest_n_rate(struct ieee80211_hw 
*hw,
else if ((tx_mcs_map  & 0x0003) ==
IEEE80211_VHT_MCS_SUPPORT_0_8)
hw_rate =
-   rtlpriv->cfg->maps[RTL_RC_VHT_RATE_1SS_MCS9];
+   rtlpriv->cfg->maps[RTL_RC_VHT_RATE_1SS_MCS8];
else
hw_rate =
rtlpriv->cfg->maps[RTL_RC_VHT_RATE_1SS_MCS9];
-- 
2.12.3

[PATCH] staging: rtl8822be: Keep array subscript no lower than zero

[Larry Finger]

The kbuild test robot reports the following:
   drivers/staging//rtlwifi/phydm/phydm_dig.c: In function 'odm_pause_dig':
   drivers/staging//rtlwifi/phydm/phydm_dig.c:494:45: warning: array subscript 
is below array bounds [-Warray-bounds]
  odm_write_dig(dm, dig_tab->pause_dig_value[max_level]);

This condition is caused when a loop falls through. The fix is to pin
max_level to be >= 0.

Signed-off-by: Larry Finger 
c: kbuild test robot 
Fixes: 9ce99b04b5b82fdf11e4c76b60a5f82c1e541297 staging: r8822be: Add phydm 
mini driver
---
 drivers/staging/rtlwifi/phydm/phydm_dig.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/rtlwifi/phydm/phydm_dig.c 
b/drivers/staging/rtlwifi/phydm/phydm_dig.c
index 31a4f3fcad19..c88b9788363a 100644
--- a/drivers/staging/rtlwifi/phydm/phydm_dig.c
+++ b/drivers/staging/rtlwifi/phydm/phydm_dig.c
@@ -490,6 +490,8 @@ void odm_pause_dig(void *dm_void, enum phydm_pause_type 
pause_type,
break;
}
 
+   /* pin max_level to be >= 0 */
+   max_level = max_t(s8, 0, max_level);
/* write IGI of lower level */
odm_write_dig(dm, dig_tab->pause_dig_value[max_level]);
ODM_RT_TRACE(dm, ODM_COMP_DIG,
-- 
2.12.3

Re: RTL8192EE PCIe Wireless Network Adapter crashed with linux-4.13

[Larry Finger]

On 09/21/2017 06:37 AM, Zwindl wrote:
Hi, I've reported to archlinux's bugzilla, and finally found out the flag which 
caused that issue, it's the `CONFIG_INTEL_IOMMU_DEFAULT_ON=y` flag, I think may 
this is a kernel bug, more details at https://bugs.archlinux.org/task/55665


My standard kernel has the following:

CONFIG_INTEL_IOMMU=y
# CONFIG_INTEL_IOMMU_SVM is not set
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set

I will do some further testing to see if turning CONFIG_INTEL_IOMMU_DEFAULT_ON 
also breaks my system.


Larry

Re: RTL8192EE PCIe Wireless Network Adapter crashed with linux-4.13

[Larry Finger]

On 09/16/2017 06:27 AM, Zwindl wrote:
Hi, I've done the test, and the weird thing happened. The kernel buit with this 
config file https://ptpb.pw/HF1g which is from 
https://aur.archlinux.org/packages/linux-git/  can run properly, the wifi can 
connect, despite which version it is, but, with this config file 
https://ptpb.pw/7GuV which comes from the archlinux's official package build 
repo(linux-package 
), 
all the version begin with 4.13 was failed to connect wifi.
So, I think the issue is not caused by the kernel code, is caused by some 
options in the config file, but I can't fully understand the meaning of these 
options so that I can't determine which option caused that issue, what should I 
do now, maybe report this bug to archlinux's maintainer?
By the way, maybe I'll lost internet connection tomorrow, it's time to back to 
university, but I'm happy to help to push the debug progress.


Yes, you need to report this to archlinux's bugzilla or maintainer, whichever is 
appropriate. I have seen a configuration error cause some feature to be silently 
missing, but leading to a WARN is rare.


I looked at your two configurations, but did not see a definitive difference.

Larry

Re: RTL8192EE PCIe Wireless Network Adapter crashed with linux-4.13

[Larry Finger]

On 09/15/2017 12:12 PM, Zwindl wrote:

Thanks for your patient and advice, I'll keep that in mind.
I do want help, and I got 1 day to build the system, but I can't recall how to 
compile it, The last time I compile kernel is 2013, so, maybe I'll ask you so 
many stupid questions during the build time.

ZWindL


Building a new kernel is not difficult. In an average week, I make at least 10 
new kernels. Many of them are done on slow machines that take many hours. At 
least, your i5 CPU should do it in less that one hour.


Step 1: Download the kernel sources using

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

If your system complains that the git command is unknown, then you will need to 
install it with your package manager (pacman?).


Step 2: "cd  linux" and copy the latest /boot/config-. to the linux source 
directory as ".config". Edit .config, find the line that says
"# CONFIG_LOCALVERSION_AUTO is not set", and change the line to read 
"CONFIG_LOCALVERSION_AUTO=y".


Step 3: Build and install the latest version using

make -j9
sudo make modules_install install

You will need to answer some configuration questions at the start of the first 
make line. Answer with the default value, i.e. just use an ENTER. When the build 
is complete, reboot. Grub should show an entry for something like 
v4.13-12084-ged43e4d190d0. The numbers after the 4.13 will likely be different, 
but the form will match. Check that the new kernel still has the fault. If not, 
it has been fixed and we do not need to find it.


It the problem is still in the latest version of the kernel, then we start the 
bisection with the following:


git bisect start
git bisect bad v4.13
git bisect good v4.12

At this point, git will report the number of revisions to test, the likely 
number of tries, and the SHA hash for the new kernel. Record the first 7 digits 
of the hash, and repeat the make commands above. After the build is complete, 
reboot into the kernel with the hash in the version name and test. Then enter 
the command "git bisect xxx", where xxx is good or bad depending on the test. A 
new trial will be generated by bisecting the appropriate half of the commits. 
Record its hash and redo the build. Repeat until git tells you the bad commit.


This process will generate a number of kernels that will take quite a bit of 
disk space. If you run short, you can delete kernels that have already been 
tested from /boot. You should also delete the corresponding modules from 
/lib/modules.


Good luck,

Larry

Re: RTL8192EE PCIe Wireless Network Adapter crashed with linux-4.13

[Larry Finger]

On 09/15/2017 05:10 AM, Zwindl wrote:



 Original Message 
Subject: Re: RTL8192EE PCIe Wireless Network Adapter crashed with linux-4.13
Local Time: 14 September 2017 6:05 PM
UTC Time: 14 September 2017 18:05
From: larry.fin...@lwfinger.net
To: Zwindl , linux-wirel...@vger.kernel.org 

chaoming...@realsil.com.cn , kv...@codeaurora.org 
, pks...@realtek.com , 
johannes.b...@intel.com , gre...@linuxfoundation.org 
, netdev@vger.kernel.org , 
linux-ker...@vger.kernel.org 


On 09/14/2017 08:30 AM, Zwindl wrote:
> Dear developers:
> I"m using Arch Linux with testing enabled, the current kernel version and
> details are
> `Linux zwindl 4.13.2-1-ARCH #1 SMP PREEMPT Thu Sep 14 02:57:34 UTC 2017 x86_64
> GNU/Linux`.
> The wireless card can"t work properly from the kernel 4.13. Here"s the log(in
> attachment) when NetworkManager trying to connect my wifi which is named as
> "TP", my mac addr hided as xx:xx:xx:xx:xx.
> What should I provide to help to debug?
> ZWindL.

The BUG-ON arises in __intel_map_single() due to dir (for direction of DMA)
equal to DMA_NONE (3). When rtl8192ee calls pci_map_single(), it uses
PCI_DMA_TODEVICE (1). I followed the calling sequence through the entire chain,
and none of the routines made any changes to "dir", other that changing the type
from int to enum dma_data_direction. That would not have changed a 1 to a 3.

I built a 4.13.2 system. The problem does not happen here. At this point, the
system has been up for about two hours. I did discover a small memory leak
associated with firmware loading, but that should not have caused the problem.
Nonetheless, I will be sending a patch to fix that problem.

I will continue testing, although I doubt that the problem will happen here.

How long had your system been up when the problem occurred? Your dmesg fragment
did not show any times. What kernels have you tried besides 4.13.2?

Larry

Oh, sorry, the original log is from `journalctl`.
Here's the `dmesg` prints(error.txt). I can't determine which part is related, 
so I paste all of it. I've tried 4.12.X(no issue), 4.13.1(issue), 4.13.2(issue).

ZWindL


The output of dmesg is a lot more instructive than that of journalctl. I now 
know exactly the location that triggered the WARNING. I still do not understand 
it. In fact, it is likely a regression in kernel 4.13 that does not affect my 
Toshiba laptop, nor a Lenovo machine I have, but does affect your Lenovo laptop.


Is it possible for you to install the mainline source from vger.kernel.org using 
git and bisect the issue? It will take quite a bit of time, but it is likely the 
only way to find the offending change. If you are willing to try this, I will 
send you reasonably complete instructions.


By the way, it is usually better to load the dmesg output into a pastebin site 
and post the link. Sending the entire file to a list makes a lot of people 
receive a lot of data for which they have no interest.


Larry

Re: RTL8192EE PCIe Wireless Network Adapter crashed with linux-4.13

[Larry Finger]

On 09/14/2017 08:30 AM, Zwindl wrote:

Dear developers:
I'm using Arch Linux with testing enabled, the current kernel version and 
details are
`Linux zwindl 4.13.2-1-ARCH #1 SMP PREEMPT Thu Sep 14 02:57:34 UTC 2017 x86_64 
GNU/Linux`.
The wireless card can't work properly from the kernel 4.13. Here's the log(in 
attachment) when NetworkManager trying to connect my wifi which is named as 
'TP', my mac addr hided as xx:xx:xx:xx:xx.

What should I provide to help to debug?
ZWindL.


The BUG-ON arises in __intel_map_single() due to dir (for direction of DMA) 
equal to DMA_NONE (3). When rtl8192ee calls pci_map_single(), it uses 
PCI_DMA_TODEVICE (1). I followed the calling sequence through the entire chain, 
and none of the routines made any changes to 'dir', other that changing the type 
from int to enum dma_data_direction. That would not have changed a 1 to a 3.


I built a 4.13.2 system. The problem does not happen here. At this point, the 
system has been up for about two hours. I did discover a small memory leak 
associated with firmware loading, but that should not have caused the problem. 
Nonetheless, I will be sending a patch to fix that problem.


I will continue testing, although I doubt that the problem will happen here.

How long had your system been up when the problem occurred? Your dmesg fragment 
did not show any times. What kernels have you tried besides 4.13.2?


Larry

Re: [PATCH] rtlwifi: refactor code in halbtcoutsrc module

[Larry Finger]

On 08/30/2017 11:46 AM, Gustavo A. R. Silva wrote:

Function halbtc_get_wifi_rssi always returns rtlpriv->dm.undec_sm_pwdb.
So this function can be removed and the value of
rtlpriv->dm.undec_sm_pwdb assigned to *s32_tmp directly.

This issue was first reported by Coverity as "identical code for different
branches" in function halbtc_get_wifi_rssi.

Addresses-Coverity-ID: 1226793
Signed-off-by: Gustavo A. R. Silva 
---
This code was reported by Coverity and it was tested by compilation only.
Chances are this may be a copy/paste error in function
halbtc_get_wifi_rssi. Please, verify.
Also, notice this code has been there since 2014.


The value of *s32_tmp is not dependent on the link state, thus this patch is 
correct, but I request that it be changed. Future developments will modify 
halbtc_get_wifi_rssi() making it more complicated and not as easily inlined as 
this patch. In short, if you remove it here, we will have to add it later.


Thanks,

Larrt



  .../net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c   | 13 +
  1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index c1eacd8..2a47b97 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -373,17 +373,6 @@ u32 halbtc_get_wifi_link_status(struct btc_coexist 
*btcoexist)
return ret_val;
  }
  
-static s32 halbtc_get_wifi_rssi(struct rtl_priv *rtlpriv)

-{
-   int undec_sm_pwdb = 0;
-
-   if (rtlpriv->mac80211.link_state >= MAC80211_LINKED)
-   undec_sm_pwdb = rtlpriv->dm.undec_sm_pwdb;
-   else /* associated entry pwdb */
-   undec_sm_pwdb = rtlpriv->dm.undec_sm_pwdb;
-   return undec_sm_pwdb;
-}
-
  static bool halbtc_get(void *void_btcoexist, u8 get_type, void *out_buf)
  {
struct btc_coexist *btcoexist = (struct btc_coexist *)void_btcoexist;
@@ -479,7 +468,7 @@ static bool halbtc_get(void *void_btcoexist, u8 get_type, 
void *out_buf)
*bool_tmp = false;
break;
case BTC_GET_S4_WIFI_RSSI:
-   *s32_tmp = halbtc_get_wifi_rssi(rtlpriv);
+   *s32_tmp = rtlpriv->dm.undec_sm_pwdb;
break;
case BTC_GET_S4_HS_RSSI:
*s32_tmp = 0;

Re: [PATCH] rtlwifi: btcoex: 23b 1ant: fix duplicated code for different branches

[Larry Finger]

On 08/30/2017 08:42 AM, Gustavo A. R. Silva wrote:

Refactor code in order to avoid identical code for different branches.

This issue was detected with the help of Coccinelle.

Addresses-Coverity-ID: 1226788
Signed-off-by: Gustavo A. R. Silva 
---
This issue was reported by Coverity and it was tested by compilation only.
I'm suspicious this may be a copy/paste error. Please, verify.

  .../net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c   | 10 ++
  1 file changed, 2 insertions(+), 8 deletions(-)


This change is not correct. When bt_link_info->sco_exist is true, the call 
should be

halbtc8723b1ant_limited_rx(btcoexist,
   NORMAL_EXEC, true,
   false, 0x5);

NACK

I will push the correct patch.

Larry

Re: [PATCH] rtlwifi: rtl8723be: fix duplicated code for different branches

[Larry Finger]

On 08/30/2017 12:04 PM, Gustavo A. R. Silva wrote:

Refactor code in order to avoid identical code for different branches.

Addresses-Coverity-ID: 1248728
Signed-off-by: Gustavo A. R. Silva 


According to Realtek, this change is OK.

Acked-by: Larry Finger 

Thanks,

Larry


---
This issue was reported by Coverity and it was tested by compilation only.
Please, verify if this is not a copy/paste error.
Also, notice this code has been there since 2014.

  drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c | 8 ++--
  1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c
index 131c0d1..15c117e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.c
@@ -883,12 +883,8 @@ static void 
rtl8723be_dm_txpower_tracking_callback_thermalmeter(
if ((rtldm->power_index_offset[RF90_PATH_A] != 0) &&
(rtldm->txpower_track_control)) {
rtldm->done_txpower = true;
-   if (thermalvalue > rtlefuse->eeprom_thermalmeter)
-   rtl8723be_dm_tx_power_track_set_power(hw, BBSWING, 0,
-index_for_channel);
-   else
-   rtl8723be_dm_tx_power_track_set_power(hw, BBSWING, 0,
-index_for_channel);
+   rtl8723be_dm_tx_power_track_set_power(hw, BBSWING, 0,
+ index_for_channel);
  
  		rtldm->swing_idx_cck_base = rtldm->swing_idx_cck;

rtldm->swing_idx_ofdm_base[RF90_PATH_A] =

[PATCH 0/2] staging: r8822be: Remove some left-over debug code

[Larry Finger]

Some useless debugging code from the initial writing of the driver was not
removed before it was submitted. That oversight is now fixed and the
remaining code in routine deinit_priv() is simplified.

Larry

Larry Finger (2):
  staging: r8822be: Remove some dead code
  staging: r8822be: Simplify deinit_priv()

 drivers/staging/rtlwifi/halmac/rtl_halmac.c | 28 +---
 1 file changed, 1 insertion(+), 27 deletions(-)

-- 
2.12.3

[PATCH 1/2] staging: r8822be: Remove some dead code

[Larry Finger]

The code found inside an #ifdef CONFIG_RTL_DEBUG ... #endif section
is left over from debugging of the original driver, and should be
deleted.

Reported by: Andreas Ziegler 
Signed-off-by: Larry Finger 
Cc: Ping-Ke Shih 
Cc: Yan-Hsuan Chuang 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 
---
 drivers/staging/rtlwifi/halmac/rtl_halmac.c | 20 
 1 file changed, 20 deletions(-)

diff --git a/drivers/staging/rtlwifi/halmac/rtl_halmac.c 
b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
index 031bf2c6078f..2b1c5fae64ef 100644
--- a/drivers/staging/rtlwifi/halmac/rtl_halmac.c
+++ b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
@@ -386,26 +386,6 @@ static void deinit_priv(struct rtl_halmac *halmac)
u32 count, size;
 
count = HALMAC_FEATURE_ALL + 1;
-#ifdef CONFIG_RTL_DEBUG
-   {
-   struct submit_ctx *sctx;
-   u32 i;
-
-   for (i = 0; i < count; i++) {
-   if (!indicator[i].sctx)
-   continue;
-
-   RT_TRACE(
-   rtlpriv, COMP_HALMAC, DBG_LOUD,
-   "%s:  %s id(%d) sctx still 
exist!!\n",
-   __func__, RTL_HALMAC_FEATURE_NAME[i],
-   i);
-   sctx = indicator[i].sctx;
-   indicator[i].sctx = NULL;
-   rtl_mfree((u8 *)sctx, sizeof(*sctx));
-   }
-   }
-#endif /* !CONFIG_RTL_DEBUG */
size = sizeof(*indicator) * count;
kfree((u8 *)indicator);
}
-- 
2.12.3

[PATCH 2/2] staging: r8822be: Simplify deinit_priv()

[Larry Finger]

Now that the extraneous debugging code is removed, routine deinit_priv()
clearly contains code that serves no useful purpose.

A null test before a call to kfree() and a spurious cast are also removed.

Signed-off-by: Larry Finger 
Cc: Ping-Ke Shih 
Cc: Yan-Hsuan Chuang 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 
---
 drivers/staging/rtlwifi/halmac/rtl_halmac.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/staging/rtlwifi/halmac/rtl_halmac.c 
b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
index 2b1c5fae64ef..6448a8bfc14b 100644
--- a/drivers/staging/rtlwifi/halmac/rtl_halmac.c
+++ b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
@@ -382,13 +382,7 @@ static void deinit_priv(struct rtl_halmac *halmac)
 
indicator = halmac->indicator;
halmac->indicator = NULL;
-   if (indicator) {
-   u32 count, size;
-
-   count = HALMAC_FEATURE_ALL + 1;
-   size = sizeof(*indicator) * count;
-   kfree((u8 *)indicator);
-   }
+   kfree(indicator);
 }
 
 int rtl_halmac_init_adapter(struct rtl_priv *rtlpriv)
-- 
2.12.3

Re: [PATCH] rtlwifi: btcoex: 23b 1ant: fix duplicated code for different branches

[Larry Finger]

On 08/30/2017 08:42 AM, Gustavo A. R. Silva wrote:

Refactor code in order to avoid identical code for different branches.

This issue was detected with the help of Coccinelle.

Addresses-Coverity-ID: 1226788
Signed-off-by: Gustavo A. R. Silva 
---
This issue was reported by Coverity and it was tested by compilation only.
I'm suspicious this may be a copy/paste error. Please, verify.


I have referred this change to the engineers at Realtek. For the moment, please 
hold this patch.


Thanks for reporting the condition.

Larry

Re: [PATCH] staging: r8822be: Fix typo for CONFIG_RTLWIFI_DEBUG

[Larry Finger]

On 08/30/2017 02:58 AM, Andreas Ziegler wrote:

Indeed, sorry I missed that as well.

So what should we make of that #ifdef? The code inside it doesn't compile
(anymore? I didn't find any development history for that patch except the
original mail), as there is no definition of struct submit_ctx in the headers
(for other rtl drivers - 8188eu, 8723bs - that struct lives in
include/rtw_xmit.h). Is a comparable header simply missing?

Regards,

Andreas


Andreas,

I'm sorry that I did not have time yesterday to properly analyze the situation. 
All I knew is that your patch was not the correct one. It turns out that the 
extra code was left over from the original writing/testing of the driver and 
should have been deleted. I have prepared a patch that does that and will submit 
it soon.


When the extraneous code was deleted, addition simplifications of the code were 
apparent. I am currently testing that change, and will submit the two patches at 
the same time.


Larry

Re: [PATCH] staging: r8822be: Fix typo for CONFIG_RTLWIFI_DEBUG

[Larry Finger]

On 08/29/2017 06:30 AM, Andreas Ziegler wrote:

The debugging output in deinit_priv is guarded by an  #ifdef using
CONFIG_RTL_DEBUG. This symbol does not exist and should be
CONFIG_RTLWIFI_DEBUG instead.

Signed-off-by: Andreas Ziegler 


NACK.

Yes, there is a problem; however, CONFIG_RTLWIFI_DEBUG is not the value that 
should be used. That one is reserved for the non-staging drivers in 
drivers/net/wireless/realtek/rtlwifi/. The correct symbol for r8822be is 
CONFIG_RTLWIFI_DEBUG_ST.


Larry


---
  drivers/staging/rtlwifi/halmac/rtl_halmac.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtlwifi/halmac/rtl_halmac.c 
b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
index 031bf2c..888ca43 100644
--- a/drivers/staging/rtlwifi/halmac/rtl_halmac.c
+++ b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
@@ -386,7 +386,7 @@ static void deinit_priv(struct rtl_halmac *halmac)
u32 count, size;
  
  		count = HALMAC_FEATURE_ALL + 1;

-#ifdef CONFIG_RTL_DEBUG
+#ifdef CONFIG_RTLWIFI_DEBUG
{
struct submit_ctx *sctx;
u32 i;
@@ -405,7 +405,7 @@ static void deinit_priv(struct rtl_halmac *halmac)
rtl_mfree((u8 *)sctx, sizeof(*sctx));
}
}
-#endif /* !CONFIG_RTL_DEBUG */
+#endif /* !CONFIG_RTLWIFI_DEBUG */
size = sizeof(*indicator) * count;
kfree((u8 *)indicator);
}

[PATCH] rtlwifi: rtl8822be: Add firmware for new driver/device

[Larry Finger]

A driver for the RTL8822BE has been added to staging. This commit supplies
the firmware for it.

Signed-off-by: Larry Finger 
---
 WHENCE  |   9 +
 rtlwifi/rtl8822befw.bin | Bin 0 -> 127496 bytes
 2 files changed, 9 insertions(+)
 create mode 100644 rtlwifi/rtl8822befw.bin

diff --git a/WHENCE b/WHENCE
index 00737d5..e062a35 100644
--- a/WHENCE
+++ b/WHENCE
@@ -2423,6 +2423,15 @@ Licence: Redistributable. See 
LICENCE.rtlwifi_firmware.txt for details.
 
 --
 
+Driver: rtl8822be - Realtek 802.11n WLAN driver for RTL8822BE
+
+Info: Sent to Larry Finger by Realtek engineer Ping-Ke Shih 

+File: rtlwifi/rtl8822befw.bin
+
+Licence: Redistributable. See LICENCE.rtlwifi_firmware.txt for details.
+
+--
+
 Driver: rtl8192ee - Realtek 802.11n WLAN driver for RTL8192EE
 
 Info: Initial version taken from Realtek version
diff --git a/rtlwifi/rtl8822befw.bin b/rtlwifi/rtl8822befw.bin
new file mode 100644
index 
..1fcdbeb2dddf300be548f219065746a90b84fa21
GIT binary patch
literal 127496
zcmd3P3w)F1z5ny((xz=%0u&mQOInH|6oD2UGL@t)P})=~7e!$s>BY3ko3<-u;D$3T
z=yWR%6ep(jETm;}pz1u^{)cUzvr^c`Q9QDXn=9;CP$nd;r1TOuo%w%%&-=bfTIyvx
z=l?nX^7-X`-{k%(05`KXvMa8_y>)ro&eP4>5V_7f5mRTXa&8
zJ`9sQcp>;7`I~Yp^IT3~9<@sNSgi(V09rr-AW``Eh3#@#nt!agmmg#vPWeBWzkY$q
z)5IQQd)c$h&pO%vVO{Jrdy8FUSD7Ff1e35>C=l)uoPtMqMtDg$CA=dr)lAi$D!b|t
z)lt=NRUfP7t2e8kP@hzPtY$1rTc*8R3qI@gNlgC({g3po=vmqi(tecoO4{CO9Z8yG
zmh$#@svsH0a+roKU^&79AxCwy5Mc{c5e5{@Q2!s>;$dFE_h1fyo&=T+U;U<~qVb!`
z(_lNc&0zaifb^Uzr>7^Szq|6Q-&_n(p7FTpUB>^+X#5X6YDYQtiU%GgeL?`NKVfJ1)1aG&%|
zVFYi;Pvv_R;vd|?JbM5K0Y3)326)p38UT~+%ySFiKEU@Pk@Vne!wsw1#v1(f-YImrx_-xQ_`mzwW*V@o1Qpf%CwnD6Em)#
z0a>ZFiAk!I)Cm(c`pHu=64KJAU9U4ty>3SGB;)j%jA?ZAmzkeE-5)hpPH7&*vz>z)6*xV>63K2#3>Wg
zl9Q9Jc_!%f2u@5)n35*NCq`4ozo8ED-+~3VFIX^p+D!bLuxMW9bklVyhS+o3bYuF2
z)R`1(oRGRGGjsav>r)M>`bG0*U-PD5OinI+MerN~eBs{&&-eaa@VtcQjd*Ic43udj
z{1?WN07y(oi11%6i{PC?D2$#FIiA&5KUnGBQc+>Aw>NAle{f5~165m=F3rs?2k)i0
zSjgMW&>z4>z-2%`U=Z*jV9qY)X`RYE&j6I?&*X3Ac~<^bo*&BJ^qgg6p4osK0rLS1
z0f(}f=U0HsfRxz?1JnTa0A2>X3HT6j@Sk8ufOi1G_kaiRO@9oYiF>E;UE{z{5Oy4}
z@LytZ2i{8nO@KcDE&^`+A@h6%K+pdGeETP`Wx&gT6M(aTi9bbs0E+PD3_>Ko*2I>+Ac_)AiPztygPy=}A*Ua-A;1R$fz#hO+z|#PgO0A;56adtlX+z92
z0gwsE1FQgCnJ##i&k#J%0ImQw%!HlIg)IR-1Z3VMcvb;Ef+PPc{#rDZ$MypD0}cS%
z06svaPGRG@dHJrAd{?J^)RT2-TNqknTgk+kjab
z#A_Jph^G$EY&<=H(^P-Gz_#NLeX$R8^~oRT%7hP)hj84>R}v3RhFL>irE7CDWD+{paQ7b2S`7m96bIJ0Frzh-(_Z&Sg+Esw@d>2wb`S_
zyNcfb>%U$}2EGTtF97I&y>-Vun&}S^zn0HJUA2KLe@g%`9=4om@SX_J0g?d802Z3S
zSZFzlp_eXVLWq4d0ZxGaganqx|CaW8xK4F3wVoA2ZmR(T$`HU?6+n%5HJ-B(z6bz3
zswH@8w23-&aoXQl9{Ff_
zqzviq2CM~`00QDv05w1hNB|@Pm;w0!YCsY|1JDBW02M$0qyiEEFhSOMZzEf^Z569u
zQO`0~WT5O&r2byKZ=-jX0Dex0eDrbT$=wFsqmTN?Z$IAo~Q6Uh35`Dci?#=()<|kuYkpX+hO}=Jf8qf-vJ2F8x`Ob%J~m~53m$v
zECSpHSO&Nqa0lQ{z;b{YkPj#X6aiKPiUB2n?Z6F&YS-ae4cHHSO8|=i*#HwgL4yg9
z1DFd~0$2oCinyhCz66pv0!KCERRe&IEU(|5x1QX2#`ZjTlf3PC;+sq;kDXA%
z|EkCbPiF#ucENx=f{MSJgt
zCm<2F@DQFm0YfN19r>pMG626r89J0Vf$ELC2LO>sSHvtZPb33A;{fw~9c69>2#8BZ
z{+$2=Kyt^CpZ_cJMj}@tRvz|nq%aBe0hZ$X3J;6Cfja)B9`7Fbf<8P!Un0Uj*n#p<
z{g00z>@W{kd5lZgF&%&b1b_-)0L;A@SyhkpjQ|tAmq5Qx^0FgWSO)wQKnKtO;Agtf
zL;~~x0ifzi;NhCCME=xuEk=2{fIPq=fN+-d%tv0J{N?05*b`WdPW|@n3-NhkydW
zLx6_?4S+WQy?}QCmjHc$5a9m+Ou(-OL?S{&i{~VS6^K>#hO&F1r;J%lr8PTB>nf{E
zmQ@9JEZQ-re4{Bpf1UJ(`25d^-?aMfk}usse|MG@-M3}+-34~Bro6%4ShZz!ZA~K|
z+B8&&b@oaVQkoj7wr&#}P32V&)HPJ)n5euRJdJftiK(&1T~)WOF*7qWnN?Pa_6N6A
z)NQM6G~Gezkc<#qlg1REhG(U8TN|tDrF=4ePG_0DvD&f)MQy3AYiy{pS3Za|b1HL8
z6p>F6i$}*Kv$%ZgHv;jN2kbTCs9a-$QJc6tYsb$sCU|rn31LH3W5a0j#)fmgjVcS|
zkIiP;vUX!h?lr;r6nt%J9vq)~Y#FQ8U7N|WW!1X)JPJFSXrPS0thVt%rL47KT3J+3v0Gs8;Gw7v!a@+}gNR&I~b8D$`m!
ze@JoyJu4a-qVENDu@5S@u6Erv;-U1u($3%E;w!2Nhaxuk@>M2|G{;oC%?+Je#T21#M!0Q+Z8R}P9-QLAcDA|@*@*v}7A;%yC7vLMe#iVE7h_OKj$r*N`2}I?
zSJlJ6#=c?8TFkhlSU
z*f-QuIg1MI+!#+KvJx**$|XF@fb@<#*TEM`p@mgzR<5L1t_Z-rmh?yRP4VWv
zws0}qP|ry$!^-v@w;~2`t>{3mhnDHVeR^c2iJnDR6TG3
zU+cCJI;7oDPhV6i9>sXtxNjc6a!h>OH*&8mi$$|CDB`j?+sOo|9I76FU%PJIYF<@h
zV2-3=tHqkq4N|epQG;y62_g&+k_aAk(u2owUtCrvirX5iDuJGr)>QJ`TqdjVYFf{o
z;2IabH}LoJ_4H1jRFePd2JRSgR!UDvo;)uX-b(%(mzB!lVTCdL3O1+}0wtc7a?6nm
zUBlDT59MNO7nw*^)~}}r;cKLqob`2$79Ozfn!G$4TiY-?UqxN*12v8<(iAJ^UhQr)
zZw*^&&`+Fu(=t<8LzQW3RbyjKtz(&~vSzEjT&yyY^EaX0H^K9p%Eh`0S2Fu7Jat#bvxwH;q%PQFLwHUV~oM
zmU8Hw!dE`Tx#s82Yxz1(-k3IHh-9*qt>!wyyOUhAKCA3yrj<14Xsk0y$W26;3F?9t
zltlaA%MWH$RoKyUG?6GtyTNp5R1L;Z4a9wt#OJK%x@{E|Ra>`yGO6))P*7ljg34Y1
z#lUU~xUrC}%tfO{*08#^@d0|mXi(Q2Se!Kax<(foVJU8mV?R}3E46ABIE3YaHoqOQwQ;UgWE1DXbS607@U6!
zwlV(aT0VXnFHBK+K&2G!j?18NEZ{Tv6R-T^h+*8KKh>_b*HkuEe~LbnHjkny

Re: [PATCH] staging: rtlwifi: Improve debugging by using debugfs

[Larry Finger]

On 08/24/2017 08:54 PM, Andrew Lunn wrote:

netdev frowns upon debugfs. You should try to keep this altogether,
making it easy to throw away before the driver is moved out of
staging.

You might want to look at ethtool -d. That will be accepted.


Andrew,

What is the problem with debugfs?

Please suggest which driver has the best example of an ethtool -d implementation 
that we might study.


The first version of the debugfs changes were sent to wireless-drivers on July 
2. Why are we first hearing of this objection nearly 2 months later?


Larry

[PATCH] staging: rtlwifi: Improve debugging by using debugfs

[Larry Finger]

The changes in this commit are also being sent to the main rtlwifi
drivers in wireless-next; however, these changes will also be useful for
any debugging of r8822be before it gets moved into the main tree.

Use debugfs to dump register and btcoex status, and also write registers
and h2c.

We create topdir in /sys/kernel/debug/rtlwifi/, and use the MAC address
as subdirectory with several entries to dump mac_reg, bb_reg, rf_reg etc.
An example is
/sys/kernel/debug/rtlwifi/00-11-22-33-44-55-66/mac_0

This change permits examination of device registers in a dynamic manner,
a feature not available with the current debug mechanism.

We use seq_file to replace RT_TRACE to dump status, then we can use 'cat'
to access btcoex's status through debugfs.
(i.e. /sys/kernel/debug/rtlwifi/00-11-22-33-44-55-66/btcoex)
Other related changes are
1. implement btc_disp_dbg_msg() to access btcoex's common status.
2. remove obsolete field bt_exist

Signed-off-by: Ping-Ke Shih 
Signed-off-by: Larry Finger 
Cc: Yan-Hsuan Chuang 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 
---
 drivers/staging/rtlwifi/debug.c | 226 
 1 file changed, 135 insertions(+), 91 deletions(-)

diff --git a/drivers/staging/rtlwifi/debug.c b/drivers/staging/rtlwifi/debug.c
index b9fd47aeaa9b..7446d71c41d1 100644
--- a/drivers/staging/rtlwifi/debug.c
+++ b/drivers/staging/rtlwifi/debug.c
@@ -80,9 +80,11 @@ void _rtl_dbg_print_data(struct rtl_priv *rtlpriv, u64 comp, 
int level,
}
 }
 
-struct rtl_debgufs_priv {
+struct rtl_debugfs_priv {
struct rtl_priv *rtlpriv;
-   int (*cb)(struct seq_file *m, void *v);
+   int (*cb_read)(struct seq_file *m, void *v);
+   ssize_t (*cb_write)(struct file *filp, const char __user *buffer,
+   size_t count, loff_t *loff);
u32 cb_data;
 };
 
@@ -90,9 +92,9 @@ static struct dentry *debugfs_topdir;
 
 static int rtl_debug_get_common(struct seq_file *m, void *v)
 {
-   struct rtl_debgufs_priv *debugfs_priv = m->private;
+   struct rtl_debugfs_priv *debugfs_priv = m->private;
 
-   return debugfs_priv->cb(m, v);
+   return debugfs_priv->cb_read(m, v);
 }
 
 static int dl_debug_open_common(struct inode *inode, struct file *file)
@@ -109,7 +111,7 @@ static const struct file_operations file_ops_common = {
 
 static int rtl_debug_get_mac_page(struct seq_file *m, void *v)
 {
-   struct rtl_debgufs_priv *debugfs_priv = m->private;
+   struct rtl_debugfs_priv *debugfs_priv = m->private;
struct rtl_priv *rtlpriv = debugfs_priv->rtlpriv;
u32 page = debugfs_priv->cb_data;
int i, n;
@@ -126,8 +128,8 @@ static int rtl_debug_get_mac_page(struct seq_file *m, void 
*v)
 }
 
 #define RTL_DEBUG_IMPL_MAC_SERIES(page, addr)  \
-struct rtl_debgufs_priv rtl_debug_priv_mac_ ##page = { \
-   .cb = rtl_debug_get_mac_page,   \
+struct rtl_debugfs_priv rtl_debug_priv_mac_ ##page = { \
+   .cb_read = rtl_debug_get_mac_page,  \
.cb_data = addr,\
 }
 
@@ -150,7 +152,7 @@ RTL_DEBUG_IMPL_MAC_SERIES(17, 0x1700);
 
 static int rtl_debug_get_bb_page(struct seq_file *m, void *v)
 {
-   struct rtl_debgufs_priv *debugfs_priv = m->private;
+   struct rtl_debugfs_priv *debugfs_priv = m->private;
struct rtl_priv *rtlpriv = debugfs_priv->rtlpriv;
struct ieee80211_hw *hw = rtlpriv->hw;
u32 page = debugfs_priv->cb_data;
@@ -168,8 +170,8 @@ static int rtl_debug_get_bb_page(struct seq_file *m, void 
*v)
 }
 
 #define RTL_DEBUG_IMPL_BB_SERIES(page, addr)   \
-struct rtl_debgufs_priv rtl_debug_priv_bb_ ##page = {  \
-   .cb = rtl_debug_get_bb_page,\
+struct rtl_debugfs_priv rtl_debug_priv_bb_ ##page = {  \
+   .cb_read = rtl_debug_get_bb_page,   \
.cb_data = addr,\
 }
 
@@ -192,7 +194,7 @@ RTL_DEBUG_IMPL_BB_SERIES(1f, 0x1f00);
 
 static int rtl_debug_get_reg_rf(struct seq_file *m, void *v)
 {
-   struct rtl_debgufs_priv *debugfs_priv = m->private;
+   struct rtl_debugfs_priv *debugfs_priv = m->private;
struct rtl_priv *rtlpriv = debugfs_priv->rtlpriv;
struct ieee80211_hw *hw = rtlpriv->hw;
enum radio_path rfpath = debugfs_priv->cb_data;
@@ -215,8 +217,8 @@ static int rtl_debug_get_reg_rf(struct seq_file *m, void *v)
 }
 
 #define RTL_DEBUG_IMPL_RF_SERIES(page, addr)   \
-struct rtl_debgufs_priv rtl_debug_priv_rf_ ##page = {  \
-   .cb = rtl_debug_get_reg_rf, \
+struct rtl_debugfs_priv rtl_debug_priv_rf_ ##page = {  \
+   .cb_read = rtl_debug_get_reg_rf,\
.cb_data = addr,\
 }
 
@@ -225,7 +227,7 @@ RTL_DEBUG_IMPL_RF_SERIES(b, RF90_PATH_B);
 
 static int rtl_debug_get_cam_register(struct seq_file *m, void *v)
 {
-   struct rt

Re: Thoughts on staging and on fixing up drivers?

[Larry Finger]

On 08/17/2017 04:07 PM, tedheadster wrote:


Larry, you've migrated a bunch of staging code, and tried various
approaches.  Do you have any lessons on what has worked and what hasn't
and if there is anything we can do to make the process better?


I am also quite interested in such work. We asked for a Birds of
Feather discussion at the upcoming Linux Plumbers conference on
exactly this sort of work.


Matthew and Dan,

I will try to answer the question as best I can.

I got started in working with Realtek wireless devices at roughly the time that 
staging was created. At that time, Realtek published drivers sporadically. They 
would accumulate fixes in their internal svn repositories, then take a snapshot, 
and publish that with no information regarding what was changed. Even trying to 
diff the two versions was not useful. Obviously this mode of code development is 
not consistent with the Linux model.


After I was able to get driver r8712u into staging, I received an E-mail from 
Realtek asking if I would be willing to help them get their drivers into the 
kernel. They have provided sample chips and extenders to let me test drivers on 
my laptops, but I have not gotten any remuneration from Realtek. This 
collaboration has led to the rtlwifi family of drivers. A few of them have gone 
through staging because there was some urgency in getting them added to Linux. 
That is the case for today's submission of a driver for the RTL8822BE, which is 
appearing in some computers. This particular device implements a new Realtek 
model for hardware abstraction of the MAC, PHY, and dynamic management 
functions, which has increased the number of new lines of code to about 120K. 
Getting that much new code through the review process in the wireless tree would 
take a lot of time. Essentially, staging allows users to have access to the 
functionality while that review is in progress. Another card now appearing in 
the wild is the RTL8723DE. It will likely also reside initially in staging.


Besides getting wifi drivers for these cards into Linux, I have also been 
training the Realtek engineers and getting them to issue fixes as many small 
changes. That part of my "job" has been going very well, and I will soon be 
getting them to submit their material directly. That change is necessary as I am 
now 77, with the question of how long I will be continuing.


As you can tell, I am very pleased with the staging tree and its usage for new 
drivers, particularly where the regular trees move more slowly than the 
marketplace. Staging is a big help in supporting the users that otherwise will 
have no wifi under Linux. Their distro may not build staging drivers in their 
standard kernels, but configuring and building kernels is not too difficult.


The part that does not work is best exemplified by the driver that got me 
started, namely r8712u. The USB section at Realtek has not been as cooperative 
as the PCI/SDIO group. As a result, there is no path from staging to wireless 
and that driver will be left in staging as long as GregKH allows it. Now, I put 
that sort of material in a GitHub repo and force users to build it as an 
out-of-kernel driver. Of course, that method has its own problems. How many 
times a week do you want to tell another user that they need to install the 
kernel-headers, and no, I do not know how to do it on your distro. Now we have 
one example (rtl8723bs) where the GitHub driver was placed in staging. That one 
is likely to be moved to wireless.


This reply is getting rather long. I will be happy to answer any further 
questions.

Larry

[PATCH 8/8] staging: rtlwifi: Reviewers fixes

[Larry Finger]

This commit adds the TODO file and implements some reviewers comments
made against some patches to the wireless tree.

Signed-off-by: Larry Finger 
Cc: Ping-Ke Shih 
Cc: Yan-Hsuan Chuang 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 
---
 drivers/staging/rtlwifi/TODO |  8 
 drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c | 23 +++
 drivers/staging/rtlwifi/debug.c  |  5 +
 drivers/staging/rtlwifi/rtl8822be/sw.c   |  2 +-
 4 files changed, 17 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/rtlwifi/TODO b/drivers/staging/rtlwifi/TODO
index 52a85cdf453c..4a084f2fc5d0 100644
--- a/drivers/staging/rtlwifi/TODO
+++ b/drivers/staging/rtlwifi/TODO
@@ -1,11 +1,11 @@
 TODO:
-- checkpatch.pl fixes - most of the remaining ones are lines too long. Many
-  of them will require refactoring
-- merge Realtek's bugfixes and new features into the driver
 - find and remove code blocks guarded by never set CONFIG_FOO defines
 - convert any remaining unusual variable types
 - find codes that can use %pM and %Nph formatting
-- fix any reviewer's comments regarding movin the driver to 
drivers/net/wireless
+- checkpatch.pl fixes - most of the remaining ones are lines too long. Many
+  of them will require refactoring
+- merge Realtek's bugfixes and new features into the driver
+- address any reviewers comments
 
 Please send any patches to Greg Kroah-Hartman ,
 and Larry Finger .
diff --git a/drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c
index 39229cdb8045..52620b72cfa9 100644
--- a/drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -791,18 +791,17 @@ static void halbtc_display_wifi_status(struct btc_coexist 
*btcoexist,
   struct seq_file *m)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
-   s32 wifi_rssi = 0, bt_hs_rssi = 0;
-   boolscan = false, link = false, roam = false, wifi_busy = false,
-   wifi_under_b_mode = false,
-   wifi_under_5g = false;
-   u32 wifi_bw = BTC_WIFI_BW_HT20,
-   wifi_traffic_dir = BTC_WIFI_TRAFFIC_TX,
-   wifi_freq = BTC_FREQ_2_4G;
-   u32 wifi_link_status = 0x0;
-   boolbt_hs_on = false, under_ips = false, under_lps = false,
-   low_power = false, dc_mode = false;
-   u8  wifi_chnl = 0, wifi_hs_chnl = 0, fw_ps_state;
-   u8  ap_num = 0;
+   s32 wifi_rssi = 0, bt_hs_rssi = 0;
+   bool scan = false, link = false, roam = false, wifi_busy = false;
+   bool wifi_under_b_mode = false, wifi_under_5g = false;
+   u32 wifi_bw = BTC_WIFI_BW_HT20;
+   u32 wifi_traffic_dir = BTC_WIFI_TRAFFIC_TX;
+   u32 wifi_freq = BTC_FREQ_2_4G;
+   u32 wifi_link_status = 0x0;
+   bool bt_hs_on = false, under_ips = false, under_lps = false;
+   bool low_power = false, dc_mode = false;
+   u8 wifi_chnl = 0, wifi_hs_chnl = 0, fw_ps_state;
+   u8 ap_num = 0;
 
wifi_link_status = halbtc_get_wifi_link_status(btcoexist);
seq_printf(m, "\n %-35s = %d/ %d/ %d/ %d/ %d",
diff --git a/drivers/staging/rtlwifi/debug.c b/drivers/staging/rtlwifi/debug.c
index ed26267393be..b9fd47aeaa9b 100644
--- a/drivers/staging/rtlwifi/debug.c
+++ b/drivers/staging/rtlwifi/debug.c
@@ -511,10 +511,7 @@ void rtl_debug_add_one(struct ieee80211_hw *hw)
 
rtlpriv->dbg.msg_buf = vzalloc(80 * 25);
 
-   snprintf(rtlpriv->dbg.debugfs_name, 18, "%02x-%02x-%02x-%02x-%02x-%02x",
-rtlefuse->dev_addr[0], rtlefuse->dev_addr[1],
-rtlefuse->dev_addr[2], rtlefuse->dev_addr[3],
-rtlefuse->dev_addr[4], rtlefuse->dev_addr[5]);
+   snprintf(rtlpriv->dbg.debugfs_name, 18, "%pMF", rtlefuse->dev_addr);
 
rtlpriv->dbg.debugfs_dir =
debugfs_create_dir(rtlpriv->dbg.debugfs_name, debugfs_topdir);
diff --git a/drivers/staging/rtlwifi/rtl8822be/sw.c 
b/drivers/staging/rtlwifi/rtl8822be/sw.c
index 913fec4f1eea..91b784b6d1c5 100644
--- a/drivers/staging/rtlwifi/rtl8822be/sw.c
+++ b/drivers/staging/rtlwifi/rtl8822be/sw.c
@@ -432,7 +432,7 @@ static struct rtl_hal_cfg rtl8822be_hal_cfg = {
.maps[RTL_RC_VHT_RATE_2SS_MCS9] = DESC_RATEVHT2SS_MCS9,
 };
 
-static struct pci_device_id rtl8822be_pci_ids[] = {
+static const struct pci_device_id rtl8822be_pci_ids[] = {
{RTL_PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0xB822, rtl8822be_hal_cfg)},
{},
 };
-- 
2.12.3

[PATCH 7/8] staging: r8822be: Add Makefiles and Kconfig for new driver

[Larry Finger]

The RTL8822BE, an 802.11ac wireless network card, is now appearing in
new computers. Its driver is being placed in staging to reduce the time
that users of this new card will have access to in-kernel drivers.

This commit enables building of the new driver. For this version, all
routines are built into a single module r8822be. When this driver is
moved to the wireless tree, halmac, phydm, and rtl8822be will become
new modules.

Signed-off-by: Larry Finger 
Cc: Ping-Ke Shih 
Cc: Yan-Hsuan Chuang 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 
---
 drivers/staging/Kconfig   |   2 +
 drivers/staging/Makefile  |   1 +
 drivers/staging/rtlwifi/Kconfig   |  22 ++
 drivers/staging/rtlwifi/Makefile  |  70 ++
 drivers/staging/rtlwifi/TODO  |  11 +
 drivers/staging/rtlwifi/btcoexist/Makefile|   8 +
 drivers/staging/rtlwifi/btcoexist/halbt_precomp.h |   5 -
 drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c  | 257 ++
 drivers/staging/rtlwifi/rtl8822be/Makefile|   7 +
 9 files changed, 137 insertions(+), 246 deletions(-)
 create mode 100644 drivers/staging/rtlwifi/Kconfig
 create mode 100644 drivers/staging/rtlwifi/Makefile
 create mode 100644 drivers/staging/rtlwifi/TODO
 create mode 100644 drivers/staging/rtlwifi/btcoexist/Makefile
 create mode 100644 drivers/staging/rtlwifi/rtl8822be/Makefile

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index e97d72e3bc40..1b0a1bed8e11 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -40,6 +40,8 @@ source "drivers/staging/rtl8712/Kconfig"
 
 source "drivers/staging/rtl8188eu/Kconfig"
 
+source "drivers/staging/rtlwifi/Kconfig"
+
 source "drivers/staging/rts5208/Kconfig"
 
 source "drivers/staging/octeon/Kconfig"
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 993ed0c1556c..2b61cbd44d13 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_RTL8192E)+= rtl8192e/
 obj-$(CONFIG_RTL8723BS)+= rtl8723bs/
 obj-$(CONFIG_R8712U)   += rtl8712/
 obj-$(CONFIG_R8188EU)  += rtl8188eu/
+obj-$(CONFIG_R8822BE)  += rtlwifi/
 obj-$(CONFIG_RTS5208)  += rts5208/
 obj-$(CONFIG_NETLOGIC_XLR_NET) += netlogic/
 obj-$(CONFIG_OCTEON_ETHERNET)  += octeon/
diff --git a/drivers/staging/rtlwifi/Kconfig b/drivers/staging/rtlwifi/Kconfig
new file mode 100644
index ..fc482b49f9aa
--- /dev/null
+++ b/drivers/staging/rtlwifi/Kconfig
@@ -0,0 +1,22 @@
+config R8822BE
+   tristate "Realtek RTL8822BE Wireless Network Adapter"
+   depends on PCI && m
+   select FW_LOADER
+   ---help---
+   This is the staging driver for Realtek RTL8822BE 802.11ac PCIe
+   wireless network adapters.
+
+config RTLHALMAC_ST
+   tristate
+   depends on R8822BE
+   default m
+
+config RTLPHYDM_ST
+   tristate
+   depends on R8822BE
+   default m
+
+config RTLWIFI_DEBUG_ST
+   boolean
+   depends on R8822BE
+   default y
diff --git a/drivers/staging/rtlwifi/Makefile b/drivers/staging/rtlwifi/Makefile
new file mode 100644
index ..0d738c18b29c
--- /dev/null
+++ b/drivers/staging/rtlwifi/Makefile
@@ -0,0 +1,70 @@
+obj-$(CONFIG_R8822BE)  += r8822be.o
+
+r8822be-objs   :=  \
+   base.o  \
+   cam.o   \
+   core.o  \
+   debug.o \
+   efuse.o \
+   ps.o\
+   rc.o\
+   regd.o  \
+   stats.o \
+   pci.o   \
+   rtl8822be/fw.o  \
+   rtl8822be/hw.o  \
+   rtl8822be/led.o \
+   rtl8822be/phy.o \
+   rtl8822be/sw.o  \
+   rtl8822be/trx.o \
+   btcoexist/halbtc8822b2ant.o \
+   btcoexist/halbtc8822b1ant.o \
+   btcoexist/halbtc8822bwifionly.o \
+   btcoexist/halbtcoutsrc.o\
+   btcoexist/rtl_btc.o \
+   halmac/halmac_api.o \
+   halmac/halmac_88xx/halmac_api_88xx_usb.o\
+   halmac/halmac_88xx/halmac_api_88xx_sdio.o   \
+   halmac/halmac_88xx/halmac_api_88xx.o\
+   halmac/halmac_88xx/halmac_api_88xx_pcie.o   \
+   halmac/halmac_88xx/halmac_func_88xx.o   \
+   halmac/halmac_88xx/halmac_8822b/halmac_api_8822b_pcie.o \
+   halmac/halmac_88xx/halmac_8822b/halmac_func_8822b.o \
+   halmac/halmac_88xx/halmac_8822b/halmac_api_8822b_sdio.o \
+   halmac/halmac_88xx/halmac_8822b/halmac_api_8822b.o  \
+   halmac/halmac_88xx/halmac_8822b/halmac_8822b_phy.o  \
+ 

[PATCH 2/8] staging: r8822be: Copy existing btcoexist code into staging

[Larry Finger]

The RTL8822BE, an 802.11ac wireless network card, is now appearing in
new computers. Its driver is being placed in staging to reduce the time
that users of this new card will have access to in-kernel drivers.

This commit copies the existing routines from .../rtlwifi/btcoexist/
into staging. There are no changes other than removing all EXPORT
statements, and the fixing of checkpatch messages. The latter will
be backported to the wireless tree.

Signed-off-by: Larry Finger 
Cc: Ping-Ke Shih 
Cc: Yan-Hsuan Chuang 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 
---
 drivers/staging/rtlwifi/btcoexist/halbt_precomp.h |   90 +
 drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c  | 2107 +
 drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.h  |  802 
 drivers/staging/rtlwifi/btcoexist/rtl_btc.c   |  528 ++
 drivers/staging/rtlwifi/btcoexist/rtl_btc.h   |   75 +
 5 files changed, 3602 insertions(+)
 create mode 100644 drivers/staging/rtlwifi/btcoexist/halbt_precomp.h
 create mode 100644 drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c
 create mode 100644 drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.h
 create mode 100644 drivers/staging/rtlwifi/btcoexist/rtl_btc.c
 create mode 100644 drivers/staging/rtlwifi/btcoexist/rtl_btc.h

diff --git a/drivers/staging/rtlwifi/btcoexist/halbt_precomp.h 
b/drivers/staging/rtlwifi/btcoexist/halbt_precomp.h
new file mode 100644
index ..1cd3ce54b6a2
--- /dev/null
+++ b/drivers/staging/rtlwifi/btcoexist/halbt_precomp.h
@@ -0,0 +1,90 @@
+/**
+ *
+ * Copyright(c) 2007 - 2011 Realtek Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * The full GNU General Public License is included in this distribution in the
+ * file called LICENSE.
+ *
+ * Contact Information:
+ * wlanfae 
+ * Realtek Corporation, No. 2, Innovation Road II, Hsinchu Science Park,
+ * Hsinchu 300, Taiwan.
+ * Larry Finger 
+ *
+ 
**/
+
+#ifndef__HALBT_PRECOMP_H__
+#define __HALBT_PRECOMP_H__
+/*
+ * include files
+ */
+#include "../wifi.h"
+#include "../efuse.h"
+#include "../base.h"
+#include "../regd.h"
+#include "../cam.h"
+#include "../ps.h"
+#include "../pci.h"
+
+#include "halbtcoutsrc.h"
+
+/* Interface type */
+#define RT_PCI_INTERFACE   1
+#define RT_USB_INTERFACE   2
+#define RT_SDIO_INTERFACE  3
+#define DEV_BUS_TYPE   RT_PCI_INTERFACE
+
+#include "halbtc8192e2ant.h"
+#include "halbtc8723b1ant.h"
+#include "halbtc8723b2ant.h"
+#include "halbtc8821a2ant.h"
+#include "halbtc8821a1ant.h"
+#include "halbtc8822b1ant.h"
+#include "halbtc8822b2ant.h"
+#include "halbtc8822bwifionly.h"
+
+#define GETDEFAULTADAPTER(padapter)padapter
+
+#define BIT0   0x0001
+#define BIT1   0x0002
+#define BIT2   0x0004
+#define BIT3   0x0008
+#define BIT4   0x0010
+#define BIT5   0x0020
+#define BIT6   0x0040
+#define BIT7   0x0080
+#define BIT8   0x0100
+#define BIT9   0x0200
+#define BIT10  0x0400
+#define BIT11  0x0800
+#define BIT12  0x1000
+#define BIT13  0x2000
+#define BIT14  0x4000
+#define BIT15  0x8000
+#define BIT16  0x0001
+#define BIT17  0x0002
+#define BIT18  0x0004
+#define BIT19  0x0008
+#define BIT20  0x0010
+#define BIT21  0x0020
+#define BIT22  0x0040
+#define BIT23  0x0080
+#define BIT24  0x0100
+#define BIT25  0x0200
+#define BIT26  0x0400
+#define BIT27  0x0800
+#define BIT28  0x1000
+#define BIT29  0x2000
+#define BIT30  0x4000
+#define BIT31  0x8000
+
+#endif /* __HALBT_PRECOMP_H__ */
diff --git a/drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c
new file mode 100644
index ..e5c25c0babfb
--- /dev/null
+++ b/drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -0,0 +1,2107 @@
+/**
+ *
+ * Copyright(c) 2007 - 2013 Realtek Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License as
+ * published

[PATCH 0/8] staging: Add new driver for RTL8822BE

[Larry Finger]

The RTL8822BE, an 802.11ac wireless network card, is now appearing in
new computers. Its driver is being placed in staging to reduce the time
that users of this new card will have access to in-kernel drivers.

Residence in staging should be relatively short as we soon plan to start
introducing the code into the main wireless tree in small pieces.

To minimize interference between the rtlwifi drivers in the wireless tree
and this new driver, the new one can only be built as a module. In
addition, all code is built into a single module.

Larry Finger

Signed-off-by: Larry Finger 
Cc: Ping-Ke Shih 
Cc: Yan-Hsuan Chuang 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 

Larry Finger (8):
  staging: r8822be: Add existing rtlwifi and rtl_pci parts for new
driver
  staging: r8822be: Copy existing btcoexist code into staging
  staging: r8822be: Add r8822be btcoexist routines to staging
  staging: r8822be: Add code for halmac sub-driver
  staging: r8822be: Add phydm mini driver
  staging: r8822be: Add the driver code
  staging: r8822be: Add Makefiles and Kconfig for new driver
  staging: rtlwifi: Reviewers fixes

 drivers/staging/Kconfig| 2 +
 drivers/staging/Makefile   | 1 +
 drivers/staging/rtlwifi/Kconfig|22 +
 drivers/staging/rtlwifi/Makefile   |70 +
 drivers/staging/rtlwifi/TODO   |11 +
 drivers/staging/rtlwifi/base.c |  2826 
 drivers/staging/rtlwifi/base.h |   186 +
 drivers/staging/rtlwifi/btcoexist/Makefile | 8 +
 drivers/staging/rtlwifi/btcoexist/halbt_precomp.h  |85 +
 .../staging/rtlwifi/btcoexist/halbtc8822b1ant.c|  5246 
 .../staging/rtlwifi/btcoexist/halbtc8822b1ant.h|   444 +
 .../staging/rtlwifi/btcoexist/halbtc8822b2ant.c|  5225 
 .../staging/rtlwifi/btcoexist/halbtc8822b2ant.h|   498 +
 .../rtlwifi/btcoexist/halbtc8822bwifionly.c|65 +
 .../rtlwifi/btcoexist/halbtc8822bwifionly.h|35 +
 drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c   |  1881 +++
 drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.h   |   802 ++
 drivers/staging/rtlwifi/btcoexist/rtl_btc.c|   528 +
 drivers/staging/rtlwifi/btcoexist/rtl_btc.h|75 +
 drivers/staging/rtlwifi/cam.c  |   326 +
 drivers/staging/rtlwifi/cam.h  |50 +
 drivers/staging/rtlwifi/core.c |  2046 +++
 drivers/staging/rtlwifi/core.h |86 +
 drivers/staging/rtlwifi/debug.c|   592 +
 drivers/staging/rtlwifi/debug.h|   234 +
 drivers/staging/rtlwifi/efuse.c|  1342 ++
 drivers/staging/rtlwifi/efuse.h|   120 +
 drivers/staging/rtlwifi/halmac/halmac_2_platform.h |52 +
 .../halmac_88xx/halmac_8822b/halmac_8822b_cfg.h|   132 +
 .../halmac_88xx/halmac_8822b/halmac_8822b_phy.c|   106 +
 .../halmac_8822b/halmac_8822b_pwr_seq.c|   563 +
 .../halmac_8822b/halmac_8822b_pwr_seq.h|40 +
 .../halmac_88xx/halmac_8822b/halmac_api_8822b.c|   343 +
 .../halmac_88xx/halmac_8822b/halmac_api_8822b.h|44 +
 .../halmac_8822b/halmac_api_8822b_pcie.c   |   323 +
 .../halmac_8822b/halmac_api_8822b_pcie.h   |53 +
 .../halmac_8822b/halmac_api_8822b_sdio.c   |   184 +
 .../halmac_8822b/halmac_api_8822b_sdio.h   |42 +
 .../halmac_8822b/halmac_api_8822b_usb.c|   185 +
 .../halmac_8822b/halmac_api_8822b_usb.h|45 +
 .../halmac_88xx/halmac_8822b/halmac_func_8822b.c   |   414 +
 .../halmac_88xx/halmac_8822b/halmac_func_8822b.h   |38 +
 .../rtlwifi/halmac/halmac_88xx/halmac_88xx_cfg.h   |   171 +
 .../rtlwifi/halmac/halmac_88xx/halmac_api_88xx.c   |  5980 +
 .../rtlwifi/halmac/halmac_88xx/halmac_api_88xx.h   |   396 +
 .../halmac/halmac_88xx/halmac_api_88xx_pcie.c  |   329 +
 .../halmac/halmac_88xx/halmac_api_88xx_pcie.h  |71 +
 .../halmac/halmac_88xx/halmac_api_88xx_sdio.c  |   974 ++
 .../halmac/halmac_88xx/halmac_api_88xx_sdio.h  |84 +
 .../halmac/halmac_88xx/halmac_api_88xx_usb.c   |   554 +
 .../halmac/halmac_88xx/halmac_api_88xx_usb.h   |73 +
 .../rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c  |  4499 +++
 .../rtlwifi/halmac/halmac_88xx/halmac_func_88xx.h  |   321 +
 drivers/staging/rtlwifi/halmac/halmac_api.c|   426 +
 drivers/staging/rtlwifi/halmac/halmac_api.h|82 +
 drivers/staging/rtlwifi/halmac/halmac_bit2.h   | 13407 +++
 drivers/staging/rtlwifi/halmac/halmac_bit_8822b.h  | 12103 +
 drivers/staging/rtlwifi/halmac/halmac_fw_info.h|   122 +
 .../rtlwifi/halmac/halmac_fw_offload_c2h_nic.h |   184 +
 .../rtlwifi/halmac/halmac_fw_offload_h2c_nic.h |   515 +
 .../rtlwifi/halmac/halmac_h2c_extra_info_nic.h |   115 +
 .../staging/rtlwifi

Re: [PATCH 33/35] wireless: realtek: rtl8192cu: constify usb_device_id

[Larry Finger]

On 08/08/2017 11:05 AM, Arvind Yadav wrote:

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---


Acked-by: Larry Finger 

Thanks,

Larry


  drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
index 96c923b..e673bc2 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
@@ -275,7 +275,7 @@ static struct rtl_hal_cfg rtl92cu_hal_cfg = {
  #define USB_VENDER_ID_REALTEK 0x0bda
  
  /* 2010-10-19 DID_USB_V3.4 */

-static struct usb_device_id rtl8192c_usb_ids[] = {
+static const struct usb_device_id rtl8192c_usb_ids[] = {
  
  	/*=== Realtek demoboard ===*/

/* Default ID */

Re: [PATCH] rtlwifi: remove useless code

[Larry Finger]

On 07/18/2017 03:41 PM, Gustavo A. R. Silva wrote:

Remove useless local variables last_read_point and last_txw_point and
the code related.

Signed-off-by: Gustavo A. R. Silva 
---
  drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c | 6 --
  1 file changed, 6 deletions(-)


Acked-by: Larry Finger 

Thanks,

Larry

Re: [PATCH 01/11] rtlwifi: rtl8192de: constify pci_device_id.

[Larry Finger]

On 07/17/2017 01:09 PM, Arvind Yadav wrote:

pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by  work with
const pci_device_id. So mark the non-const structs as const.

File size before:
text   data bss dec hex filename
2833945  123790 ece realtek/rtlwifi/rtl8192de/sw.o

File size After adding 'const':
text   data bss dec hex filename
2929849  123790 ece realtek/rtlwifi/rtl8192de/sw.o

Signed-off-by: Arvind Yadav 


Acked-by: Larry Finger 

This applies to all 11.

Thanks,

Larry

Re: [PATCH 0/5] rtlwifi: Neatening

[Larry Finger]

On 06/19/2017 03:18 PM, Joe Perches wrote:

Joe Perches (5):
   rtlwifi: Use temporary ops variable to reduce code size
   rtlwifi: Use temporary variable btc_ops for rtlpriv->btcoexist.btc_ops
   rtlwifi: Add and use convenience macro rtl_btc
   realtek: btcoexist: Make the rtl_btc_ops struct const
   realtek: rtlwifi: drivers: Use the rtl_btc convenience macro

  drivers/net/wireless/realtek/rtlwifi/base.c|  46 ++--
  .../wireless/realtek/rtlwifi/btcoexist/rtl_btc.c   |   4 +-
  .../wireless/realtek/rtlwifi/btcoexist/rtl_btc.h   |   2 +-
  drivers/net/wireless/realtek/rtlwifi/core.c| 189 
  drivers/net/wireless/realtek/rtlwifi/efuse.c   |   9 +-
  drivers/net/wireless/realtek/rtlwifi/pci.c | 242 +++--
  drivers/net/wireless/realtek/rtlwifi/ps.c  |  83 +++
  .../net/wireless/realtek/rtlwifi/rtl8192ee/hw.c|   3 +-
  .../wireless/realtek/rtlwifi/rtl8723ae/hal_btc.c   |   4 +-
  .../net/wireless/realtek/rtlwifi/rtl8723ae/hw.c|   3 +-
  .../net/wireless/realtek/rtlwifi/rtl8723be/hw.c|   3 +-
  .../net/wireless/realtek/rtlwifi/rtl8821ae/fw.c|   6 +-
  .../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c|   3 +-
  drivers/net/wireless/realtek/rtlwifi/usb.c |  40 ++--
  drivers/net/wireless/realtek/rtlwifi/wifi.h|   9 +-
  15 files changed, 336 insertions(+), 310 deletions(-)



Joe,

In general, I approve of your patches. Unfortunately, they will conflict with a 
number of changes that I am currently making. If you would like, I can merge 
your patches, fix the conflicts, and submit a version 2 for you.


Larry

Re: [PATCH] rtlwifi: rtl8821ae: remove unused variable

[Larry Finger]

On 06/13/2017 03:42 PM, Gustavo A. R. Silva wrote:

Remove unused variable rtlhal.

Addresses-Coverity-ID: 1248810
Signed-off-by: Gustavo A. R. Silva 
---


NACK!! That variable is used in file core.c in driver rtlwifi, which is loaded 
and used by rtl8821ae.


Please do more than blindly follow Coverity outputs, or improve that tool!

Larry


  drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 3 ---
  1 file changed, 3 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
index 2bc6bac..d158e34 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
@@ -1360,7 +1360,6 @@ static bool _rtl8821ae_reset_pcie_interface_dma(struct 
ieee80211_hw *hw,
  static void _rtl8821ae_get_wakeup_reason(struct ieee80211_hw *hw)
  {
struct rtl_priv *rtlpriv = rtl_priv(hw);
-   struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
struct rtl_ps_ctl *ppsc = rtl_psc(rtlpriv);
u8 fw_reason = 0;
struct timeval ts;
@@ -1372,8 +1371,6 @@ static void _rtl8821ae_get_wakeup_reason(struct 
ieee80211_hw *hw)
  
  	ppsc->wakeup_reason = 0;
  
-	rtlhal->last_suspend_sec = ts.tv_sec;

-
switch (fw_reason) {
case FW_WOW_V2_PTK_UPDATE_EVENT:
ppsc->wakeup_reason = WOL_REASON_PTK_UPDATE;

Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_attr_interfmode_store

[Larry Finger]

On 06/01/2017 11:11 AM, Jonathan Corbet wrote:

On Thu, 01 Jun 2017 09:05:07 +0800
Jia-Ju Bai  wrote:


I admit my patches are not well tested, and they may not well fix the bugs.
I am looking forward to opinions and suggestions :)


May I politely suggest that sending out untested locking changes is a
dangerous thing to do?  You really should not be changing the locking in a
piece of kernel code without understanding very well what the lock is
protecting and being able to say why your changes are safe.  Without that,
the risk of introducing subtle bugs is very high.

It looks like you have written a useful tool that could help us to make
the kernel more robust.  If you are interested in my suggestion, I would
recommend that you post the sleep-in-atomic scenarios that you are
finding, but refrain from "fixing" them in any case where you cannot offer
a strong explanation of why your fix is correct.

Thanks for working to find bugs in the kernel!


I agree with the suggestion above. Locking changes should only be done in 
conjunction with testing by someone that actually has the hardware.


Larry

Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed

[Larry Finger]

On 05/31/2017 10:32 AM, Michael Büsch wrote:

On Wed, 31 May 2017 13:26:43 +0300
Kalle Valo  wrote:


Jia-Ju Bai  writes:


The driver may sleep under a spin lock, and the function call path is:
b43legacy_op_bss_info_changed (acquire the lock by spin_lock_irqsave)
   b43legacy_synchronize_irq
 synchronize_irq --> may sleep

To fix it, the lock is released before b43legacy_synchronize_irq, and the
lock is acquired again after this function.

Signed-off-by: Jia-Ju Bai 
---
  drivers/net/wireless/broadcom/b43legacy/main.c |2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/broadcom/b43legacy/main.c 
b/drivers/net/wireless/broadcom/b43legacy/main.c
index f1e3dad..31ead21 100644
--- a/drivers/net/wireless/broadcom/b43legacy/main.c
+++ b/drivers/net/wireless/broadcom/b43legacy/main.c
@@ -2859,7 +2859,9 @@ static void b43legacy_op_bss_info_changed(struct 
ieee80211_hw *hw,
b43legacy_write32(dev, B43legacy_MMIO_GEN_IRQ_MASK, 0);
  
  	if (changed & BSS_CHANGED_BSSID) {

+   spin_unlock_irqrestore(&wl->irq_lock, flags);
b43legacy_synchronize_irq(dev);
+   spin_lock_irqsave(&wl->irq_lock, flags);


To me this looks like a fragile workaround and not a real fix. You can
easily add new race conditions with releasing the lock like this.




I think releasing the lock possibly is fine. It certainly is better than
sleeping with a lock held.
We disabled the device interrupts just before this line.

However I think the synchronize_irq should be outside of the
conditional right after the write to B43legacy_MMIO_GEN_IRQ_MASK. (So
two lines above)
I don't think it makes sense to only synchronize if BSS_CHANGED_BSSID
is set.


On the other hand b43 does not have this irq-disabling foobar anymore.
So somebody must have removed it. Maybe you can find the commit that
removed this stuff from b43 and port it to b43legacy?


So I would vote for moving the synchronize_irq up outside of the
conditional and put the unlock/lock sequence around it.
And as a second patch on top of that try to remove this stuff
altogether like b43 did.


The patch that removed it in b43 is

commit 36dbd9548e92268127b0c31b0e121e63e9207108
Author: Michael Buesch 
Date:   Fri Sep 4 22:51:29 2009 +0200

b43: Use a threaded IRQ handler

Use a threaded IRQ handler to allow locking the mutex and
sleeping while executing an interrupt.
This removes usage of the irq_lock spinlock, but introduces
a new hardirq_lock, which is _only_ used for the PCI/SSB lowlevel
hard-irq handler. Sleeping busses (SDIO) will use mutex instead.

Signed-off-by: Michael Buesch 
    Tested-by: Larry Finger 
Signed-off-by: John W. Linville 

I vaguely remember this patch. Although it is roughly a 1000-line fix, I will 
try to port it to b43legacy. I still have an old BCM4306 PCMCIA card that I can 
test in a PowerBook G4.


I agree with Michael that this is the way to go. Both of Jia-Ju's patches should 
be rejected.


Larry

Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_attr_interfmode_store

[Larry Finger]

On 05/31/2017 05:29 AM, Jia-Ju Bai wrote:

The driver may sleep under a spin lock, and the function call path is:
b43legacy_attr_interfmode_store (acquire the lock by spin_lock_irqsave)
   b43legacy_radio_set_interference_mitigation
 b43legacy_radio_interference_mitigation_disable
   b43legacy_calc_nrssi_slope
 b43legacy_synth_pu_workaround
   might_sleep and msleep --> may sleep

Fixing it may be complex, and a possible way is to remove
spin_lock_irqsave and spin_lock_irqrestore in
b43legacy_attr_interfmode_store, and the code has been protected by
mutex_lock and mutex_unlock.

Signed-off-by: Jia-Ju Bai 
---
  drivers/net/wireless/broadcom/b43legacy/sysfs.c |2 --
  1 file changed, 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/b43legacy/sysfs.c 
b/drivers/net/wireless/broadcom/b43legacy/sysfs.c
index 2a1da15..9ede143 100644
--- a/drivers/net/wireless/broadcom/b43legacy/sysfs.c
+++ b/drivers/net/wireless/broadcom/b43legacy/sysfs.c
@@ -137,14 +137,12 @@ static ssize_t b43legacy_attr_interfmode_store(struct 
device *dev,
}
  
  	mutex_lock(&wldev->wl->mutex);

-   spin_lock_irqsave(&wldev->wl->irq_lock, flags);
  
  	err = b43legacy_radio_set_interference_mitigation(wldev, mode);

if (err)
b43legacyerr(wldev->wl, "Interference Mitigation not "
   "supported by device\n");
mmiowb();
-   spin_unlock_irqrestore(&wldev->wl->irq_lock, flags);
mutex_unlock(&wldev->wl->mutex);
  
  	return err ? err : count;




Jia-Ju,

Did you actually observe the attempt to sleep under the spin lock, or did you 
discover this using some tool? In other words, have either of your patches been 
tested?


Larry

Re: [net-realtek-btcoexist] question about identical code for different branches

[Larry Finger]

On 05/17/2017 04:52 PM, Gustavo A. R. Silva wrote:


Hello everybody,

While looking into Coverity ID 1362263 I ran into the following piece of code at 
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c:1000:


1000void exhalbtc_set_ant_num(struct rtl_priv *rtlpriv, u8 type, u8 ant_num)
1001{
1002if (BT_COEX_ANT_TYPE_PG == type) {
1003gl_bt_coexist.board_info.pg_ant_num = ant_num;
1004gl_bt_coexist.board_info.btdm_ant_num = ant_num;
1005/* The antenna position:
1006 * Main (default) or Aux for pgAntNum=2 && btdmAntNum =1.
1007 * The antenna position should be determined by
1008 * auto-detect mechanism.
1009 * The following is assumed to main,
1010 * and those must be modified
1011 * if y auto-detect mechanism is ready
1012 */
1013if ((gl_bt_coexist.board_info.pg_ant_num == 2) &&
1014(gl_bt_coexist.board_info.btdm_ant_num == 1))
1015gl_bt_coexist.board_info.btdm_ant_pos =
1016   
BTC_ANTENNA_AT_MAIN_PORT;

1017else
1018gl_bt_coexist.board_info.btdm_ant_pos =
1019   
BTC_ANTENNA_AT_MAIN_PORT;

1020} else if (BT_COEX_ANT_TYPE_ANTDIV == type) {
1021gl_bt_coexist.board_info.btdm_ant_num = ant_num;
1022gl_bt_coexist.board_info.btdm_ant_pos =
1023   
BTC_ANTENNA_AT_MAIN_PORT;

1024} else if (type == BT_COEX_ANT_TYPE_DETECTED) {
1025gl_bt_coexist.board_info.btdm_ant_num = ant_num;
1026if (rtlpriv->cfg->mod_params->ant_sel == 1)
1027gl_bt_coexist.board_info.btdm_ant_pos =
1028BTC_ANTENNA_AT_AUX_PORT;
1029else
1030gl_bt_coexist.board_info.btdm_ant_pos =
1031BTC_ANTENNA_AT_MAIN_PORT;
1032}
1033}

The issue is that lines of code 1015-1016 and 1018-1019 are identical for 
different branches.


My question here is if one of those assignments should be modified, or the 
entire _if_ statement replaced and the function refactored?


I'd really appreciate any comment on this.

Thank you!
--
Gustavo A. R. Silva


Gustavo,

Thanks for the notification. I will discuss with Realtek as to the proper fix.

Larry

Re: 4.10.9 nok with realtek wlan, atom

[Larry Finger]

On 04/16/2017 01:09 PM, rupert THURNER wrote:

On Sun, Apr 16, 2017 at 6:02 PM, Larry Finger  wrote:

On 04/16/2017 05:23 AM, rupert THURNER wrote:


On Sat, Apr 15, 2017 at 10:40 PM, Larry Finger
 wrote:


On 04/14/2017 03:26 PM, rupert THURNER wrote:



On Thu, Feb 9, 2017 at 9:09 PM, Larry Finger 
wrote:



On 02/09/2017 01:43 PM, Bjorn Helgaas wrote:




[+cc rtl8192ce folks in case they've seen this]

On Thu, Feb 09, 2017 at 03:45:01PM +0100, rupert THURNER wrote:




hi,

not technical expert enough, i just wanted to give a short user
feedback. for realtek wlan on atom, kernels up to 4.9.5 are ok, and
kernel 4.10.0-rc7-g926af6273fc6 (arch linux-git version numbering) as
well. kernels 4.9.6, 4.9.7, and 4.9.8 fail, i.e. connection to a WLAN
hotspot is possible then drops, or connecting to wlan fails
alltogether.





Thanks very much for your report, and sorry for the inconvenience.

v4.10-rc7 works, so I guess we don't need to worry about fixing v4.10.

But the stable kernels v4.9.6, v4.9.7, and v4.9.8 are broken, so we
need to figure out why and make sure we fix the v4.9 stable series.

I can't tell yet whether this is PCI-related or not.  If it is,
4922a6a5cfa7 ("PCI: Enumerate switches below PCI-to-PCIe bridges")
appeared in v4.9.6, and there is a known issue with that.  The issue
should be fixed by 610c2b7ff8f6 ("PCI/ASPM: Handle PCI-to-PCIe bridges
as roots of PCIe hierarchies"), which appeared in v4.9.9, so I guess
the first thing to do would be to test v4.9.9.

If it's not fixed in v4.9.9, can you share the complete dmesg log
(output of "dmesg" command) and "lspci -vv" output for v4.9.5 (last
known working version) and v4.9.6 (first known broken version)?  On
v4.9.6, collect the dmesg output after the failure occurs.


24: PCI 300.0: 0282 WLAN controller
  [Created at pci.366]
  Model: "Realtek RTL8188CE 802.11b/g/n WiFi Adapter"
  Device: pci 0x8176 "RTL8188CE 802.11b/g/n WiFi Adapter"
  Revision: 0x01
  Driver: "rtl8192ce"
  Driver Modules: "rtl8192ce"
  Device File: wlp3s0
  Features: WLAN





It would be helpful if someone were to bisect this issue. The only
issue
that comes to mind was fixed in commit 52f5631a4c05 ("rtlwifi:
rtl8192ce:
Fix loading of incorrect firmware") which is in 4.10-rc7 and will be
backported to 4.9.

The above issue is one that could not be reproduced on my hardware,
thus
it
took Jurij Smakov to find the fix. Without his bisection of the
problem,
who
knows how long it would have taken to find my edit mistake.




larry, using the newest kernel 4.10.8 the network connection dropps
again irregular.

# dmesg
[0.00] Linux version 4.10.9-1-ARCH (builduser@tobias) (gcc
version 6.3.1 20170306 (GCC) ) #1 SMP PREEMPT Sat Apr 8 12:39:59 CEST
2017
[   11.933373] rtl8192ce: rtl8192ce: Power Save off (module option)
[   11.933396] rtl8192ce: Using firmware rtlwifi/rtl8192cfw.bin
[   11.978307] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[   11.978945] rtlwifi: rtlwifi: wireless switch is on

# lspci -vv
Subsystem: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi
Adapter
Kernel driver in use: rtl8192ce




Is firmware rtlwifi/rtl8192cfw.bin also used on kernels that work?



4.10.x used to work. 4.10.6 or 4.10.7 it started failing? i am not too
sure about it.

# ls -l /usr/lib/firmware/rtlwifi/rtl8192cfw.bin
-rw-r--r-- 1 root root 16192 Mar 10 12:15
/usr/lib/firmware/rtlwifi/rtl8192cfw.bin



That does not answer my question.

4.10, 4.10.2, 4.10.3, 4.10.5 worked. as far as i can tell
rtl8192cfw.bin did not change and was used. with kernels 4.9 there was
a phase where rtl8192cfwU.bin was loaded which did not work. or i do
not understand your question correctly?


I think you mean that rtl8192cfw.bin was the firmware used for both a good and a 
bad kernel.


My problem is that there are at least 6 varieties of chips that use the 
rtl8192ce driver. I do not have all of them, but so far it is impossible for me 
to tell if yours is the same as one of mine. If you post the output of 'lspci 
-nn', then I might be able to answer that question.


A second problem is that there are no fixes in any 4.10.x kernel where x >= 1 
that can cause a problem in rtl8192ce, thus it is hard to know how 4.10.5 can 
work and 4.10.6 or 7 can fail! That is the reason that a bisection would be useful.


At this point, and with the information you have provided, I'm not sure if the 
problem is even in rtl8192ce, or how I can help.


Larry

Re: 4.10.9 nok with realtek wlan, atom

[Larry Finger]

On 04/16/2017 05:23 AM, rupert THURNER wrote:

On Sat, Apr 15, 2017 at 10:40 PM, Larry Finger
 wrote:

On 04/14/2017 03:26 PM, rupert THURNER wrote:


On Thu, Feb 9, 2017 at 9:09 PM, Larry Finger 
wrote:


On 02/09/2017 01:43 PM, Bjorn Helgaas wrote:



[+cc rtl8192ce folks in case they've seen this]

On Thu, Feb 09, 2017 at 03:45:01PM +0100, rupert THURNER wrote:



hi,

not technical expert enough, i just wanted to give a short user
feedback. for realtek wlan on atom, kernels up to 4.9.5 are ok, and
kernel 4.10.0-rc7-g926af6273fc6 (arch linux-git version numbering) as
well. kernels 4.9.6, 4.9.7, and 4.9.8 fail, i.e. connection to a WLAN
hotspot is possible then drops, or connecting to wlan fails
alltogether.




Thanks very much for your report, and sorry for the inconvenience.

v4.10-rc7 works, so I guess we don't need to worry about fixing v4.10.

But the stable kernels v4.9.6, v4.9.7, and v4.9.8 are broken, so we
need to figure out why and make sure we fix the v4.9 stable series.

I can't tell yet whether this is PCI-related or not.  If it is,
4922a6a5cfa7 ("PCI: Enumerate switches below PCI-to-PCIe bridges")
appeared in v4.9.6, and there is a known issue with that.  The issue
should be fixed by 610c2b7ff8f6 ("PCI/ASPM: Handle PCI-to-PCIe bridges
as roots of PCIe hierarchies"), which appeared in v4.9.9, so I guess
the first thing to do would be to test v4.9.9.

If it's not fixed in v4.9.9, can you share the complete dmesg log
(output of "dmesg" command) and "lspci -vv" output for v4.9.5 (last
known working version) and v4.9.6 (first known broken version)?  On
v4.9.6, collect the dmesg output after the failure occurs.


24: PCI 300.0: 0282 WLAN controller
  [Created at pci.366]
  Model: "Realtek RTL8188CE 802.11b/g/n WiFi Adapter"
  Device: pci 0x8176 "RTL8188CE 802.11b/g/n WiFi Adapter"
  Revision: 0x01
  Driver: "rtl8192ce"
  Driver Modules: "rtl8192ce"
  Device File: wlp3s0
  Features: WLAN




It would be helpful if someone were to bisect this issue. The only issue
that comes to mind was fixed in commit 52f5631a4c05 ("rtlwifi: rtl8192ce:
Fix loading of incorrect firmware") which is in 4.10-rc7 and will be
backported to 4.9.

The above issue is one that could not be reproduced on my hardware, thus
it
took Jurij Smakov to find the fix. Without his bisection of the problem,
who
knows how long it would have taken to find my edit mistake.



larry, using the newest kernel 4.10.8 the network connection dropps
again irregular.

# dmesg
[0.00] Linux version 4.10.9-1-ARCH (builduser@tobias) (gcc
version 6.3.1 20170306 (GCC) ) #1 SMP PREEMPT Sat Apr 8 12:39:59 CEST
2017
[   11.933373] rtl8192ce: rtl8192ce: Power Save off (module option)
[   11.933396] rtl8192ce: Using firmware rtlwifi/rtl8192cfw.bin
[   11.978307] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[   11.978945] rtlwifi: rtlwifi: wireless switch is on

# lspci -vv
Subsystem: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi
Adapter
Kernel driver in use: rtl8192ce



Is firmware rtlwifi/rtl8192cfw.bin also used on kernels that work?


4.10.x used to work. 4.10.6 or 4.10.7 it started failing? i am not too
sure about it.

# ls -l /usr/lib/firmware/rtlwifi/rtl8192cfw.bin
-rw-r--r-- 1 root root 16192 Mar 10 12:15
/usr/lib/firmware/rtlwifi/rtl8192cfw.bin


That does not answer my question.

Larry