[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(>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 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 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(>current_network, net,
-  sizeof(struct rtllib_network));
+   memcpy(>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 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(>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 <larry.fin...@lwfinger.net> 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 <colin.k...@canonical.com>

Trivial fix to spelling mistake in RT_TRACE message text.

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


Acked-by: Larry Finger <larry.fin...@lwfinger.net?

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: 陆朱伟 <alex...@realsil.com.cn>
Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 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<N9{>@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
zcmd443tSXemIqwbbT<t_(G+yJ;{gpiw~0JEem0(PWHy5u=%E5evJkAwiRICNZfP
z^O}Kd6nw<TY};UB6f)Y~nC$Lkr_<;pqd2SJE3aMRBZ2Nl8#S7pWVXNmsipy)%*^iZ
zx8Hsr{BG5)TeoiAx{q_uJ?DQ;FD$c4tIA5tSH32#jbm6w#l$glIPSLGipdPa_)
z=OWVg_vcd0(s6En>p0KMg0%(mky|{nu_T8-GS+j8Tlnmj-s3pL$9ba1@raLicZADa
z9pQB@A-^Wr5q`xb7sv)AsFG1n-~<gE!VE$9d@^LK<__A}R(=C8$-h^trp!#yKV
z#)#hINW@2aqQ_B)kMht_vzfURSIU$X?~7=!!}!u~y+98NUI8+UT@4>(_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@N$6SYH{rO>pN`|p{=qoD
z;xEAQRev&$ulW~Bj9ut?-TySMO8r8Q4dGV^5`qJv0-+M~mst{KC=?zqOoNW~6
z8`-OIRYR<L^pACBeC9~|>Oi8$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<A0ys#1kD;+(xH
zfu!t?%er|bojSLnb4Eu;c&?LOR3fq*V~gLceUrJQF5UeM`ggrS{=PI}sqT3EvB(Oh
z{1%V1J|gKuns(W^e!TjmdZVVcDZsa%yZ3E#WoY)5#Gi>(@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-!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$|QW??^n!7%vnho#xLZZcN%-v}=fY}(`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<<Uw`@hj
z6@8`2*zmNrP3MV7vV*VR+g%-K3Sb!WIo|8WTO`&<wQ#xwt$m1i9
zMQqgp#-7;ryqg*MN0Z=R<57u1Pj3BlZp`RyQb28H?MdzWb}g6F<-2a4!Z`HDlTNO3
z7jEU+R-xUVaj`20Tem1PL#N@gzZ9Q*Pni?Jirz8tQ<vH<1>#Un8QOP+TiBCoOMRS1
zs1y)AtR%O*DKaBZng+KC9#hy`ZwhZhc)EV9SkpDE-O=?^Pe=Wu9-%(w9${~F@G=QD{up8xe;_`5V7}M+dp_LWka9Bl
z)X-ZP2OstvymWoIG`MXDW?$F%^wY&`=yKB0c%fl?uQJTJaNbTSa_fd%s<{DEj
zH&%D=5Z$ebo5BU$=A)h5rr@QcmweaHPVb!F9U8Xz>a?RF<EAr+r*8fM@mvJ`rlieB
zyC#OtBOa+pTi+U@b)=@Vpun(xGIAD}_*MvLU`q46FU0!iljyKoMyX1z}t_68p
z3TguJQe(5le3q_$gd}`7qVjGPIGsZ*GhQy7+HTM3A7(EV*F72@)?a?uj
zwAnN*as80m?u!#I?h{p*KR--!TpYD|<oXd9v#A(gcYr3B6k*&(m`IFPEx;IFNaGmc
zK7<$@cpLN81e!Zs#T*!o_#)hU41vZxjZ=k29M>FM;Nkb8<s^1qHRvgSWVp51{q=
z9E+RZlVE10`EJ=i-_1yL6b`GnxuDQ<FfIyl#n@(g9zMb|BX>_=LU#g$HU7AwR|
zuOa9-?+e@NH7nJaxp!eiX}Nyd9kSkmr(|ROc)>r-owYU22HKdxuE<9z|KJjOnq1Vn
zj9qQcaSJZ?@zvrj?)4YghfLwYt}P<FYKy3zT+@jW=;Ff-uGi2zrf{8WQg=0C5vjU!
z$V5}K(9^h!56^PF7f8)Ep)^_r#<-oXk%+$+&}3so<{-W&`6n=npF_h2T~4|X
zBsU)}_4DB@KPZjMfVwlbG<+!q(8cu{^obgMLTeQD1@(gkf%<~hF6s;FE25o5t7jvq
z5Qsig9}z80aSK}+TQcX|`xSbiF_hH|eB0$5O?G^9bSy9xF
zf_4#q6B|!d=ATNFmL?ugIA+>@uf0*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=<Unv7Qp_KD*p>P@DMwT

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 <a...@arndb.de>
---
  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 <larry.fin...@lwfinger.net>

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 <m...@chromium.org>
---
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 <larry.fin...@lwfinger.net>




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   

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 <baijiaju1...@gmail.com>
---
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.fin...@lwfinger.net>

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 <colin.k...@canonical.com>

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 <larry.fin...@lwfinger.net>

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 <colin.k...@canonical.com>
---
  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 <larry.fin...@lwfinger.net>
Cc: Ping-Ke Shih <pks...@realtek.com>
---
 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_Td0<mj+CQG$tc60GOGR*_gfMPETNV{WD2uz4R^u`{YS3b36iD<|TT00Vq=aJO
z)RGo;p!gOY5V3YF4vq_zs^E+Yl~Ko)3noSAk{cl`(j?!{b8b?=nfLvE-#>nT{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{`v4T?<8c3Y`|v_0x*%V>K9b#uN*Et!9IO
zugRd-8T<9Im~__EJ{F_S+P9Ax{=R)o2Kpk6HA74_>e4gB6nq`_i$q<f!#*gLz8Plv
zrWx@a+6UiZLy<Cb*bwsDhY)<|kby{<la-mF%g)Ifl#cHR<ju~xB7?q{W$5sA@b4w`
z6$FFPXiZ5;?Vm0RDSi9*OG_7ZM*L^hrR#?2M(Xl))w)*wrTQHG1G;B*yLI2|AJ9Ll
ze?kAL{)iwLt*PQ5NA^vw$1^S)onNwHce`G%7x2GeK(T_+Y_V9aRt<(P;Pi!~xmr4t
z9^~U^3nIq-(a&*&<)Z?^Z$q6osDvAw7Ar`Y;WJ<z1CNiozDg<9YvAK;Im^(
zBhP;EY^P)8$@X^zL5jEf7dPkXaz8IMl*j|yt?s@%8{4xF7^V+8{zaqpo30}(_u7N0
z@nMd|C)2Ff9R{OUSF*T0JMfDxnA%#OpJ_^!Du<_@Y>*xLSj>ibmWXD5H2>r$-k
zEsA_Rn7Xe%_tIc0)t88l4r>4GWN`6ZmwB^SLWaaMT=cUT~f~i!G*GNrJ4Cx0`
zy}IlJmh7L5UaRw%bK%EdG&<#}7JEtMD~lz;WsX~)itj(|H3UlJ<JRNW{lAthekz+)
zL?wMqixR+Z+6sMfrK|Ya(l4I<qR}pd_N@_e4c@q2TAY=2vOP0+3>8h!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$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+y@4hA0b#t`yrXIU;vOzi3p#0jP
zoVF{cx#yI<Lv1*sHXK&%dzbEAaxzfk7O||{{Tdo-PQnve;#(ScQW9z%h!l8sz;#
z1^V|xpr!#y8*{m10X3F5RkQg^qG`Ouj*J#+WcT;s93Wc>}t_Xp&@dSJrz
z%v_mO91ASc*SOwoh}|2UDCwV#w_uu1e8LqfC$&^a@LcY04?n`)x5FpmubU|8-{ETxB|wAPj+H
zgd@JT9)+?R7nR3qW}z@vQx;y)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^Fi
zyn3U%h*b!-}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)41~#EMMjzfLsf
zQ17)pJ)l9!R4h*Y^g>m}Cc7SkuZoSkneSz#S#M>>EB@Y^T5WDXp9yIfypvwJt
z&|;><CKc^|S(PWU$}raZ3Zuewx!H<U0pi}E%4TviRc!m^^#jm=A=!%2Ymf!(AI}To
z#+}r!X&8_O#krqKYE;9^fl8QfuQDAq*;r*=+r3C^TtpyeRArUl0AS#Nb<`8)dr86W
z=ZlWj4HPS;vbys^s#tMr)jhhZ`}I{1nX5|DtIEZyB^g!A2Ua~hsH%E!RqcgUFJ4qt
ze@WHG%_fs@I2Cy?JTX_RFi@yP|4mZq+AKtNuA{)s!2nzPY*TM_1LsSyhJ~s_J~W
zDqL7~e0J68M^@>IR+%1M)o0GCw8vIuJico1+*Oy%TQzL{s>|G~Mz(vtEy;s
z)sz3w=~j(yn<^~7m_9LlK21UMlz4+!F<#hvEdZbE@Y!I+XU7ltwEPvH<q|%B{uQ6b
zc6{Dg**5jSdU#qs#^=3D@YyWj^T7(+*FP!vY1>p*`Lb*xXPfxROM-C`z{5N7
z+5eZesZ*TrJUtVig)V#+P+|99g-_XGeB5L3x#<{`~RI}@LRG74tnbN4U!NLBch
zynxRGeev0I5!1IQ({VnaM@+vHhh*JA?0HuCG-2O(WXY<fG*6YK6r_+{n>}qhUkX>A
zy%_l9H;C=G(eziI!piS2kLKIqd~AnI#VT(3ArR%|QDmBY9`jwLxH8TKr+eq~rLh6~
z#L9~iUz<lust;dDI2~vuy`;qH#Olw?pD9ipRpve9i0?m~tqcxn+r-vA-KsWV!#cfj
zR@o+Q-NZ}}E39sW%1jTzy%O#$xL3e+!M$Ak><GT$BiM2+#uihHxy6E1;Un0UhS*-i
zUSY3(ukNhK21E@yH;Vah5U^DV6VYDL(<zO0!gS!>h7bx3uZ=kk(Qd?9PPZ6<=bUM*
z?lN_+LHx5J{2b!MmwIquO6kB9PfC`889;V)Bm*`2OAFd=@`6oV

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 <nicolas.iooss_li...@m4x.org>


Looks good. Acked-by: Larry Finger <larry.fin...@lwfinger.net>

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, _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 <larry.fin...@lwfinger.net>
---

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 <larry.fin...@lwfinger.net>
---
 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 <a...@arndb.de>


For all three of these patches:

Acked-by: Larry Finger <larry.fin...@lwfinger.net>

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();

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 <colin.k...@canonical.com>

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 <colin.k...@canonical.com>


Looks OK to me.

Acked-by: Larry Finger <larry.fin...@lwfinger.net>

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 <larry.fin...@lwfinger.net>
Cc: Ping-Ke Shih <pks...@realtek.com>
Cc: Yan-Hsuan Chuang <yhchu...@realtek.com>
Cc: Birming Chiu <birm...@realtek.com>
Cc: Shaofu <sha...@realtek.com>
Cc: Steven Ting <stevent...@realtek.com>
Cc: kbuild-...@01.org
Cc: Julia Lawall <julia.law...@lip6.fr>
---
 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 <larry.fin...@lwfinger.net>
c: kbuild test robot <fengguang...@intel.com>
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 <gust...@embeddedor.com>


According to Realtek, this change is OK.

Acked-by: Larry Finger <larry.fin...@lwfinger.net>

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 <andreas.zieg...@fau.de>
Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
Cc: Ping-Ke Shih <pks...@realtek.com>
Cc: Yan-Hsuan Chuang <yhchu...@realtek.com>
Cc: Birming Chiu <birm...@realtek.com>
Cc: Shaofu <sha...@realtek.com>
Cc: Steven Ting <stevent...@realtek.com>
---
 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 <larry.fin...@lwfinger.net>
Cc: Ping-Ke Shih <pks...@realtek.com>
Cc: Yan-Hsuan Chuang <yhchu...@realtek.com>
Cc: Birming Chiu <birm...@realtek.com>
Cc: Shaofu <sha...@realtek.com>
Cc: Steven Ting <stevent...@realtek.com>
---
 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 <larry.fin...@lwfinger.net>
---
 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 
<pks...@realtek.com>
+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|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`-{<mse$Vgr+#j+YV=R>k%(05`KXvMa8_y>)ro>5V_7f5mRTXa&8
zJ`9sQcp>;7`I~Yp^IT3~9<@sNSgi(V09rr-AW``Eh3#@#nt!agmmg#vPWeBWzkY$q
z)5IQQd)c$h%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<Bt&1O8!
z_;<FLc?JN9CCoDe@CCqk0EYl40K<S;R^~Z+5A(bX_&30R0Nw;>?`NKVfJ1)1aG&%|
zVFYi;Pvv_R;vd|?JbM5K0Y3)326)p38UT~+%ySFiKEU<m%(D<s0Js<620RP+9^fe8
zUjZiw9L)1N;17WFfFNLN4f8w&_#xo8fI+}Qk$JuinB_(|prn?0mQQA$)qr(?F995Y
z7rx3o_zB?WfL{R4S_RKVz#w2wso-$|b^-S5_owYQ?!PW+()HQ@wngx$ZGz_)
zczy_<Ae5@%|>@Pk@Vne!wsw1#v1(f-YImrx_-xQ_`mzwW*V@o1Qpf%CwnD6Em)#
z0a>ZFiAk!I)Cm(c`pHu=64KJAU9U4ty>3SGB;)j%jA?ZAmz<moc`}VYeR_7zt!BKw
zuv_q)0E~V1BTRvp@&2X^^e#LicrpN=MN>keE-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?&*X3Ac~<^bo*^qgg6p4osK0rLS1
z0f(}f=U0HsfRxz?1JnTa0A2>X3HT6j@Sk8ufOi1G_kaiRO@9oYiF>E;UE{z{5Oy4}
z@LytZ2i{8nO@KcDE&^`+A@h6%K+pdGeETP`Wx(aTi9bbs0E+<yfO`Q4r;mo?
z_>PD3_>Ko*2I>+Ac_)AiPztygPy=}A*Ua-A;1R$fz#hO+z|#PgO0A;56adtlX+z92
z0gwsE1FQgCnJ##i#J%0ImQw%!HlIg)IR-1Z3VMcvb;Ef+PPc{#rDZ$MypD0}cS%
z06svaP<iYX086?9B~klHtw|)ZUR!yr3~)DK2jD@#*8q`7<U2O4?U)VkNN50<0E+GRG@dHJrAd{?J^)RT2-TNqknTgk+kjab
z#A_Jph^G$EY&<=H(^P-Gz_#NLeX$R8^~oRT%7hP)hj84<SZ{<)7tniS5gl706zNt9
zk;nwrYk(VRO9s~;VF+V3d_SgNDX`PYtca~->>R}v3RhFL><ZH|QHS(w7UAq-$vXC*
zS5g65(v)7Ho{)*>irE7CDWD+{paQ7b2S`7m96bIJ0Frzh-(_Z+Esw@d>2wb`S_
zyNcfb>%U$}2EGTtF97I>-Vun&}S^zn0HJUA2KLe@g%`9=4om@SX_J0g?d802Z3S
zSZFzlp_eXVLWq4d0ZxGaganqx|CaW8xK4F3wVoA2ZmR(T$`HU?6+n%5HJ-B(z6bz3
zswH@8w23-&<Wx<@2ac`7w+GK=z%IaUz$1VK2oFJyR5bqdU;!RoECKb>aoXQl9{Ff_
zqzviq2CM~`00QDv05w1hNB|@Pm;w0!YCsY|1JDBW02M$0qyiEEFhSOMZzEf^Z569u
zQO`0~WT5O=-jX0Dex0eDrbT$=wFsq<fNXLVXa--!rL?_mh9wzmJm*SCFRD
zFg<`p{sLZpJZpQ^nx*J{vv%;u2dIMnnenU!)Z+a#<Xnm8Y}i00!Xgnfii`BlmTN?Z$IAo~Q6Uh35`Dci?#=()<|kuYkpX+hO}=Jf8qf-vJ2F8x`Ob%J~m~53m$v
zECSpHSO{z;b{YkPj#X6aiKPiUB2n?Z6F|=i*#HwgL4yg9
z1DFd~0$2oCinyhCz6<CDl!3nW0A}vZxFV!6p`I=8MV;OOc#-y5z^?$m1oXmxI8fdL
zfGR)*pd4TaEJQq;3&;U11>6pv0!KCERRe(|5x1QX2#`ZjTlf3PC;+sq;kDXA%
z|EkCbPiF#ucENx=f{MSJg<ZhK)QKzt*adp`0-gk39m;(Y?;n7MzX1LU_z(b{c-Rm5
zwE-BbHVQ~P3wkphkON$^09%mv7}CB1*aBWa9!4``KQ06m0jz+-NY_PmV<ynXbl<>t
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&%_-)0L;A@SyhkpjQ|tAmq5Qx^0FgWSO)wQKnKtO;Agtf
zL;~~x0ifzi;NhCCME=xuEk=2{fIPq=fN<o<Um1+@0{HYJ)HedMH{-b!W%vjr`5e0!
zVVWsu*8n<z9)PMuN<q(E04rcE!1pNm5-n>+-d%tv0J{N?05*b`WdPW|@n3-NhkydW
zLx6_?4S+WQy?}QCmjHc$5a9m+Ou(-OL?S{{~VS6^K>#hOJ%lr8PTB>nf{E
zmQ@9JEZQ-re4{Bpf1UJ(`25d^-?aMfk}usse|MG@-M3}+-34~Bro6%4ShZz!ZA~K|
z+B8&@oaVQkoj7wr
<

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 <pks...@realtek.com>
Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
Cc: Yan-Hsuan Chuang <yhchu...@realtek.com>
Cc: Birming Chiu <birm...@realtek.com>
Cc: Shaofu <sha...@realtek.com>
Cc: Steven Ting <stevent...@realtek.com>
---
 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,

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 <larry.fin...@lwfinger.net>
Cc: Ping-Ke Shih <pks...@realtek.com>
Cc: Yan-Hsuan Chuang <yhchu...@realtek.com>
Cc: Birming Chiu <birm...@realtek.com>
Cc: Shaofu <sha...@realtek.com>
Cc: Steven Ting <stevent...@realtek.com>
---
 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 <gre...@linuxfoundation.org>,
 and Larry Finger <larry.fin...@lwfinger.net>.
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 <larry.fin...@lwfinger.net>
Cc: Ping-Ke Shih <pks...@realtek.com>
Cc: Yan-Hsuan Chuang <yhchu...@realtek.com>
Cc: Birming Chiu <birm...@realtek.com>
Cc: Shaofu <sha...@realtek.com>
Cc: Steven Ting <stevent...@realtek.com>
---
 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/h

[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 <larry.fin...@lwfinger.net>
Cc: Ping-Ke Shih <pks...@realtek.com>
Cc: Yan-Hsuan Chuang <yhchu...@realtek.com>
Cc: Birming Chiu <birm...@realtek.com>
Cc: Shaofu <sha...@realtek.com>
Cc: Steven Ting <stevent...@realtek.com>
---
 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 <wlan...@realtek.com>
+ * Realtek Corporation, No. 2, Innovation Road II, Hsinchu Science Park,
+ * Hsinchu 300, Taiwan.
+ * Larry Finger <larry.fin...@lwfinger.net>
+ *
+ 
**/
+
+#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 @@
+/**
+ *
+

[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 <larry.fin...@lwfinger.net>
Cc: Ping-Ke Shih <pks...@realtek.com>
Cc: Yan-Hsuan Chuang <yhchu...@realtek.com>
Cc: Birming Chiu <birm...@realtek.com>
Cc: Shaofu <sha...@realtek.com>
Cc: Steven Ting <stevent...@realtek.com>

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/hal

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 <arvind.yadav...@gmail.com>
---


Acked-by: Larry Finger <larry.fin...@lwfinger.net>

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 <gust...@embeddedor.com>
---
  drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c | 6 --
  1 file changed, 6 deletions(-)


Acked-by: Larry Finger <larry.fin...@lwfinger.net>

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 <arvind.yadav...@gmail.com>


Acked-by: Larry Finger <larry.fin...@lwfinger.net>

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 <kv...@codeaurora.org> wrote:


Jia-Ju Bai <baijiaju1...@163.com> 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 <baijiaju1...@163.com>
---
  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(>irq_lock, flags);
b43legacy_synchronize_irq(dev);
+   spin_lock_irqsave(>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 <m...@bu3sch.de>
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 <m...@bu3sch.de>
Tested-by: Larry Finger <larry.fin...@lwfinger.net>
Signed-off-by: John W. Linville <linvi...@tuxdriver.com>

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(>wl->mutex);

-   spin_lock_irqsave(>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(>wl->irq_lock, flags);
mutex_unlock(>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 <larry.fin...@lwfinger.net> wrote:

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


On Sat, Apr 15, 2017 at 10:40 PM, Larry Finger
<larry.fin...@lwfinger.net> wrote:


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



On Thu, Feb 9, 2017 at 9:09 PM, Larry Finger <larry.fin...@lwfinger.net>
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
<larry.fin...@lwfinger.net> wrote:

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


On Thu, Feb 9, 2017 at 9:09 PM, Larry Finger <larry.fin...@lwfinger.net>
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

Re: 4.10.9 nok with realtek wlan, atom

[Larry Finger]

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

On Thu, Feb 9, 2017 at 9:09 PM, Larry Finger <larry.fin...@lwfinger.net> 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?

Larry

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

[Larry Finger]

These files were supplied by Realtek.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 WHENCE |   3 ++-
 rtl_bt/rtl8822b_config.bin | Bin 32 -> 14 bytes
 rtl_bt/rtl8822b_fw.bin | Bin 51756 -> 51176 bytes
 3 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/WHENCE b/WHENCE
index dcd5011..1ac6fd0 100644
--- a/WHENCE
+++ b/WHENCE
@@ -2859,7 +2859,8 @@ Licence: Redistributable. See 
LICENCE.rtlwifi_firmware.txt for details.
 
 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.
+Files rtl_bt/rtl8822b_* came directly from Realtek. These files are
+updated on April 14, 2017.
 
 --
 
diff --git a/rtl_bt/rtl8822b_config.bin b/rtl_bt/rtl8822b_config.bin
index 
a691e7ca258b0e7dc4ff2bdbdc1d13f2a613526b..b00270edca74c0bcd0234ceb8fe313a61ee28416
 100644
GIT binary patch
literal 14
VcmWGtt=!JRaFc<N{|N<}1Bn0t

literal 32
ncmWGtt=ulfaGQbAX&)n#faGpQMq3vKHbEt07gmOw42=2!f)WPF

diff --git a/rtl_bt/rtl8822b_fw.bin b/rtl_bt/rtl8822b_fw.bin
index 
b7d6d1229491314875b3d4a7266462c47998c0fb..5a464614ff4a339aa463d11ee6739153a7098237
 100644
GIT binary patch
delta 17685
zcma)k3s@7^w*O2r2_XcS@ElMi1n>c95%5{95wX6aRco#FaXJC%U^0OgZI6A}jA-BJ
z5eJL4+7km-i(oYY+k4OLJt=70Yw;Wftvx;My|iizNzkAkdrxnB`Tuqztv~Hpa
zGc$Yk?B`l*uk~AN+fuLW`<*gtdAUX0R9;rG_Ho-$B}G#TN=fC-s+ekcAfKWr?<|Uv
zHlN6H#0HtpNu*>b$NsHRBz^f`|SX^Wfxg0em5<~zdoc#j<U$CpOQ6JCx>-0G>p
zW6ho4ZMfg&*(U$trEL0H`RkWP)IBzep=~yQ-6o@KdU-l+m7jh2-uSg{r;8DH3^+Ru
zx^@hl9XQzWh%D2Y35`ms+!QQzK7iIt!7}F(T;<Q`EXOj>GSs}xvmC$6L%$IX>Rr@z
zrfmIGR$58vB_3%7(!Wh}${0D4vy;#j?`K7`;?i#7Zs5ds@j#S0eP%VwAas>kgKc
zj^lb&`f*|A>y2PDSaZ0WB+4MCv6~1}imb_0r!QDip-c#dKEUQE;Xj1<41v?#J~|
zBrEmeirJKYLM0ba>C^G7^d-J|;vQCd8Sg$s+2gn#$iy=$mp0>jbl?KY)J3pTNwi*i
z17*A@a~>UH(2*w!@r_Q80a6qvVRZK?^wP`tuofwMG794(6+Z5b)k}YgVx_V8C=%B$
zT=mG`g^x3Et;cmDt}V!)jcXgOrz7NlFP`psT=@e{Q?gBEA2k(o8KCvjSX^fy4dH$%
zt|p`vQ{}hjmU>pHXVCJDc}4Q(`K#rHZ>(2tyG6?<-gsBpc#D$#3m#FdnkwJFuv*U7
zd~S%wX!_K8DLRdn*3Q#QKb5IUO)c~-Wwp{Gagw5OY@|ZodtkF%l=OwNY;c6EPoBc8
zLR+$Pv6xL3wgTy)qnRyUyw<{nc(YSFoAn`zL|5iL(#a*u+W>RFf^L(9*1`
z$QKT-)sjitj<hsRUXpT#o+fWyny6U9$oZ)S<g=ExpHcDm95t$#VAwtsN3~
zfT7BbZpvkJOGsXqQT~snjD@N0hz-5_IJa|O3iyLLA8|qRnf6lD#iSD|@dta
z)!-9s^fk*LCYX|812TYkj89ST|+kJ7Upan;*1%|H#oS8R0P}b)0#ZI<7*J
zA0Ju7Jeh!D?>aPE{?o`MvTl^Y@?T|<rJC~*=So_#1m})diMOZbNXTYl1P*{M!
zpI%|wS6onBAo{Y6OKmBHVVc%A(e~sv=P9HXgQ)7(4eS`u4M>A(GsU^*GCho}+TAEn
z+}>+7Lacnx=)@d~OA6Epkqw%<2ym0Cj4B_yNiY2idS}GsWg@*zQzv$umaHpEFpN
zRyy+h2y{xi6<5tzO#4l~t@~dGH++Pr1$yB2Zy=>R
ziJ`b}KKy5Iiu^!&%9xpLstZZ=nw}r*>I*6Lr8kw85f`3z)(G13kv+6c3`AXc?TGHe
zB>8vg<1@M4L)G{3y*D%)ruxRX<NC9|=?%_5NLLqGyupPBqpJ0mO!+_3Gt#+w1NUX}
zaUn^f{dg9}iGweZ2U@2FPmcur0?Bo}de4BY!Ob_r2#X&=RnHy#(1tbu!M9aWyz
zFtTn0rXUtmKo;opu@EP9ddWOpKK9N+MXpl*;T=OnF60x%U63=H1$7f9CvAefvze1`
zJhEO^j9xCUJ<7`b>ZSB7`NZni=xlkSafH0SB~`8*{mi&~h$5rC?cl>8SH*=Z37c
zKFSu=z0FOHTxsAtYCH;oAIxjqDrdB?4v59KT}j|yH%Fox=k*6^=2Wu=PA&@
zQ!aXAqGfNhf%|QuM#bhF5FT^ekNEukytC7F_NPKI@qEBh0ZI6L2Y;L|e)*8D;
z!4FwQUxkMjrOsUfHFBMS>wc`=duUy|^APVb1Yd7VxJd2|!CQ_-L-5H){l!Pyovm3y
z>IIcBBo6e~_KoPV_v_AayP5H;@unr9yYNUGAw{WWz3@PrDd=g^`Qv-oiz`qKE5}_-
z+fJ$3#2RFUgW`pm#7Hz!|O0`jCqLY%ln`m^29g_+UgvhtZ=-Hg6+cdqi;o#2
zM!bHZ&_0kV+m5Bv3G!>lQXFx+Svh{s{E6!e7WdP(lc0Sw?#6j?Fh6`_SHHR7@j|;V
z!dC0I`$l{CM#IFWo6%L9k=Nxj6_`*q10{8@(;{`7JSnVa`<d<^>}hUSaAc+WT*P_8
zzN+ry!g+AXvy?G>`=gvY5UY(r42gNckaZXe^eKunM7(eB2ix)gwKJv>A!8
z4Pl>D1$A;1?(1+r6=^pTAq9xZXWnfxxaXR|pR7puld|9ErXYllsK<yiAvPp#nOeT@
z_;$q+wS4M$k$mb=ZX9Wrbb~Y}}7Q8jbV}(sS~(6H{oV{KScQ3QvUm
z+(o<7qqFdGST@$m)7<GY%bz4I{L7e$itlOp`k3)VgzxmsS04PETHY{rgnY}Bs`pV;
z2UXz>ra)r>MuA<#)#lig9Y08~1r3@5*;8GbvGPSFl>KNsu^Cgx8fF5?6|x9FM6p
z!p8KZdQ?3|EXogd`nFEa$Vrh~+T-$xv<wfKt{AbK>KG|gR#PWsO=;ljk}>hoWn`=S
z1bgD0S$jUGKt%>IRn9({p5}=_b4RFKs!d9sx|Oo&9?Mks{mnzwYM$aI%a)Ue<
zWADf}Ygoc%$rIljA@iFVna$HEVpX2hyrl}oo=A^4VGgYr)X69ANlqX#;K#CvQuR5?
zx<y#pDRE+?{N+7U>B;g;>jH#nd6<f!8Ud>OS@v-cjn4tJmr2OwTiClPb6wS*H
z@d@SD8=U-U!C1wO6gka)ul7r_X(M5drx#9+acDt{Haoaf;v8D}`9gyN7iZyea$*1V
zq}*I!M#?c=}Ea{l_pH$uya>crOE3jO;1>=Rd=g*(>ChEiZcvL
zgMOZl^0+6lbm0T;2RzkZJm7f}X#<joRE6{y5|6YQ=~<+u(5{w-f8~jqx#_dqhCz$V
zFetge<W|0LhyUI-zUy9(Gbl9X=T4WmJ~58;s^y7P2Ngw?GYl1sQ%T%XtxCO4c)3~P
z8j-88WxDw@nVw9y-KPm+us);5^w(5(@8HWWFNC1dNZp{U5$r6mEni^wp(zNjROp_=
zDjrpyXVXiAiLCT@?2`RR%aU2?9Xv-OeVD~c6ZIT23Rp=G1?^TkbfQ#QJ9RXD-1AU%
z8LikpMgHfFM!9X;DEWttk0p%*`CNfs;uWEr{H_f21wI!8y9Z)9h-QFe;UxOji1
z#C?h!i8~%CAD{l4C=D`BVGoeFhvk%ef9u#j1v&{*05xtR_mB{wjr&~Uao!mLaceMA
z+*`S{XmZlF1aT!q7R9Z|+wO~T^ZQ0x>7cH1m0#x}dc?N^5#Cx)*%y>G(!+GCLb`;y
z8^jyhnhDqDqkhus6zGSbQ2E}EX2;x}|94h?^`qj1tZ1rS$5M7(o7wN|VlpLeRv<OBf;{{_cjuQ_24VYPi|2XVKY!=ff&1RzTxV}^y_4Qx
z!YcO$A9LpRYwUa>U%1%c8=U9VR

Re: [PATCH] net: rfkill: gpio: Add OBDA8723 ACPI HID

[Larry Finger]

On 04/09/2017 07:11 AM, Marcel Holtmann wrote:

Hi Hans,


The OBDA8723 ACPI HID is used on quite a few Bay Trail based tablets
for bluetooth rfkill functionality.

Tested-by: russianneuroman...@ya.ru 
Signed-off-by: Hans de Goede 
---
net/rfkill/rfkill-gpio.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
index 76c01cb..50ca65e 100644
--- a/net/rfkill/rfkill-gpio.c
+++ b/net/rfkill/rfkill-gpio.c
@@ -163,6 +163,7 @@ static int rfkill_gpio_remove(struct platform_device *pdev)
static const struct acpi_device_id rfkill_acpi_match[] = {
{ "BCM4752", RFKILL_TYPE_GPS },
{ "LNV4752", RFKILL_TYPE_GPS },
+   { "OBDA8723", RFKILL_TYPE_BLUETOOTH },
{ },
};


NAK. We are integrating these with hci_bcm.c or hci_intel.c drivers.


This is for the bluetooth side of the rtl8723bs driver which recently
(yesterday) got merged in into drivers/staging. Which still needs
hciattach from userspace. I completely agree that eventually we should
fix that. In the mean time it would be nice if we could carry this
one line patch to give people using the staging driver working bluetooth.


why are Bluetooth drivers in staging? I objected to them before. The only 
reason to have them in staging would be people being to lazy to clean things up.


The Bluetooth driver is not in staging. It is only the wifi part; however, 
having a driver for that hardware in the kernel makes it easier for users to 
handle the BT part of the device. As Hans stated, the current BT driver runs in 
userspace. Until we actually produce hci_rtk, having this one line patch will be 
helpful.


Larry



--
If I was stranded on an island and the only way to get off
the island was to make a pretty UI, I’d die there.

Linus Torvalds

Re: [PATCH 06/22] staging: rtl8723bs: Fix various errors in os_dep/ioctl_cfg80211.c

[Larry Finger]

On 04/09/2017 10:28 AM, Bastien Nocera wrote:

On Sat, 2017-04-08 at 11:07 -0500, Larry Finger wrote:

Smatch lists the following:

  CHECK   drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:470
rtw_cfg80211_ibss_indicate_connect() error: we previously assumed
'scanned' could be null (see line 466)
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:942
rtw_cfg80211_set_encryption() warn: inconsistent indenting
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:955
rtw_cfg80211_set_encryption() error: buffer overflow 'psecuritypriv-

dot11DefKey' 4 <= 4

drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:1017
rtw_cfg80211_set_encryption() error: buffer overflow 'padapter-

securitypriv.dot118021XGrpKey' 5 <= 5

drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:1216
cfg80211_rtw_set_default_key() warn: inconsistent indenting
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:2498
rtw_cfg80211_monitor_if_xmit_entry() error: we previously assumed
'skb' could be null (see line 2495)
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:2850
cfg80211_rtw_start_ap() warn: if statement not indented
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:2860
cfg80211_rtw_start_ap() warn: if statement not indented
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3417
rtw_cfg80211_preinit_wiphy() warn: inconsistent indenting
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3547
rtw_wdev_alloc() info: ignoring unreachable code.

The indenting warnings were fixed by simple white space changes.

The section where 'scanned' could be null required an immediate exit
from
the routine at that point. A similar fix was required where 'skb'
could be null.

The two buffer overflow errors were caused by off-by-one errors.
While
locating these problems, another one was found in
os_dep/ioctl_linux.c.


Could you please split those up into patches that fix one kind of
problem? Makes it easier to review.


These patches were merged earlier today. Thanks for the reviews.

Larry

[PATCH 20/22] staging rtl8723bs: Fix indenting errors and an off-by-one mistake in core/rtw_mlme_ext.c

[Larry Finger]

Smatch lists the following:

  CHECK   drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:525 _mgt_dispatcher() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:1595 OnAssocReq() error: buffer 
overflow 'pstapriv->sta_aid' 32 <= 32
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:2391 dump_mgntframe_and_wait() 
warn: inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:2420 
dump_mgntframe_and_wait_ack() warn: inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:4969 process_80211d() error: 
testing array offset 'i' after use.
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:5738 linked_status_chk() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:6459 sitesurvey_cmd_hdl() warn: 
inconsistent indenting

The indenting problems were fixed with white-space changes. The error at
line 1595 was the result of an off-by-one error in a for loop. The error
at line 4969 was not fixed as that code lies inside a block of code that
only is needed for 5G channels. This chip only works at 2.4 GHz.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 25 -
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c 
b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
index e0a3cd64777f..18e78d5198c3 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
@@ -522,15 +522,14 @@ static void _mgt_dispatcher(struct adapter *padapter, 
struct mlme_handler *ptabl
u8 bc_addr[ETH_ALEN] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
u8 *pframe = precv_frame->u.hdr.rx_data;
 
- if (ptable->func) {
-/* receive the frames that ra(a1) is my address or ra(a1) is 
bc address. */
-   if (memcmp(GetAddr1Ptr(pframe), 
myid(>eeprompriv), ETH_ALEN) &&
-   memcmp(GetAddr1Ptr(pframe), bc_addr, ETH_ALEN))
-   return;
-
-   ptable->func(padapter, precv_frame);
-   }
+   if (ptable->func) {
+   /* receive the frames that ra(a1) is my address or ra(a1) is bc 
address. */
+   if (memcmp(GetAddr1Ptr(pframe), myid(>eeprompriv), 
ETH_ALEN) &&
+   memcmp(GetAddr1Ptr(pframe), bc_addr, ETH_ALEN))
+   return;
 
+   ptable->func(padapter, precv_frame);
+   }
 }
 
 void mgt_dispatcher(struct adapter *padapter, union recv_frame *precv_frame)
@@ -1575,7 +1574,7 @@ unsigned int OnAssocReq(struct adapter *padapter, union 
recv_frame *precv_frame)
if (pstat->aid > 0) {
DBG_871X("  old AID %d\n", pstat->aid);
} else {
-   for (pstat->aid = 1; pstat->aid <= NUM_STA; pstat->aid++)
+   for (pstat->aid = 1; pstat->aid < NUM_STA; pstat->aid++)
if (pstapriv->sta_aid[pstat->aid - 1] == NULL)
break;
 
@@ -2388,7 +2387,7 @@ s32 dump_mgntframe_and_wait(struct adapter *padapter, 
struct xmit_frame *pmgntfr
pxmitbuf->sctx = NULL;
spin_unlock_irqrestore(>lock_sctx, irqL);
 
-return ret;
+   return ret;
 }
 
 s32 dump_mgntframe_and_wait_ack(struct adapter *padapter, struct xmit_frame 
*pmgntframe)
@@ -2417,7 +2416,7 @@ s32 dump_mgntframe_and_wait_ack(struct adapter *padapter, 
struct xmit_frame *pmg
mutex_unlock(>ack_tx_mutex);
}
 
-return ret;
+   return ret;
 }
 
 static int update_hidden_ssid(u8 *ies, u32 ies_len, u8 hidden_ssid_mode)
@@ -5735,7 +5734,7 @@ void linked_status_chk(struct adapter *padapter)
#else
rx_chk_limit = 8;
#endif
-   link_count_limit = 7; /*  16 sec */
+   link_count_limit = 7; /*  16 sec */
 
/*  Marked by Kurt 20130715 */
/*  For WiDi 3.5 and latered on, they don't ask WiDi sink to do 
roaming, so we could not check rx limit that strictly. */
@@ -6456,7 +6455,7 @@ u8 sitesurvey_cmd_hdl(struct adapter *padapter, u8 *pbuf)
Switch_DM_Func(padapter, DYNAMIC_FUNC_DISABLE, false);
 
/* config the initial gain under scaning, need to write the BB 
registers */
-   initialgain = 0x1e;
+   initialgain = 0x1e;
 
rtw_hal_set_hwreg(padapter, HW_VAR_INITIAL_GAIN, (u8 
*)());
 
-- 
2.12.0

[PATCH 19/22] staging: rtl8723bs: Fix white-space errors in core/rtw_recv.c

[Larry Finger]

Smart reports the following:

  CHECK   drivers/staging/rtl8723bs/core/rtw_recv.c
drivers/staging/rtl8723bs/core/rtw_recv.c:598 portctrl() warn: inconsistent 
indenting
drivers/staging/rtl8723bs/core/rtw_recv.c:838 sta2sta_data_frame() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_recv.c:1547 validate_recv_frame() warn: 
inconsistent indenting

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8723bs/core/rtw_recv.c | 21 -
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_recv.c 
b/drivers/staging/rtl8723bs/core/rtw_recv.c
index 864538e8299d..6e98a1bd3e77 100644
--- a/drivers/staging/rtl8723bs/core/rtw_recv.c
+++ b/drivers/staging/rtl8723bs/core/rtw_recv.c
@@ -595,7 +595,7 @@ union recv_frame *portctrl(struct adapter *adapter, union 
recv_frame *precv_fram
memcpy(_tmp, ptr, 2);
ether_type = ntohs(be_tmp);
 
- if (ether_type == eapol_type)
+   if (ether_type == eapol_type)
prtnframe = precv_frame;
else {
/* free this frame */
@@ -827,17 +827,14 @@ sint sta2sta_data_frame(
sta_addr = pattrib->src;
 
} else if (check_fwstate(pmlmepriv, WIFI_STATION_STATE) == true) {
-   {
-   /*  For Station mode, sa and bssid should always be 
BSSID, and DA is my mac-address */
-   if (memcmp(pattrib->bssid, pattrib->src, ETH_ALEN)) {
-   RT_TRACE(_module_rtl871x_recv_c_, _drv_err_, 
("bssid != TA under STATION_MODE; drop pkt\n"));
-   ret = _FAIL;
-   goto exit;
-   }
-
-   sta_addr = pattrib->bssid;
+   /*  For Station mode, sa and bssid should always be BSSID, and 
DA is my mac-address */
+   if (memcmp(pattrib->bssid, pattrib->src, ETH_ALEN)) {
+   RT_TRACE(_module_rtl871x_recv_c_, _drv_err_, ("bssid != 
TA under STATION_MODE; drop pkt\n"));
+   ret = _FAIL;
+   goto exit;
}
 
+   sta_addr = pattrib->bssid;
} else if (check_fwstate(pmlmepriv, WIFI_AP_STATE) == true) {
if (bmcast) {
/*  For AP mode, if DA == MCAST, then BSSID should be 
also MCAST */
@@ -1517,6 +1514,7 @@ sint validate_recv_frame(struct adapter *adapter, union 
recv_frame *precv_frame)
u8 type;
u8 subtype;
sint retval = _SUCCESS;
+   u8 bDumpRxPkt;
 
struct rx_pkt_attrib *pattrib = _frame->u.hdr.attrib;
 
@@ -1544,8 +1542,6 @@ sint validate_recv_frame(struct adapter *adapter, union 
recv_frame *precv_frame)
pattrib->mdata = GetMData(ptr);
pattrib->privacy = GetPrivacy(ptr);
pattrib->order = GetOrder(ptr);
-{
-   u8 bDumpRxPkt;
rtw_hal_get_def_var(adapter, HAL_DEF_DBG_DUMP_RXPKT, &(bDumpRxPkt));
if (bDumpRxPkt == 1) /* dump all rx packets */
dump_rx_packet(ptr);
@@ -1553,7 +1549,6 @@ sint validate_recv_frame(struct adapter *adapter, union 
recv_frame *precv_frame)
dump_rx_packet(ptr);
else if ((bDumpRxPkt == 3) && (type == WIFI_DATA_TYPE))
dump_rx_packet(ptr);
-}
 
switch (type) {
case WIFI_MGT_TYPE: /* mgnt */
-- 
2.12.0

[PATCH 13/22] staging: rtl8723bs: Fix indenting mistake in core/rtw_ap.c

[Larry Finger]

Smatch reports the following:

  CHECK   drivers/staging/rtl8723bs/core/rtw_ap.c
drivers/staging/rtl8723bs/core/rtw_ap.c:382 expire_timeout_chk() warn: 
inconsistent indenting

Fixing this requires changing the indentatikon of a long for loop.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8723bs/core/rtw_ap.c | 99 -
 1 file changed, 47 insertions(+), 52 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c 
b/drivers/staging/rtl8723bs/core/rtw_ap.c
index 9c71692a3a05..68b750275dff 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ap.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ap.c
@@ -379,70 +379,65 @@ void expire_timeout_chk(struct adapter *padapter)
 
spin_unlock_bh(>asoc_list_lock);
 
-if (chk_alive_num) {
+   if (chk_alive_num) {
+   u8 backup_oper_channel = 0;
+   struct mlme_ext_priv *pmlmeext = >mlmeextpriv;
+
+   /* switch to correct channel of current network  before issue 
keep-alive frames */
+   if (rtw_get_oper_ch(padapter) != pmlmeext->cur_channel) {
+   backup_oper_channel = rtw_get_oper_ch(padapter);
+   SelectChannel(padapter, pmlmeext->cur_channel);
+   }
 
-   u8 backup_oper_channel = 0;
-   struct mlme_ext_priv *pmlmeext = >mlmeextpriv;
-   /* switch to correct channel of current network  before issue 
keep-alive frames */
-   if (rtw_get_oper_ch(padapter) != pmlmeext->cur_channel) {
-   backup_oper_channel = rtw_get_oper_ch(padapter);
-   SelectChannel(padapter, pmlmeext->cur_channel);
-   }
+   /* issue null data to check sta alive*/
+   for (i = 0; i < chk_alive_num; i++) {
+   int ret = _FAIL;
 
-   /* issue null data to check sta alive*/
-   for (i = 0; i < chk_alive_num; i++) {
-   int ret = _FAIL;
+   psta = rtw_get_stainfo_by_offset(pstapriv, 
chk_alive_list[i]);
+   if (!(psta->state & _FW_LINKED))
+   continue;
 
-   psta = rtw_get_stainfo_by_offset(pstapriv, chk_alive_list[i]);
-   if (!(psta->state & _FW_LINKED))
-   continue;
+   if (psta->state & WIFI_SLEEP_STATE)
+   ret = issue_nulldata(padapter, psta->hwaddr, 0, 
1, 50);
+   else
+   ret = issue_nulldata(padapter, psta->hwaddr, 0, 
3, 50);
 
-   if (psta->state & WIFI_SLEEP_STATE)
-   ret = issue_nulldata(padapter, psta->hwaddr, 0, 1, 50);
-   else
-   ret = issue_nulldata(padapter, psta->hwaddr, 0, 3, 50);
+   psta->keep_alive_trycnt++;
+   if (ret == _SUCCESS) {
+   DBG_871X(
+   "asoc check, sta(" MAC_FMT ") is 
alive\n",
+   MAC_ARG(psta->hwaddr)
+   );
+   psta->expire_to = pstapriv->expire_to;
+   psta->keep_alive_trycnt = 0;
+   continue;
+   } else if (psta->keep_alive_trycnt <= 3) {
 
-   psta->keep_alive_trycnt++;
-   if (ret == _SUCCESS) {
+   DBG_871X(
+   "ack check for asoc expire, 
keep_alive_trycnt =%d\n",
+   psta->keep_alive_trycnt);
+   psta->expire_to = 1;
+   continue;
+   }
 
-   DBG_871X(
-   "asoc check, sta(" MAC_FMT ") is alive\n",
-   MAC_ARG(psta->hwaddr)
-   );
-   psta->expire_to = pstapriv->expire_to;
psta->keep_alive_trycnt = 0;
-   continue;
-   } else if (psta->keep_alive_trycnt <= 3) {
-
-
DBG_871X(
-   "ack check for asoc expire, keep_alive_trycnt 
=%d\n",
-   psta->keep_alive_trycnt
-   );
-   psta->expire_to = 1;
-   continue;
-   }
-
-   psta->keep_alive_trycnt = 0;
-   DBG_871X(
-   "asoc expire "MAC_FMT", state = 0x%x\n",
-   MAC_ARG(psta->hwaddr),
-   psta->state
-   );
-   spin_lock_bh(>asoc_list_lock);
-

[PATCH 21/22] staging: rtl8723bs: Fix indenting problems in core/rtw_odm.c

[Larry Finger]

Smatch reports the following:

  CHECK   drivers/staging/rtl8723bs/core/rtw_odm.c
drivers/staging/rtl8723bs/core/rtw_odm.c:109 rtw_odm_dbg_comp_msg() warn: if 
statement not indented
drivers/staging/rtl8723bs/core/rtw_odm.c:146 rtw_odm_ability_msg() warn: if 
statement not indented

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8723bs/core/rtw_odm.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_odm.c 
b/drivers/staging/rtl8723bs/core/rtw_odm.c
index 5bc573386ad1..3144e8ec2fa2 100644
--- a/drivers/staging/rtl8723bs/core/rtw_odm.c
+++ b/drivers/staging/rtl8723bs/core/rtw_odm.c
@@ -107,8 +107,9 @@ void rtw_odm_dbg_comp_msg(void *sel, struct adapter 
*adapter)
DBG_871X_SEL_NL(sel, "odm.DebugComponents = 0x%016llx\n", dbg_comp);
for (i = 0; i < RTW_ODM_COMP_MAX; i++) {
if (odm_comp_str[i])
-   DBG_871X_SEL_NL(sel, "%cBIT%-2d %s\n",
-   (BIT0 << i) & dbg_comp ? '+' : ' ', i, odm_comp_str[i]);
+   DBG_871X_SEL_NL(sel, "%cBIT%-2d %s\n",
+   (BIT0 << i) & dbg_comp ? '+' : ' ',
+   i, odm_comp_str[i]);
}
 }
 
@@ -144,8 +145,9 @@ void rtw_odm_ability_msg(void *sel, struct adapter *adapter)
DBG_871X_SEL_NL(sel, "odm.SupportAbility = 0x%08x\n", ability);
for (i = 0; i < RTW_ODM_ABILITY_MAX; i++) {
if (odm_ability_str[i])
-   DBG_871X_SEL_NL(sel, "%cBIT%-2d %s\n",
-   (BIT0 << i) & ability ? '+' : ' ', i, 
odm_ability_str[i]);
+   DBG_871X_SEL_NL(sel, "%cBIT%-2d %s\n",
+   (BIT0 << i) & ability ? '+' : ' ', i,
+   odm_ability_str[i]);
}
 }
 
-- 
2.12.0

[PATCH 15/22] staging: rtl8723bs: Fix indenting mistakes in core/rtw_mlme.c

[Larry Finger]

Smatch reports the following:

  CHECK   drivers/staging/rtl8723bs/core/rtw_mlme.c
drivers/staging/rtl8723bs/core/rtw_mlme.c:862 rtw_survey_event_callback() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_mlme.c:1102 rtw_free_assoc_resources() warn: 
if statement not indented
drivers/staging/rtl8723bs/core/rtw_mlme.c:1165 rtw_indicate_disconnect() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_mlme.c:2830 rtw_restructure_ht_ie() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_mlme.c:2991 rtw_update_ht_cap() warn: 
inconsistent indenting

All of there are simple white-space errors. A typo is also fixed.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8723bs/core/rtw_mlme.c | 37 +++
 1 file changed, 18 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c 
b/drivers/staging/rtl8723bs/core/rtw_mlme.c
index c95e0626b522..53755e5b97a6 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
@@ -856,7 +856,7 @@ void rtw_survey_event_callback(struct adapter   
*adapter, u8 *pbuf)
 
/*  lock pmlmepriv->lock when you accessing network_q */
if ((check_fwstate(pmlmepriv, _FW_UNDER_LINKING)) == false) {
- if (pnetwork->Ssid.Ssid[0] == 0) {
+   if (pnetwork->Ssid.Ssid[0] == 0) {
pnetwork->Ssid.SsidLength = 0;
}
rtw_add_network(adapter, pnetwork);
@@ -1100,8 +1100,7 @@ void rtw_free_assoc_resources(struct adapter *adapter, 
int lock_scanned_queue)
}
 
if (lock_scanned_queue)
-
-   adapter->securitypriv.key_mask = 0;
+   adapter->securitypriv.key_mask = 0;
 
rtw_reset_rx_info(pdbgpriv);
 }
@@ -1162,7 +1161,7 @@ void rtw_indicate_disconnect(struct adapter *padapter)
/* set ips_deny_time to avoid enter IPS before LPS leave */
rtw_set_ips_deny(padapter, 3000);
 
- _clr_fwstate_(pmlmepriv, _FW_LINKED);
+   _clr_fwstate_(pmlmepriv, _FW_LINKED);
 
rtw_clear_scan_deny(padapter);
}
@@ -2826,8 +2825,8 @@ unsigned int rtw_restructure_ht_ie(struct adapter 
*padapter, u8 *in_ie, u8 *out_
if (stbc_rx_enable)
ht_capie.cap_info |= 
cpu_to_le16(IEEE80211_HT_CAP_RX_STBC_1R);/* RX STBC One spatial stream */
 
-   set_mcs_rate_by_mask(ht_capie.supp_mcs_set, MCS_RATE_1R);
-   break;
+   set_mcs_rate_by_mask(ht_capie.supp_mcs_set, MCS_RATE_1R);
+   break;
 
case RF_2T2R:
case RF_1T2R:
@@ -2984,22 +2983,22 @@ void rtw_update_ht_cap(struct adapter *padapter, u8 
*pie, uint ie_len, u8 channe
 #else /* CONFIG_DISABLE_MCS13TO15 */

set_mcs_rate_by_mask(pmlmeinfo->HT_caps.u.HT_cap_element.MCS_rate, MCS_RATE_2R);
 #endif /* CONFIG_DISABLE_MCS13TO15 */
-   }
+   }
 
-   /* switch to the 40M Hz mode accoring to the AP */
-   /* pmlmeext->cur_bwmode = CHANNEL_WIDTH_40; */
-   switch ((pmlmeinfo->HT_info.infos[0] & 0x3)) {
-   case EXTCHNL_OFFSET_UPPER:
-   pmlmeext->cur_ch_offset = HAL_PRIME_CHNL_OFFSET_LOWER;
-   break;
+   /* switch to the 40M Hz mode according to the AP */
+   /* pmlmeext->cur_bwmode = CHANNEL_WIDTH_40; */
+   switch ((pmlmeinfo->HT_info.infos[0] & 0x3)) {
+   case EXTCHNL_OFFSET_UPPER:
+   pmlmeext->cur_ch_offset = HAL_PRIME_CHNL_OFFSET_LOWER;
+   break;
 
-   case EXTCHNL_OFFSET_LOWER:
-   pmlmeext->cur_ch_offset = HAL_PRIME_CHNL_OFFSET_UPPER;
-   break;
+   case EXTCHNL_OFFSET_LOWER:
+   pmlmeext->cur_ch_offset = HAL_PRIME_CHNL_OFFSET_UPPER;
+   break;
 
-   default:
-   pmlmeext->cur_ch_offset = HAL_PRIME_CHNL_OFFSET_DONT_CARE;
-   break;
+   default:
+   pmlmeext->cur_ch_offset = 
HAL_PRIME_CHNL_OFFSET_DONT_CARE;
+   break;
}
}
 
-- 
2.12.0

[PATCH 17/22] staging: rtl8723bs: Fix indenting problem in core/rtw_sta_mgt.c

[Larry Finger]

Sparse reports the following:

  CHECK   drivers/staging/rtl8723bs/core/rtw_sta_mgt.c
drivers/staging/rtl8723bs/core/rtw_sta_mgt.c:25 _rtw_init_stainfo() warn: 
inconsistent indenting

This problem is fixed with a white-spcae change.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8723bs/core/rtw_sta_mgt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_sta_mgt.c 
b/drivers/staging/rtl8723bs/core/rtw_sta_mgt.c
index d7eee6dd7e3b..cb43ec90a648 100644
--- a/drivers/staging/rtl8723bs/core/rtw_sta_mgt.c
+++ b/drivers/staging/rtl8723bs/core/rtw_sta_mgt.c
@@ -22,7 +22,7 @@ void _rtw_init_stainfo(struct sta_info *psta)
 {
memset((u8 *)psta, 0, sizeof(struct sta_info));
 
-spin_lock_init(>lock);
+   spin_lock_init(>lock);
INIT_LIST_HEAD(>list);
INIT_LIST_HEAD(>hash_list);
/* INIT_LIST_HEAD(>asoc_list); */
-- 
2.12.0

[PATCH 16/22] staging: rtl8723bs: Fix some indenting problems and a potential data overrun

[Larry Finger]

Smatch reports the following:

  CHECK   drivers/staging/rtl8723bs/core/rtw_wlan_util.c
drivers/staging/rtl8723bs/core/rtw_wlan_util.c:67 cckrates_included() warn: if 
statement not indented
drivers/staging/rtl8723bs/core/rtw_wlan_util.c:81 cckratesonly_included() warn: 
if statement not indented
drivers/staging/rtl8723bs/core/rtw_wlan_util.c:815 rtw_camid_alloc() warn: 
should '1 << (cam_id)' be a 64 bit type?

The first two are fixed with white-space changes. The third is fixed by
restricting cam_id to be less than 32.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8723bs/core/rtw_wlan_util.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c 
b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
index c966241df2ea..f485f541e36d 100644
--- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
@@ -65,8 +65,8 @@ int cckrates_included(unsigned char *rate, int ratelen)
 
for (i = 0; i < ratelen; i++) {
if  rate[i]) & 0x7f) == 2)  || (((rate[i]) & 0x7f) == 4) ||
-  (((rate[i]) & 0x7f) == 11)  || (((rate[i]) & 0x7f) 
== 22))
-   return true;
+(((rate[i]) & 0x7f) == 11)  || (((rate[i]) & 0x7f) == 22))
+   return true;
}
 
return false;
@@ -79,8 +79,8 @@ int cckratesonly_included(unsigned char *rate, int ratelen)
 
for (i = 0; i < ratelen; i++) {
if  rate[i]) & 0x7f) != 2) && (((rate[i]) & 0x7f) != 4) &&
-  (((rate[i]) & 0x7f) != 11)  && (((rate[i]) & 0x7f) 
!= 22))
-   return false;
+(((rate[i]) & 0x7f) != 11)  && (((rate[i]) & 0x7f) != 22))
+   return false;
}
 
return true;
@@ -811,7 +811,7 @@ s16 rtw_camid_alloc(struct adapter *adapter, struct 
sta_info *sta, u8 kid)
}
 
 bitmap_handle:
-   if (cam_id >= 0)
+   if (cam_id >= 0 && cam_id < 32)
cam_ctl->bitmap |= BIT(cam_id);
 
spin_unlock_bh(_ctl->lock);
-- 
2.12.0

[PATCH 18/22] staging: rtl8723bs: Fix some white-space errors in core/rtw_security.c

[Larry Finger]

Smatch reports the following:

  CHECK   drivers/staging/rtl8723bs/core/rtw_security.c
drivers/staging/rtl8723bs/core/rtw_security.c:266 rtw_wep_encrypt() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_security.c:433 rtw_seccalctkipmic() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_security.c:749 rtw_tkip_encrypt() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_security.c:865 rtw_tkip_decrypt() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_security.c:1383 aes_cipher() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_security.c:1415 aes_cipher() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_security.c:1430 aes_cipher() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_security.c:1582 rtw_aes_encrypt() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_security.c:1651 aes_decipher() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_security.c:1739 aes_decipher() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_security.c:1792 aes_decipher() warn: curly 
braces intended?
drivers/staging/rtl8723bs/core/rtw_security.c:1809 aes_decipher() warn: 
inconsistent indenting

All of the above are fixed with white-space changes. A few unneeded
blank lines are deleted.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8723bs/core/rtw_security.c | 469 +-
 1 file changed, 229 insertions(+), 240 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_security.c 
b/drivers/staging/rtl8723bs/core/rtw_security.c
index 698e11e5d0a9..e832f16997b7 100644
--- a/drivers/staging/rtl8723bs/core/rtw_security.c
+++ b/drivers/staging/rtl8723bs/core/rtw_security.c
@@ -262,17 +262,15 @@ void rtw_wep_encrypt(struct adapter *padapter, u8 
*pxmitframe)
arcfour_encrypt(, payload+length, 
crc, 4);
 
} else{
-   length = 
pxmitpriv->frag_len-pattrib->hdrlen-pattrib->iv_len-pattrib->icv_len;
+   length = 
pxmitpriv->frag_len-pattrib->hdrlen-pattrib->iv_len-pattrib->icv_len;
*((__le32 *)crc) = getcrc32(payload, length);
arcfour_init(, wepkey, 3+keylength);
arcfour_encrypt(, payload, payload, 
length);
arcfour_encrypt(, payload+length, 
crc, 4);
 
-   pframe += pxmitpriv->frag_len;
-   pframe = (u8 *)RND4((SIZE_PTR)(pframe));
-
+   pframe += pxmitpriv->frag_len;
+   pframe = (u8 *)RND4((SIZE_PTR)(pframe));
}
-
}
 
WEP_SW_ENC_CNT_INC(psecuritypriv, pattrib->ra);
@@ -429,7 +427,7 @@ void rtw_seccalctkipmic(u8 *key, u8 *header, u8 *data, u32 
data_len, u8 *mic_cod
 
/* Michael MIC pseudo header: DA, SA, 3 x 0, Priority */
if (header[1]&1) {   /* ToDS == 1 */
-   rtw_secmicappend(, [16], 6);  /* DA */
+   rtw_secmicappend(, [16], 6);  /* DA */
if (header[1]&2)  /* From Ds == 1 */
rtw_secmicappend(, [24], 6);
else
@@ -746,9 +744,8 @@ u32 rtw_tkip_encrypt(struct adapter *padapter, u8 
*pxmitframe)
arcfour_encrypt(, payload, 
payload, length);
arcfour_encrypt(, 
payload+length, crc, 4);
 
-   pframe += pxmitpriv->frag_len;
-   pframe = (u8 *)RND4((SIZE_PTR)(pframe));
-
+   pframe += pxmitpriv->frag_len;
+   pframe = (u8 *)RND4((SIZE_PTR)(pframe));
}
}
 
@@ -791,10 +788,8 @@ u32 rtw_tkip_decrypt(struct adapter *padapter, u8 
*precvframe)
 
/* 4 start to decrypt recvframe */
if (prxattrib->encrypt == _TKIP_) {
-
stainfo = rtw_get_stainfo(>stapriv, 
>ta[0]);
if (stainfo != NULL) {
-
if (IS_MCAST(prxattrib->ra)) {
static unsigned long start = 0;
static u32 no_gkey_bc_cnt = 0;
@@ -860,8 +855,9 @@ u32 rtw_tkip_decrypt(struct adapter *padapter, u8 
*precvframe)
*((u32 *)crc) = le32_to_cpu(getcrc32(payload, 
length-4));
 
if (crc[3] != payload[length-1] || crc[2] != 
payload[length-2] || crc[1] != payload[length-3] || crc[0] != 
payload[length-4]) {
-   RT_TRACE(_module_rtl871x_security_c_, _drv_err_, 
("rtw_wep_decrypt:icv error crc[3](%x)!=payload[length-1](%x) || 
crc[2](%x)!=payload[length-2](%x) || crc

[PATCH 22/22] staging: rtl8723bs: Fix indenting error in core/rtw_pwrctrl.c

[Larry Finger]

Smatch reports the following:

  CHECK   drivers/staging/rtl8723bs/core/rtw_pwrctrl.c
drivers/staging/rtl8723bs/core/rtw_pwrctrl.c:641 LeaveAllPowerSaveModeDirect() 
warn: inconsistent indenting

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8723bs/core/rtw_pwrctrl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_pwrctrl.c 
b/drivers/staging/rtl8723bs/core/rtw_pwrctrl.c
index c5dd794dac4b..f708dbf5bfd4 100644
--- a/drivers/staging/rtl8723bs/core/rtw_pwrctrl.c
+++ b/drivers/staging/rtl8723bs/core/rtw_pwrctrl.c
@@ -638,7 +638,7 @@ void LeaveAllPowerSaveModeDirect(struct adapter *Adapter)
 
rtw_set_rpwm(Adapter, PS_STATE_S4);
 
-   up(>lock);
+   up(>lock);
 
rtw_lps_ctrl_wk_cmd(pri_padapter, LPS_CTRL_LEAVE, 0);
} else{
-- 
2.12.0

[PATCH 07/22] staging: rtl8723bs: Fix potential usage while NULL error in hal/rtl8723b_hal_init.c

[Larry Finger]

Smatch logs the following:

  CHECK   drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c:518 
rtl8723b_FirmwareDownload() error: we previously assumed 'pFirmware' could be 
null (see line 382)

Fixing this error required a rewrite of the error exits from this routine.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c 
b/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
index b7f6dc7ce318..d40ad03e99a3 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
@@ -377,13 +377,13 @@ s32 rtl8723b_FirmwareDownload(struct adapter *padapter, 
bool  bUsedWoWLANFw)
RT_TRACE(_module_hal_init_c_, _drv_notice_, ("+%s, bUsedWoWLANFw:%d\n", 
__func__, bUsedWoWLANFw));
 #endif
pFirmware = kzalloc(sizeof(struct rt_firmware), GFP_KERNEL);
+   if (!pFirmware)
+   return _FAIL;
pBTFirmware = kzalloc(sizeof(struct rt_firmware), GFP_KERNEL);
-
-   if (!pFirmware || !pBTFirmware) {
-   rtStatus = _FAIL;
-   goto exit;
+   if (!pBTFirmware) {
+   kfree(pFirmware);
+   return _FAIL;
}
-
tmp_ps = rtw_read8(padapter, 0xa3);
tmp_ps &= 0xf8;
tmp_ps |= 0x02;
@@ -441,7 +441,7 @@ s32 rtl8723b_FirmwareDownload(struct adapter *padapter, 
bool  bUsedWoWLANFw)
if (pFirmware->ulFwLength > FW_8723B_SIZE) {
rtStatus = _FAIL;
DBG_871X_LEVEL(_drv_emerg_, "Firmware size:%u exceed %u\n", 
pFirmware->ulFwLength, FW_8723B_SIZE);
-   goto exit;
+   goto release_fw1;
}
 
pFirmwareBuf = pFirmware->szFwBuffer;
@@ -517,6 +517,7 @@ s32 rtl8723b_FirmwareDownload(struct adapter *padapter, 
bool  bUsedWoWLANFw)
 exit:
kfree(pFirmware->szFwBuffer);
kfree(pFirmware);
+release_fw1:
kfree(pBTFirmware);
DBG_871X(" <=== rtl8723b_FirmwareDownload()\n");
return rtStatus;
-- 
2.12.0

[PATCH 10/22] staging: rtl8723bs: Fix indenting problem for hal/hal_com.c

[Larry Finger]

Smatch lists the following:

  CHECK   drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
drivers/staging/rtl8723bs/hal/hal_com_phycfg.c:2090 
Hal_ChannelPlanToRegulation() warn: inconsistent indenting

Fixed by changing the white space.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8723bs/hal/hal_com.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/rtl8723bs/hal/hal_com.c 
b/drivers/staging/rtl8723bs/hal/hal_com.c
index 093978d8f2a4..1880d4140bee 100644
--- a/drivers/staging/rtl8723bs/hal/hal_com.c
+++ b/drivers/staging/rtl8723bs/hal/hal_com.c
@@ -1731,11 +1731,11 @@ void rtw_bb_rf_gain_offset(struct adapter *padapter)
for (i = 0; i < ArrayLen; i += 2) {
v1 = Array[i];
v2 = Array[i+1];
-if (v1 == 
padapter->eeprompriv.EEPROMRFGainVal) {
-   DBG_871X("Offset RF Gain. got 
v1 = 0x%x , v2 = 0x%x\n", v1, v2);
-   target = v2;
-   break;
-}
+   if (v1 == padapter->eeprompriv.EEPROMRFGainVal) 
{
+   DBG_871X("Offset RF Gain. got v1 = 0x%x 
, v2 = 0x%x\n", v1, v2);
+   target = v2;
+   break;
+   }
}
DBG_871X("padapter->eeprompriv.EEPROMRFGainVal = 0x%x , 
Gain offset Target Value = 0x%x\n", padapter->eeprompriv.EEPROMRFGainVal, 
target);
PHY_SetRFReg(padapter, RF_PATH_A, 
REG_RF_BB_GAIN_OFFSET, BIT18|BIT17|BIT16|BIT15, target);
-- 
2.12.0

[PATCH 14/22] staging: rtl8723bs: Fix indenting mistakes in core/rtw_ieee80211.c

[Larry Finger]

Smatch reports the following:

  CHECK   drivers/staging/rtl8723bs/core/rtw_ieee80211.c
drivers/staging/rtl8723bs/core/rtw_ieee80211.c:83 rtw_is_cckrates_included() 
warn: if statement not indented
drivers/staging/rtl8723bs/core/rtw_ieee80211.c:98 
rtw_is_cckratesonly_included() warn: if statement not indented

These warnings are fixed with white-space changes.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8723bs/core/rtw_ieee80211.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c 
b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
index af44a8cd26f8..4670e72368e5 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
@@ -81,8 +81,8 @@ uint  rtw_is_cckrates_included(u8 *rate)
 
while (rate[i] !=  0) {
if  rate[i]) & 0x7f) == 2)  || (((rate[i]) & 0x7f) 
== 4) ||
-   (((rate[i]) & 0x7f) == 11)  || (((rate[i]) & 0x7f) == 
22))
-   return true;
+(((rate[i]) & 0x7f) == 11)  || (((rate[i]) & 0x7f) 
== 22))
+   return true;
i++;
}
 
@@ -95,16 +95,13 @@ uintrtw_is_cckratesonly_included(u8 *rate)
 
 
while (rate[i] != 0) {
-   if  rate[i]) & 0x7f) != 2) && (((rate[i]) & 0x7f) 
!= 4) &&
-   (((rate[i]) & 0x7f) != 11)  && (((rate[i]) & 
0x7f) != 22))
-
+   if  rate[i]) & 0x7f) != 2) && (((rate[i]) & 0x7f) != 4) &&
+(((rate[i]) & 0x7f) != 11)  && (((rate[i]) & 0x7f) != 22))
return false;
-
-   i++;
+   i++;
}
 
return true;
-
 }
 
 int rtw_check_network_type(unsigned char *rate, int ratelen, int channel)
-- 
2.12.0

[PATCH 09/22] staging: rtl8723bs: Fix indening problem in hal/hal_com_phycfg.c

[Larry Finger]

Smatch reports the following:

  CHECK   drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
drivers/staging/rtl8723bs/hal/hal_com_phycfg.c:2090 
Hal_ChannelPlanToRegulation() warn: inconsistent indenting

This warning is fixed with a white-space change.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8723bs/hal/hal_com_phycfg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c 
b/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
index 95fff20e9c4b..566b6f0997da 100644
--- a/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
+++ b/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
@@ -2087,7 +2087,7 @@ void Hal_ChannelPlanToRegulation(struct adapter *Adapter, 
u16 ChannelPlan)
case RT_CHANNEL_DOMAIN_WORLD_FCC2:
pHalData->Regulation2_4G = TXPWR_LMT_FCC;
pHalData->Regulation5G = TXPWR_LMT_FCC;
-   break;
+   break;
case RT_CHANNEL_DOMAIN_WORLD_FCC3:
pHalData->Regulation2_4G = TXPWR_LMT_FCC;
pHalData->Regulation5G = TXPWR_LMT_FCC;
-- 
2.12.0

[PATCH 05/22] staging: rtl8723bs: Fix indenting mistake in os_dep/mlme_linux.c

[Larry Finger]

Smatch reports the following warning:

  CHECK   drivers/staging/rtl8723bs/os_dep/mlme_linux.c
drivers/staging/rtl8723bs/os_dep/mlme_linux.c:149 rtw_os_indicate_disconnect() 
warn: inconsistent indenting

Again, a simple change in the white space fixes this problem.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8723bs/os_dep/mlme_linux.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/mlme_linux.c 
b/drivers/staging/rtl8723bs/os_dep/mlme_linux.c
index aa1793389797..46315d1a82f7 100644
--- a/drivers/staging/rtl8723bs/os_dep/mlme_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/mlme_linux.c
@@ -145,8 +145,8 @@ void rtw_os_indicate_disconnect(struct adapter *adapter)
 
rtw_indicate_wx_disassoc_event(adapter);
 
-/* modify for CONFIG_IEEE80211W, none 11w also can use the same 
command */
-rtw_reset_securitypriv_cmd(adapter);
+   /* modify for CONFIG_IEEE80211W, none 11w also can use the same command 
*/
+   rtw_reset_securitypriv_cmd(adapter);
 }
 
 void rtw_report_sec_ie(struct adapter *adapter, u8 authmode, u8 *sec_ie)
-- 
2.12.0

[PATCH 12/22] staging: rtl8723bs: Fix possible usage of NULL pointer in core/rtw_debug.c

[Larry Finger]

Smatch reports the following:

  CHECK   drivers/staging/rtl8723bs/core/rtw_debug.c
drivers/staging/rtl8723bs/core/rtw_debug.c:454 proc_get_survey_info() error: we 
previously assumed 'phead' could be null (see line 453)
drivers/staging/rtl8723bs/core/rtw_debug.c:455 proc_get_survey_info() warn: 
variable dereferenced before check 'phead' (see line 454)

In the code, there are two successive calls to get_head(). The second
is removed.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8723bs/core/rtw_debug.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_debug.c 
b/drivers/staging/rtl8723bs/core/rtw_debug.c
index d34747b29309..51cef55d3f76 100644
--- a/drivers/staging/rtl8723bs/core/rtw_debug.c
+++ b/drivers/staging/rtl8723bs/core/rtw_debug.c
@@ -451,7 +451,6 @@ int proc_get_survey_info(struct seq_file *m, void *v)
spin_lock_bh(&(pmlmepriv->scanned_queue.lock));
phead = get_list_head(queue);
plist = phead ? get_next(phead) : NULL;
-   plist = get_next(phead);
if ((!phead) || (!plist)) {
spin_unlock_bh(&(pmlmepriv->scanned_queue.lock));
return 0;
-- 
2.12.0

[PATCH 06/22] staging: rtl8723bs: Fix various errors in os_dep/ioctl_cfg80211.c

[Larry Finger]

Smatch lists the following:

  CHECK   drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:470 
rtw_cfg80211_ibss_indicate_connect() error: we previously assumed 'scanned' 
could be null (see line 466)
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:942 
rtw_cfg80211_set_encryption() warn: inconsistent indenting
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:955 
rtw_cfg80211_set_encryption() error: buffer overflow 
'psecuritypriv->dot11DefKey' 4 <= 4
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:1017 
rtw_cfg80211_set_encryption() error: buffer overflow 
'padapter->securitypriv.dot118021XGrpKey' 5 <= 5
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:1216 
cfg80211_rtw_set_default_key() warn: inconsistent indenting
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:2498 
rtw_cfg80211_monitor_if_xmit_entry() error: we previously assumed 'skb' could 
be null (see line 2495)
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:2850 cfg80211_rtw_start_ap() 
warn: if statement not indented
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:2860 cfg80211_rtw_start_ap() 
warn: if statement not indented
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3417 
rtw_cfg80211_preinit_wiphy() warn: inconsistent indenting
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3547 rtw_wdev_alloc() info: 
ignoring unreachable code.

The indenting warnings were fixed by simple white space changes.

The section where 'scanned' could be null required an immediate exit from
the routine at that point. A similar fix was required where 'skb' could be null.

The two buffer overflow errors were caused by off-by-one errors. While
locating these problems, another one was found in os_dep/ioctl_linux.c.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 38 +--
 drivers/staging/rtl8723bs/os_dep/ioctl_linux.c|  2 +-
 2 files changed, 15 insertions(+), 25 deletions(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index ce7cca68ff7a..d2c66041a561 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -463,9 +463,10 @@ void rtw_cfg80211_ibss_indicate_connect(struct adapter 
*padapter)
}
else
{
-   if (scanned == NULL)
+   if (scanned == NULL) {
rtw_warn_on(1);
-
+   return;
+   }
if (!memcmp(&(scanned->network.Ssid), 
&(pnetwork->Ssid), sizeof(struct ndis_802_11_ssid))
&& !memcmp(scanned->network.MacAddress, 
pnetwork->MacAddress, sizeof(NDIS_802_11_MAC_ADDRESS))
) {
@@ -906,7 +907,7 @@ static int rtw_cfg80211_set_encryption(struct net_device 
*dev, struct ieee_param
param->sta_addr[4] == 0xff && param->sta_addr[5] == 0xff)
{
if (param->u.crypt.idx >= WEP_KEYS
-   && param->u.crypt.idx > BIP_MAX_KEYID
+   || param->u.crypt.idx >= BIP_MAX_KEYID
)
{
ret = -EINVAL;
@@ -927,7 +928,7 @@ static int rtw_cfg80211_set_encryption(struct net_device 
*dev, struct ieee_param
wep_key_idx = param->u.crypt.idx;
wep_key_len = param->u.crypt.key_len;
 
-   if ((wep_key_idx > WEP_KEYS) || (wep_key_len <= 0))
+   if ((wep_key_idx >= WEP_KEYS) || (wep_key_len <= 0))
{
ret = -EINVAL;
goto exit;
@@ -939,7 +940,7 @@ static int rtw_cfg80211_set_encryption(struct net_device 
*dev, struct ieee_param
 
wep_key_len = wep_key_len <= 5 ? 5 : 13;
 
-   psecuritypriv->ndisencryptstatus = Ndis802_11Encryption1Enabled;
+   psecuritypriv->ndisencryptstatus = 
Ndis802_11Encryption1Enabled;
psecuritypriv->dot11PrivacyAlgrthm = _WEP40_;
psecuritypriv->dot118021XGrpPrivacy = _WEP40_;
 
@@ -1213,11 +1214,8 @@ static int cfg80211_rtw_set_default_key(struct wiphy 
*wiphy,
struct adapter *padapter = (struct adapter *)rtw_netdev_priv(ndev);
struct security_priv *psecuritypriv = >securitypriv;
 
-   DBG_871X(FUNC_NDEV_FMT" key_index =%d"
-   ", unicast =%d, multicast =%d"
-   ".\n", FUNC_NDEV_ARG(ndev), key_index
-   , unicast, multicast
-   );
+   DBG_871X(FUNC_NDEV_FMT" key_index =%d, unicast =%d, multicast =%d\n",
+FUNC_NDEV_ARG(ndev), key_index, unicast, mult

[PATCH 08/22] staging: rtl8723bs: Fix indenting problems in hal/HalHWImg8723B_BB.c

[Larry Finger]

Smatch lists the following:

  CHECK   drivers/staging/rtl8723bs/hal/HalHWImg8723B_BB.c
drivers/staging/rtl8723bs/hal/HalHWImg8723B_BB.c:314 
ODM_ReadAndConfig_MP_8723B_AGC_TAB() warn: for statement not indented
drivers/staging/rtl8723bs/hal/HalHWImg8723B_BB.c:583 
ODM_ReadAndConfig_MP_8723B_PHY_REG() warn: for statement not indented
drivers/staging/rtl8723bs/hal/HalHWImg8723B_BB.c:586 
ODM_ReadAndConfig_MP_8723B_PHY_REG() warn: inconsistent indenting

These were all fixed with white-space changes.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8723bs/hal/HalHWImg8723B_BB.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8723bs/hal/HalHWImg8723B_BB.c 
b/drivers/staging/rtl8723bs/hal/HalHWImg8723B_BB.c
index b42f06076f93..51d4219177d3 100644
--- a/drivers/staging/rtl8723bs/hal/HalHWImg8723B_BB.c
+++ b/drivers/staging/rtl8723bs/hal/HalHWImg8723B_BB.c
@@ -312,7 +312,7 @@ void ODM_ReadAndConfig_MP_8723B_AGC_TAB(PDM_ODM_T pDM_Odm)
*   Discard the following (offset, data) pairs.
*/
while (v1 < 0x4000 && i < ArrayLen-2)
-   READ_NEXT_PAIR(v1, v2, i);
+   READ_NEXT_PAIR(v1, v2, i);
 
i -= 2; /*  prevent from for-loop += 2 */
} else {
@@ -581,9 +581,9 @@ void ODM_ReadAndConfig_MP_8723B_PHY_REG(PDM_ODM_T pDM_Odm)
*   Discard the following (offset, data) pairs.
*/
while (v1 < 0x4000 && i < ArrayLen-2)
-   READ_NEXT_PAIR(v1, v2, i);
+   READ_NEXT_PAIR(v1, v2, i);
 
-   i -= 2; /*  prevent from for-loop += 2 
*/
+   i -= 2; /*  prevent from for-loop += 2 */
} else { /*  Configure matched pairs and skip to end of 
if-else. */
while (v1 < 0x4000 && i < ArrayLen-2) {
odm_ConfigBB_PHY_8723B(pDM_Odm, v1, 
bMaskDWord, v2);
-- 
2.12.0

[PATCH 11/22] staging: rtl8723bs: Fix indenting problems in core/rtw_xmit.c

[Larry Finger]

Smatch logs the following:

  CHECK   drivers/staging/rtl8723bs/core/rtw_xmit.c
drivers/staging/rtl8723bs/core/rtw_xmit.c:277 _rtw_init_xmit_priv() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_xmit.c:294 _rtw_free_xmit_priv() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_xmit.c:295 _rtw_free_xmit_priv() warn: 
inconsistent indenting
drivers/staging/rtl8723bs/core/rtw_xmit.c:946 xmitframe_addmic() warn: 
inconsistent indenting

These are fixed with white-space changes.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8723bs/core/rtw_xmit.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_xmit.c 
b/drivers/staging/rtl8723bs/core/rtw_xmit.c
index 60585540069a..8f2c9a6658bf 100644
--- a/drivers/staging/rtl8723bs/core/rtw_xmit.c
+++ b/drivers/staging/rtl8723bs/core/rtw_xmit.c
@@ -274,7 +274,7 @@ s32 _rtw_init_xmit_priv(struct xmit_priv *pxmitpriv, struct 
adapter *padapter)
rtw_alloc_hwxmits(padapter);
rtw_init_hwxmits(pxmitpriv->hwxmits, pxmitpriv->hwxmit_entry);
 
-  for (i = 0; i < 4; i++) {
+   for (i = 0; i < 4; i++) {
pxmitpriv->wmm_para_seq[i] = i;
}
 
@@ -290,8 +290,8 @@ s32 _rtw_init_xmit_priv(struct xmit_priv *pxmitpriv, struct 
adapter *padapter)
 
 void _rtw_free_xmit_priv(struct xmit_priv *pxmitpriv)
 {
-   int i;
-  struct adapter *padapter = pxmitpriv->adapter;
+   int i;
+   struct adapter *padapter = pxmitpriv->adapter;
struct xmit_frame   *pxmitframe = (struct xmit_frame *) 
pxmitpriv->pxmit_frame_buf;
struct xmit_buf *pxmitbuf = (struct xmit_buf *)pxmitpriv->pxmitbuf;
 
@@ -942,8 +942,8 @@ static s32 xmitframe_addmic(struct adapter *padapter, 
struct xmit_frame *pxmitfr
 
}
 
-  /* if (pqospriv->qos_option == 1) */
-  if (pattrib->qos_en)
+   /* if (pqospriv->qos_option == 1) */
+   if (pattrib->qos_en)
priority[0] = (u8)pxmitframe->attrib.priority;
 
 
-- 
2.12.0

[PATCH 01/22] staging: rtl8723bs: Fix indenting warning in os_dep/xmit_linux.c

[Larry Finger]

Smatch issues the warning

  CHECK   drivers/staging/rtl8723bs/os_dep/xmit_linux.c
drivers/staging/rtl8723bs/os_dep/xmit_linux.c:42 _rtw_pktfile_read() warn: 
inconsistent indenting

A simple indent changes fixes this.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8723bs/os_dep/xmit_linux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/xmit_linux.c 
b/drivers/staging/rtl8723bs/os_dep/xmit_linux.c
index 5ede3b6fbdec..66dfec18f770 100644
--- a/drivers/staging/rtl8723bs/os_dep/xmit_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/xmit_linux.c
@@ -39,7 +39,7 @@ uint _rtw_pktfile_read (struct pkt_file *pfile, u8 *rmem, 
uint rlen)
len =  rtw_remainder_len(pfile);
len = (rlen > len)? len: rlen;
 
-   if (rmem)
+   if (rmem)
skb_copy_bits(pfile->pkt, pfile->buf_len-pfile->pkt_len, rmem, 
len);
 
pfile->cur_addr += len;
-- 
2.12.0

[PATCH 02/22] staging: rtl8723bs: Fix indenting warning in os_dep/rtw_proc.c

[Larry Finger]

Smatch lists the following warning:

  CHECK   drivers/staging/rtl8723bs/os_dep/rtw_proc.c
drivers/staging/rtl8723bs/os_dep/rtw_proc.c:102 rtw_drv_proc_open() warn: 
inconsistent indenting

This warning is fixed with a simple change in the white space.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8723bs/os_dep/rtw_proc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/rtw_proc.c 
b/drivers/staging/rtl8723bs/os_dep/rtw_proc.c
index 4088381dff35..a2011e06d719 100644
--- a/drivers/staging/rtl8723bs/os_dep/rtw_proc.c
+++ b/drivers/staging/rtl8723bs/os_dep/rtw_proc.c
@@ -99,7 +99,8 @@ static int rtw_drv_proc_open(struct inode *inode, struct file 
*file)
/* struct net_device *dev = proc_get_parent_data(inode); */
ssize_t index = (ssize_t)PDE_DATA(inode);
const struct rtw_proc_hdl *hdl = drv_proc_hdls+index;
-   return single_open(file, hdl->show, NULL);
+
+   return single_open(file, hdl->show, NULL);
 }
 
 static ssize_t rtw_drv_proc_write(struct file *file, const char __user 
*buffer, size_t count, loff_t *pos)
-- 
2.12.0

[PATCH 03/22] staging: rtl8723bs: Fix dereference before check warning in os_dep/recv_linux.c

[Larry Finger]

Smatch lists the following warning:

  CHECK   drivers/staging/rtl8723bs/os_dep/recv_linux.c
drivers/staging/rtl8723bs/os_dep/recv_linux.c:353 rtw_recv_indicatepkt() warn: 
variable dereferenced before check 'precv_frame' (see line 312)

This warning is fixed by removing the test at line 353.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8723bs/os_dep/recv_linux.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/recv_linux.c 
b/drivers/staging/rtl8723bs/os_dep/recv_linux.c
index c677a5216b54..e731ab4e2bd7 100644
--- a/drivers/staging/rtl8723bs/os_dep/recv_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/recv_linux.c
@@ -350,8 +350,7 @@ int rtw_recv_indicatepkt(struct adapter *padapter, union 
recv_frame *precv_frame
 _recv_indicatepkt_drop:
 
 /* enqueue back to free_recv_queue */
-if (precv_frame)
-rtw_free_recvframe(precv_frame, pfree_recv_queue);
+rtw_free_recvframe(precv_frame, pfree_recv_queue);
 
 DBG_COUNTER(padapter->rx_logs.os_indicate_err);
 return _FAIL;
-- 
2.12.0

[PATCH 04/22] staging: rtl8723bs: Fix indenting warning in os_dep/os_intfs.c

[Larry Finger]

Smatch logs the following warning:

  CHECK   drivers/staging/rtl8723bs/os_dep/os_intfs.c
drivers/staging/rtl8723bs/os_dep/os_intfs.c:1082 ips_netdrv_open() warn: 
inconsistent indenting

A simple change in the white space handles this warning.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8723bs/os_dep/os_intfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/os_intfs.c 
b/drivers/staging/rtl8723bs/os_dep/os_intfs.c
index 2ed3067b4af0..843be2cc6c10 100644
--- a/drivers/staging/rtl8723bs/os_dep/os_intfs.c
+++ b/drivers/staging/rtl8723bs/os_dep/os_intfs.c
@@ -1079,7 +1079,7 @@ static int  ips_netdrv_open(struct adapter *padapter)
 
_set_timer(>mlmepriv.dynamic_chk_timer, 2000);
 
-return _SUCCESS;
+   return _SUCCESS;
 
 netdev_open_error:
/* padapter->bup = false; */
-- 
2.12.0

[PATCH 00/22] staging: rtl87232bs: Fix errors and warnings detected by Smatch

[Larry Finger]

A number of routines have indenting, off by one, and possible usage
while null warnings or errors listed by Smatch. This set of patches
fix all but one of these, and it is in code that will be removed in a
subsequent patch.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>


Larry Finger (22):
  staging: rtl8723bs: Fix indenting warning in os_dep/xmit_linux.c
  staging: rtl8723bs: Fix indenting warning in os_dep/rtw_proc.c
  staging: rtl8723bs: Fix dereference before check warning in
os_dep/recv_linux.c
  staging: rtl8723bs: Fix indenting warning in os_dep/os_intfs.c
  staging: rtl8723bs: Fix indenting mistake in os_dep/mlme_linux.c
  staging: rtl8723bs: Fix various errors in os_dep/ioctl_cfg80211.c
  staging: rtl8723bs: Fix potential usage while NULL error in
hal/rtl8723b_hal_init.c
  staging: rtl8723bs: Fix indenting problems in hal/HalHWImg8723B_BB.c
  staging: rtl8723bs: Fix indening problem in hal/hal_com_phycfg.c
  staging: rtl8723bs: Fix indenting problem for hal/hal_com.c
  staging: rtl8723bs: Fix indenting problems in core/rtw_xmit.c
  staging: rtl8723bs: Fix possible usage of NULL pointer in
core/rtw_debug.c
  staging: rtl8723bs: Fix indenting mistake in core/rtw_ap.c
  staging: rtl8723bs: Fix indenting mistakes in core/rtw_ieee80211.c
  staging: rtl8723bs: Fix indenting mistakes in core/rtw_mlme.c
  staging: rtl8723bs: Fix some indenting problems and a potential data
overrun
  staging: rtl8723bs: Fix indenting problem in core/rtw_sta_mgt.c
  staging: rtl8723bs: Fix some white-space errors in core/rtw_security.c
  staging: rtl8723bs: Fix white-space errors in core/rtw_recv.c
  staging rtl8723bs: Fix indenting errors and an off-by-one mistake in
core/rtw_mlme_ext.c
  staging: rtl8723bs: Fix indenting problems in core/rtw_odm.c
  staging: rtlwifi: Fix indenting error in core/rtw_pwrctrl.c

 drivers/staging/rtl8723bs/core/rtw_ap.c   |  99 +++--
 drivers/staging/rtl8723bs/core/rtw_debug.c|   1 -
 drivers/staging/rtl8723bs/core/rtw_ieee80211.c|  13 +-
 drivers/staging/rtl8723bs/core/rtw_mlme.c |  37 +-
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c |  25 +-
 drivers/staging/rtl8723bs/core/rtw_odm.c  |  10 +-
 drivers/staging/rtl8723bs/core/rtw_pwrctrl.c  |   2 +-
 drivers/staging/rtl8723bs/core/rtw_recv.c |  21 +-
 drivers/staging/rtl8723bs/core/rtw_security.c | 469 +++---
 drivers/staging/rtl8723bs/core/rtw_sta_mgt.c  |   2 +-
 drivers/staging/rtl8723bs/core/rtw_wlan_util.c|  10 +-
 drivers/staging/rtl8723bs/core/rtw_xmit.c |  10 +-
 drivers/staging/rtl8723bs/hal/HalHWImg8723B_BB.c  |   6 +-
 drivers/staging/rtl8723bs/hal/hal_com.c   |  10 +-
 drivers/staging/rtl8723bs/hal/hal_com_phycfg.c|   2 +-
 drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c |  13 +-
 drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c |  38 +-
 drivers/staging/rtl8723bs/os_dep/ioctl_linux.c|   2 +-
 drivers/staging/rtl8723bs/os_dep/mlme_linux.c |   4 +-
 drivers/staging/rtl8723bs/os_dep/os_intfs.c   |   2 +-
 drivers/staging/rtl8723bs/os_dep/recv_linux.c |   3 +-
 drivers/staging/rtl8723bs/os_dep/rtw_proc.c   |   3 +-
 drivers/staging/rtl8723bs/os_dep/xmit_linux.c |   2 +-
 23 files changed, 375 insertions(+), 409 deletions(-)

-- 
2.12.0

Re: [PATCH][V2] rtlwifi: rtl8192de: ix spelling mistake: "althougth" -> "though"

[Larry Finger]

On 02/26/2017 12:52 PM, Colin King wrote:

From: Colin Ian King <colin.k...@canonical.com>

trivial fix to spelling mistake in RT_TRACE message

Signed-off-by: Colin Ian King <colin.k...@canonical.com>
---
 drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


Acked-by: Larry Finger <larry.fin...@lwfinger.net>

Thanks,

Larry



diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c
index de98d88..dcb5d83 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c
@@ -812,7 +812,7 @@ bool rtl92d_phy_config_rf_with_headerfile(struct 
ieee80211_hw *hw,
 * pathA or mac1 has to set phy0 pathA */
if ((content == radiob_txt) && (rfpath == RF90_PATH_A)) {
RT_TRACE(rtlpriv, COMP_INIT, DBG_LOUD,
-" ===> althougth Path A, we load radiob.txt\n");
+" ===> though Path A, we load radiob.txt\n");
radioa_arraylen = radiob_arraylen;
radioa_array_table = radiob_array_table;
}

Re: [PATCH] rtlwifi: rtl8192de: ix spelling mistake: "althougth" -> "although"

[Larry Finger]

On 02/26/2017 09:19 AM, Colin King wrote:

From: Colin Ian King 

trivial fix to spelling mistake in RT_TRACE message

Signed-off-by: Colin Ian King 


Bad fix. It should be althougth => through. Please read the context.

NACK.

Larry


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

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c
index de98d88..dcb5d83 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c
@@ -812,7 +812,7 @@ bool rtl92d_phy_config_rf_with_headerfile(struct 
ieee80211_hw *hw,
 * pathA or mac1 has to set phy0 pathA */
if ((content == radiob_txt) && (rfpath == RF90_PATH_A)) {
RT_TRACE(rtlpriv, COMP_INIT, DBG_LOUD,
-" ===> althougth Path A, we load radiob.txt\n");
+" ===> although Path A, we load radiob.txt\n");
radioa_arraylen = radiob_arraylen;
radioa_array_table = radiob_array_table;
}

Re: [PATCH trivial 2/4] rtlwifi: rtl8821ae: Spelling s/wrtie_addr/write_addr/

[Larry Finger]

On 02/17/2017 10:19 AM, Geert Uytterhoeven wrote:

Hi Larry,

On Fri, Feb 17, 2017 at 5:14 PM, Larry Finger <larry.fin...@lwfinger.net> wrote:

On 02/17/2017 09:36 AM, Geert Uytterhoeven wrote:

As per symmetry with _rtl8821ae_dbi_read(), "wrtie" is not a funky
register acronym, but a simple misspelling of "write".

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
Cc: Larry Finger <larry.fin...@lwfinger.net>
Cc: Chaoming Li <chaoming...@realsil.com.cn>
Cc: netdev@vger.kernel.org


I'm not sure that it is possible to have a typo in a variable name. That
seems to be within an author's prerogative. Nonetheless, the patch is OK


;-)


other than it was sent to the wrong destination. Patches for this driver


MAINTAINERS has your name for drivers/net/wireless/realtek/rtlwifi/.
Perhaps that line should be dropped?


The usual hierarchy is through me to Kalle, then to DaveM, and finally to 
mainline.


should go through linux-wirel...@vger.kernel.org. Kalle Valo is the wireless
maintainer, but it is not necessary to send to him directly as he usually
picks up the patches from Patchwork.


I guess Jiri (trivial) will pick it up...


The only potential problem would be conflicts arising from changes merging from 
two different directions. It applies to Kalle's wireless-drivers-next branch, 
and I will try to keep it in mind as additional patches are supplied to rtl8821ae.


Larry

Re: [PATCH trivial 2/4] rtlwifi: rtl8821ae: Spelling s/wrtie_addr/write_addr/

[Larry Finger]

On 02/17/2017 09:36 AM, Geert Uytterhoeven wrote:

As per symmetry with _rtl8821ae_dbi_read(), "wrtie" is not a funky
register acronym, but a simple misspelling of "write".

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
Cc: Larry Finger <larry.fin...@lwfinger.net>
Cc: Chaoming Li <chaoming...@realsil.com.cn>
Cc: netdev@vger.kernel.org


I'm not sure that it is possible to have a typo in a variable name. That seems 
to be within an author's prerogative. Nonetheless, the patch is OK other than it 
was sent to the wrong destination. Patches for this driver should go through 
linux-wirel...@vger.kernel.org. Kalle Valo is the wireless maintainer, but it is 
not necessary to send to him directly as he usually picks up the patches from 
Patchwork.


Larry


---
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
index 4f83eee1ff75bc81..546f085afb8f42fa 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
@@ -1135,13 +1135,13 @@ static u8 _rtl8821ae_dbi_read(struct rtl_priv *rtlpriv, 
u16 addr)
 static void _rtl8821ae_dbi_write(struct rtl_priv *rtlpriv, u16 addr, u8 data)
 {
u8 tmp = 0, count = 0;
-   u16 wrtie_addr, remainder = addr % 4;
+   u16 write_addr, remainder = addr % 4;

-   wrtie_addr = REG_DBI_WDATA + remainder;
-   rtl_write_byte(rtlpriv, wrtie_addr, data);
+   write_addr = REG_DBI_WDATA + remainder;
+   rtl_write_byte(rtlpriv, write_addr, data);

-   wrtie_addr = (addr & 0xfffc) | (BIT(0) << (remainder + 12));
-   rtl_write_word(rtlpriv, REG_DBI_ADDR, wrtie_addr);
+   write_addr = (addr & 0xfffc) | (BIT(0) << (remainder + 12));
+   rtl_write_word(rtlpriv, REG_DBI_ADDR, write_addr);

rtl_write_byte(rtlpriv, REG_DBI_FLAG, 0x1);

Re: [PATCH 6/7] staging: r8712u: Fix Sparse warnings in rtl871x_ioctl_linux.c

[Larry Finger]

On 02/13/2017 05:27 AM, David Laight wrote:

From: Larry Finger

Sent: 11 February 2017 03:30
Sparse reports the following:
  CHECK   drivers/staging/rtl8712/rtl871x_ioctl_linux.c
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:1422:46: warning: restricted 
__le16 degrades to integer
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:1424:46: warning: restricted 
__le16 degrades to integer

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index 0dc18d6..f4167f1 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -1419,9 +1419,9 @@ static int r8711_wx_get_rate(struct net_device *dev,
ht_cap = true;
pht_capie = (struct ieee80211_ht_cap *)(p + 2);
memcpy(_rate, pht_capie->supp_mcs_set, 2);
-   bw_40MHz = (pht_capie->cap_info &
+   bw_40MHz = (le16_to_cpu(pht_capie->cap_info) &
IEEE80211_HT_CAP_SUP_WIDTH) ? 1 : 0;
-   short_GI = (pht_capie->cap_info &
+   short_GI = (le16_to_cpu(pht_capie->cap_info) &
(IEEE80211_HT_CAP_SGI_20 |
IEEE80211_HT_CAP_SGI_40)) ? 1 : 0;


You've added a byteswap on le systems - so the title is wrong.
You need to sort out whether the byteswap is needed or not.

Also it is best to byteswap the constant.


Yes, I could byteswap the constant rather than the variable, but I prefer to 
have both be in cpu order. That way there will be no confusion when that 
quantity is used later. In this case, both results are boolean and it would not 
make a difference.


I do not understand the comment about the title being wrong. All multi-byte 
quantities in struct ieee80211_ht_cap are little endian. For the code to work on 
BE hardware, a byteswap is necessary. On LE hardware, le16_to_cpu() is defined 
as ((__force __u16)(__le16)(x)), which does not result in a byteswap.


Larry

Re: [PATCH] rtlwifi: btcoexist: fix semicolon.cocci warnings

[Larry Finger]

On 02/09/2017 02:12 PM, Julia Lawall wrote:

Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

CC: Larry Finger <larry.fin...@lwfinger.net>
Signed-off-by: Julia Lawall <julia.law...@lip6.fr>
Signed-off-by: Fengguang Wu <fengguang...@intel.com>


Acked-by: Larry Finger <larry.fin...@lwfinger.net>

Thanks,

Larry


---

 halbtc8821a2ant.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
@@ -2877,7 +2877,7 @@ static void halbtc8821a2ant_action_pan_e
  false, false);
btc8821a2ant_sw_mech2(btcoexist, false, false,
  false, 0x18);
-   };
+   }
} else {
/* fw mechanism */
if ((bt_rssi_state == BTC_RSSI_STATE_HIGH) ||

[PATCH 3/7] staging: r8712u: Fix macros used to read/write the TX/RX descriptors

[Larry Finger]

Although the driver works on big-endian hardware, Sparse generates a lot
of warnings. Many of these are the result of incorrect coding of these
macros.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8712/wifi.h | 109 -
 1 file changed, 52 insertions(+), 57 deletions(-)

diff --git a/drivers/staging/rtl8712/wifi.h b/drivers/staging/rtl8712/wifi.h
index 7ebf247..74dfc9b 100644
--- a/drivers/staging/rtl8712/wifi.h
+++ b/drivers/staging/rtl8712/wifi.h
@@ -151,92 +151,88 @@ enum WIFI_REG_DOMAIN {
 #define _ORDER_BIT(15)
 
 #define SetToDs(pbuf) ({ \
-   *(unsigned short *)(pbuf) |= cpu_to_le16(_TO_DS_); \
+   *(__le16 *)(pbuf) |= cpu_to_le16(_TO_DS_); \
 })
 
-#define GetToDs(pbuf)  (((*(unsigned short *)(pbuf)) & \
-   le16_to_cpu(_TO_DS_)) != 0)
+#define GetToDs(pbuf)  (((*(__le16 *)(pbuf)) & cpu_to_le16(_TO_DS_)) != 0)
 
 #define ClearToDs(pbuf)({ \
-   *(unsigned short *)(pbuf) &= (~cpu_to_le16(_TO_DS_)); \
+   *(__le16 *)(pbuf) &= (~cpu_to_le16(_TO_DS_)); \
 })
 
 #define SetFrDs(pbuf) ({ \
-   *(unsigned short *)(pbuf) |= cpu_to_le16(_FROM_DS_); \
+   *(__le16 *)(pbuf) |= cpu_to_le16(_FROM_DS_); \
 })
 
-#define GetFrDs(pbuf)  (((*(unsigned short *)(pbuf)) & \
-   le16_to_cpu(_FROM_DS_)) != 0)
+#define GetFrDs(pbuf)  (((*(__le16 *)(pbuf)) & cpu_to_le16(_FROM_DS_)) != 0)
 
 #define ClearFrDs(pbuf)({ \
-   *(unsigned short *)(pbuf) &= (~cpu_to_le16(_FROM_DS_)); \
+   *(__le16 *)(pbuf) &= (~cpu_to_le16(_FROM_DS_)); \
 })
 
 #define get_tofr_ds(pframe)((GetToDs(pframe) << 1) | GetFrDs(pframe))
 
 
 #define SetMFrag(pbuf) ({ \
-   *(unsigned short *)(pbuf) |= cpu_to_le16(_MORE_FRAG_); \
+   *(__le16 *)(pbuf) |= cpu_to_le16(_MORE_FRAG_); \
 })
 
-#define GetMFrag(pbuf) (((*(unsigned short *)(pbuf)) & \
-   le16_to_cpu(_MORE_FRAG_)) != 0)
+#define GetMFrag(pbuf) (((*(__le16 *)(pbuf)) & cpu_to_le16(_MORE_FRAG_)) != 0)
 
 #define ClearMFrag(pbuf) ({ \
-   *(unsigned short *)(pbuf) &= (~cpu_to_le16(_MORE_FRAG_)); \
+   *(__le16 *)(pbuf) &= (~cpu_to_le16(_MORE_FRAG_)); \
 })
 
 #define SetRetry(pbuf) ({ \
-   *(unsigned short *)(pbuf) |= cpu_to_le16(_RETRY_); \
+   *(__le16 *)(pbuf) |= cpu_to_le16(_RETRY_); \
 })
 
-#define GetRetry(pbuf) (((*(unsigned short *)(pbuf)) & \
-   le16_to_cpu(_RETRY_)) != 0)
+#define GetRetry(pbuf) (((*(__le16 *)(pbuf)) & cpu_to_le16(_RETRY_)) != 0)
 
 #define ClearRetry(pbuf) ({ \
-   *(unsigned short *)(pbuf) &= (~cpu_to_le16(_RETRY_)); \
+   *(__le16 *)(pbuf) &= (~cpu_to_le16(_RETRY_)); \
 })
 
 #define SetPwrMgt(pbuf) ({ \
-   *(unsigned short *)(pbuf) |= cpu_to_le16(_PWRMGT_); \
+   *(__le16 *)(pbuf) |= cpu_to_le16(_PWRMGT_); \
 })
 
-#define GetPwrMgt(pbuf)(((*(unsigned short *)(pbuf)) & \
-   le16_to_cpu(_PWRMGT_)) != 0)
+#define GetPwrMgt(pbuf)(((*(__le16 *)(pbuf)) & \
+   cpu_to_le16(_PWRMGT_)) != 0)
 
 #define ClearPwrMgt(pbuf) ({ \
-   *(unsigned short *)(pbuf) &= (~cpu_to_le16(_PWRMGT_)); \
+   *(__le16 *)(pbuf) &= (~cpu_to_le16(_PWRMGT_)); \
 })
 
 #define SetMData(pbuf) ({ \
-   *(unsigned short *)(pbuf) |= cpu_to_le16(_MORE_DATA_); \
+   *(__le16 *)(pbuf) |= cpu_to_le16(_MORE_DATA_); \
 })
 
-#define GetMData(pbuf) (((*(unsigned short *)(pbuf)) & \
-   le16_to_cpu(_MORE_DATA_)) != 0)
+#define GetMData(pbuf) (((*(__le16 *)(pbuf)) & \
+   cpu_to_le16(_MORE_DATA_)) != 0)
 
 #define ClearMData(pbuf) ({ \
-   *(unsigned short *)(pbuf) &= (~cpu_to_le16(_MORE_DATA_)); \
+   *(__le16 *)(pbuf) &= (~cpu_to_le16(_MORE_DATA_)); \
 })
 
 #define SetPrivacy(pbuf) ({ \
-   *(unsigned short *)(pbuf) |= cpu_to_le16(_PRIVACY_); \
+   *(__le16 *)(pbuf) |= cpu_to_le16(_PRIVACY_); \
 })
 
-#define GetPrivacy(pbuf)   (((*(unsigned short *)(pbuf)) & \
-   le16_to_cpu(_PRIVACY_)) != 0)
+#define GetPrivacy(pbuf)   (((*(__le16 *)(pbuf)) & \
+   cpu_to_le16(_PRIVACY_)) != 0)
 
-#define GetOrder(pbuf) (((*(unsigned short *)(pbuf)) & \
-   le16_to_cpu(_ORDER_)) != 0)
+#define GetOrder(pbuf) (((*(__le16 *)(pbuf)) & \
+   cpu_to_le16(_ORDER_)) != 0)
 
 #define GetFrameType(pbuf) (le16_to_cpu(*(__le16 *)(pbuf)) & \
(BIT(3) | BIT(2)))
 
 #define SetFrameType(pbuf, type)   \
do {\
-   *(unsigned short *)(pbuf) &= cpu_to_le16(~(BIT(3) | \
+   *(__le16 *)(pbuf) &= cpu_to_le16(~(BIT(3) | \
BIT(2))); \
-   *(unsigned short *)(pbuf) |= cpu_to_le16(type); \
+   *(__le16 *)(pb

[PATCH 7/7] staging: r8712u: Fix Sparse warnings in rtl871x_mlme.c

[Larry Finger]

Sparse reports the following:
  CHECK   drivers/staging/rtl8712/rtl871x_mlme.c
drivers/staging/rtl8712/rtl871x_mlme.c:1653:46: warning: incorrect type in 
assignment (different base types)
drivers/staging/rtl8712/rtl871x_mlme.c:1653:46:expected unsigned int 
[unsigned] [usertype] DSConfig
drivers/staging/rtl8712/rtl871x_mlme.c:1653:46:got restricted __le32 
[usertype] 
drivers/staging/rtl8712/rtl871x_mlme.c:1656:56: warning: incorrect type in 
assignment (different base types)
drivers/staging/rtl8712/rtl871x_mlme.c:1656:56:expected unsigned int 
[unsigned] [usertype] ATIMWindow
drivers/staging/rtl8712/rtl871x_mlme.c:1656:56:got restricted __le32 
[usertype] 
drivers/staging/rtl8712/rtl871x_mlme.c:1712:35: warning: incorrect type in 
assignment (different base types)
drivers/staging/rtl8712/rtl871x_mlme.c:1712:35:expected restricted __le16 
[addressable] [usertype] cap_info
drivers/staging/rtl8712/rtl871x_mlme.c:1712:35:got int

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8712/rtl871x_mlme.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl871x_mlme.c 
b/drivers/staging/rtl8712/rtl871x_mlme.c
index fd8d96d..bf1ac22 100644
--- a/drivers/staging/rtl8712/rtl871x_mlme.c
+++ b/drivers/staging/rtl8712/rtl871x_mlme.c
@@ -1650,10 +1650,9 @@ void r8712_update_registrypriv_dev_network(struct 
_adapter *adapter)
/* TODO */
break;
}
-   pdev_network->Configuration.DSConfig = cpu_to_le32(
-  pregistrypriv->channel);
+   pdev_network->Configuration.DSConfig = pregistrypriv->channel;
if (cur_network->network.InfrastructureMode == Ndis802_11IBSS)
-   pdev_network->Configuration.ATIMWindow = cpu_to_le32(3);
+   pdev_network->Configuration.ATIMWindow = 3;
pdev_network->InfrastructureMode = 
cur_network->network.InfrastructureMode;
/* 1. Supported rates
 * 2. IE
@@ -1709,12 +1708,12 @@ unsigned int r8712_restructure_ht_ie(struct _adapter 
*padapter, u8 *in_ie,
}
out_len = *pout_len;
memset(_capie, 0, sizeof(struct ieee80211_ht_cap));
-   ht_capie.cap_info = IEEE80211_HT_CAP_SUP_WIDTH |
+   ht_capie.cap_info = cpu_to_le16(IEEE80211_HT_CAP_SUP_WIDTH |
IEEE80211_HT_CAP_SGI_20 |
IEEE80211_HT_CAP_SGI_40 |
IEEE80211_HT_CAP_TX_STBC |
IEEE80211_HT_CAP_MAX_AMSDU |
-   IEEE80211_HT_CAP_DSSSCCK40;
+   IEEE80211_HT_CAP_DSSSCCK40);
ht_capie.ampdu_params_info = (IEEE80211_HT_CAP_AMPDU_FACTOR &
0x03) | (IEEE80211_HT_CAP_AMPDU_DENSITY & 0x00);
r8712_set_ie(out_ie + out_len, _HT_CAPABILITY_IE_,
-- 
2.10.2

[PATCH 1/7] staging: rtl8712: Fix some Sparse endian messages

[Larry Finger]

Sparse reports the following:

  CHECK   drivers/staging/rtl8712/rtl8712_xmit.c
drivers/staging/rtl8712/rtl8712_xmit.c:564:42: warning: cast from restricted 
__le32
drivers/staging/rtl8712/rtl8712_xmit.c:569:42: warning: cast from restricted 
__le32
drivers/staging/rtl8712/rtl8712_xmit.c:571:42: warning: cast from restricted 
__le32

Each of these cases is transferring a quantity that is little-endian. There
is no need for conversion.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8712/rtl8712_xmit.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl8712_xmit.c 
b/drivers/staging/rtl8712/rtl8712_xmit.c
index 4231a0a..7fe6265 100644
--- a/drivers/staging/rtl8712/rtl8712_xmit.c
+++ b/drivers/staging/rtl8712/rtl8712_xmit.c
@@ -561,14 +561,14 @@ static void update_txdesc(struct xmit_frame *pxmitframe, 
uint *pmem, int sz)
 
ptxdesc_mp = _mp;
/* offset 8 */
-   ptxdesc->txdw2 = cpu_to_le32(ptxdesc_mp->txdw2);
+   ptxdesc->txdw2 = ptxdesc_mp->txdw2;
if (bmcst)
ptxdesc->txdw2 |= cpu_to_le32(BMC);
ptxdesc->txdw2 |= cpu_to_le32(BK);
/* offset 16 */
-   ptxdesc->txdw4 = cpu_to_le32(ptxdesc_mp->txdw4);
+   ptxdesc->txdw4 = ptxdesc_mp->txdw4;
/* offset 20 */
-   ptxdesc->txdw5 = cpu_to_le32(ptxdesc_mp->txdw5);
+   ptxdesc->txdw5 = ptxdesc_mp->txdw5;
pattrib->pctrl = 0;/* reset to zero; */
}
} else if (pxmitframe->frame_tag == MGNT_FRAMETAG) {
-- 
2.10.2

[PATCH 2/7] staging: rtl8712u: Fix endian settings for structs describing network packets

[Larry Finger]

The headers describing a number of network packets do not have the
correct endian settings for several types of data.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8712/ieee80211.h | 84 ++---
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/drivers/staging/rtl8712/ieee80211.h 
b/drivers/staging/rtl8712/ieee80211.h
index 67ab580..68fd65e 100644
--- a/drivers/staging/rtl8712/ieee80211.h
+++ b/drivers/staging/rtl8712/ieee80211.h
@@ -138,51 +138,51 @@ struct ieee_ibss_seq {
 };
 
 struct ieee80211_hdr {
-   u16 frame_ctl;
-   u16 duration_id;
+   __le16 frame_ctl;
+   __le16 duration_id;
u8 addr1[ETH_ALEN];
u8 addr2[ETH_ALEN];
u8 addr3[ETH_ALEN];
-   u16 seq_ctl;
+   __le16 seq_ctl;
u8 addr4[ETH_ALEN];
-} __packed;
+}  __packed __aligned(2);
 
 struct ieee80211_hdr_3addr {
-   u16 frame_ctl;
-   u16 duration_id;
+   __le16 frame_ctl;
+   __le16 duration_id;
u8 addr1[ETH_ALEN];
u8 addr2[ETH_ALEN];
u8 addr3[ETH_ALEN];
-   u16 seq_ctl;
-} __packed;
+   __le16 seq_ctl;
+}  __packed __aligned(2);
 
 struct ieee80211_hdr_qos {
-   u16 frame_ctl;
-   u16 duration_id;
+   __le16 frame_ctl;
+   __le16 duration_id;
u8 addr1[ETH_ALEN];
u8 addr2[ETH_ALEN];
u8 addr3[ETH_ALEN];
-   u16 seq_ctl;
+   __le16 seq_ctl;
u8 addr4[ETH_ALEN];
-   u16 qc;
-}  __packed;
+   __le16  qc;
+}   __packed __aligned(2);
 
 struct  ieee80211_hdr_3addr_qos {
-   u16 frame_ctl;
-   u16 duration_id;
+   __le16 frame_ctl;
+   __le16 duration_id;
u8  addr1[ETH_ALEN];
u8  addr2[ETH_ALEN];
u8  addr3[ETH_ALEN];
-   u16 seq_ctl;
-   u16 qc;
+   __le16 seq_ctl;
+   __le16 qc;
 }  __packed;
 
 struct eapol {
u8 snap[6];
-   u16 ethertype;
+   __be16 ethertype;
u8 version;
u8 type;
-   u16 length;
+   __le16 length;
 } __packed;
 
 enum eap_type {
@@ -514,13 +514,13 @@ struct ieee80211_security {
  */
 
 struct ieee80211_header_data {
-   u16 frame_ctl;
-   u16 duration_id;
+   __le16 frame_ctl;
+   __le16 duration_id;
u8 addr1[6];
u8 addr2[6];
u8 addr3[6];
-   u16 seq_ctrl;
-};
+   __le16 seq_ctrl;
+} __packed __aligned(2);
 
 #define BEACON_PROBE_SSID_ID_POSITION 12
 
@@ -552,18 +552,18 @@ struct ieee80211_info_element {
 /*
  * These are the data types that can make up management packets
  *
-   u16 auth_algorithm;
-   u16 auth_sequence;
-   u16 beacon_interval;
-   u16 capability;
+   __le16 auth_algorithm;
+   __le16 auth_sequence;
+   __le16 beacon_interval;
+   __le16 capability;
u8 current_ap[ETH_ALEN];
-   u16 listen_interval;
+   __le16 listen_interval;
struct {
u16 association_id:14, reserved:2;
} __packed;
-   u32 time_stamp[2];
-   u16 reason;
-   u16 status;
+   __le32 time_stamp[2];
+   __le16 reason;
+   __le16 status;
 */
 
 #define IEEE80211_DEFAULT_TX_ESSID "Penguin"
@@ -571,16 +571,16 @@ struct ieee80211_info_element {
 
 struct ieee80211_authentication {
struct ieee80211_header_data header;
-   u16 algorithm;
-   u16 transaction;
-   u16 status;
+   __le16 algorithm;
+   __le16 transaction;
+   __le16 status;
 } __packed;
 
 struct ieee80211_probe_response {
struct ieee80211_header_data header;
-   u32 time_stamp[2];
-   u16 beacon_interval;
-   u16 capability;
+   __le32 time_stamp[2];
+   __le16 beacon_interval;
+   __le16 capability;
struct ieee80211_info_element info_element;
 } __packed;
 
@@ -590,16 +590,16 @@ struct ieee80211_probe_request {
 
 struct ieee80211_assoc_request_frame {
struct ieee80211_hdr_3addr header;
-   u16 capability;
-   u16 listen_interval;
+   __le16 capability;
+   __le16 listen_interval;
struct ieee80211_info_element_hdr info_element;
 } __packed;
 
 struct ieee80211_assoc_response_frame {
struct ieee80211_hdr_3addr header;
-   u16 capability;
-   u16 status;
-   u16 aid;
+   __le16 capability;
+   __le16 status;
+   __le16 aid;
 } __packed;
 
 struct ieee80211_txb {
-- 
2.10.2

[PATCH 4/7] staging: r8712u: Fix Sparse warning in rtl871x_xmit.c

[Larry Finger]

Sparse reports the following:
  CHECK   drivers/staging/rtl8712/rtl871x_xmit.c
drivers/staging/rtl8712/rtl871x_xmit.c:350:44: warning: restricted __le32 
degrades to integer
drivers/staging/rtl8712/rtl871x_xmit.c:491:23: warning: incorrect type in 
initializer (different base types)
drivers/staging/rtl8712/rtl871x_xmit.c:491:23:expected unsigned short 
[usertype] *fctrl
drivers/staging/rtl8712/rtl871x_xmit.c:491:23:got restricted __le16 
*
drivers/staging/rtl8712/rtl871x_xmit.c:580:36: warning: incorrect type in 
assignment (different base types)
drivers/staging/rtl8712/rtl871x_xmit.c:580:36:expected unsigned short 
[unsigned] [short] [usertype] 
drivers/staging/rtl8712/rtl871x_xmit.c:580:36:got restricted __be16 
[usertype] 

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 drivers/staging/rtl8712/rtl871x_xmit.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl871x_xmit.c 
b/drivers/staging/rtl8712/rtl871x_xmit.c
index 4ab82ba..de88819 100644
--- a/drivers/staging/rtl8712/rtl871x_xmit.c
+++ b/drivers/staging/rtl8712/rtl871x_xmit.c
@@ -347,7 +347,8 @@ sint r8712_update_attrib(struct _adapter *padapter, _pkt 
*pkt,
 * some settings above.
 */
if (check_fwstate(pmlmepriv, WIFI_MP_STATE))
-   pattrib->priority = (txdesc.txdw1 >> QSEL_SHT) & 0x1f;
+   pattrib->priority =
+   (le32_to_cpu(txdesc.txdw1) >> QSEL_SHT) & 0x1f;
return _SUCCESS;
 }
 
@@ -488,7 +489,7 @@ static sint make_wlanhdr(struct _adapter *padapter, u8 *hdr,
struct ieee80211_hdr *pwlanhdr = (struct ieee80211_hdr *)hdr;
struct mlme_priv *pmlmepriv = >mlmepriv;
struct qos_priv *pqospriv = >qospriv;
-   u16 *fctrl = >frame_ctl;
+   __le16 *fctrl = >frame_ctl;
 
memset(hdr, 0, WLANHDR_OFFSET);
SetFrameSubType(fctrl, pattrib->subtype);
@@ -577,7 +578,7 @@ static sint r8712_put_snap(u8 *data, u16 h_proto)
snap->oui[0] = oui[0];
snap->oui[1] = oui[1];
snap->oui[2] = oui[2];
-   *(u16 *)(data + SNAP_SIZE) = htons(h_proto);
+   *(__be16 *)(data + SNAP_SIZE) = htons(h_proto);
return SNAP_SIZE + sizeof(u16);
 }
 
-- 
2.10.2