Re: [PATCH] staging: rtl8188eu: Add Edimax EW-7811UN V2 to device table

[Larry Finger]

On 2/4/21 2:52 AM, Martin Kaiser wrote:

The Edimax EW-7811UN V2 uses an RTL8188EU chipset and works with this
driver.

Signed-off-by: Martin Kaiser 
---
  drivers/staging/rtl8188eu/os_dep/usb_intf.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c 
b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
index 43ebd11b53fe..efad43d8e465 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
@@ -41,6 +41,7 @@ static const struct usb_device_id rtw_usb_id_tbl[] = {
{USB_DEVICE(0x2357, 0x0111)}, /* TP-Link TL-WN727N v5.21 */
{USB_DEVICE(0x2C4E, 0x0102)}, /* MERCUSYS MW150US v2 */
{USB_DEVICE(0x0df6, 0x0076)}, /* Sitecom N150 v2 */
+   {USB_DEVICE(0x7392, 0xb811)}, /* Edimax EW-7811UN V2 */
{USB_DEVICE(USB_VENDER_ID_REALTEK, 0xffef)}, /* Rosewill RNX-N150NUB */
{}  /* Terminating entry */
  };



Acked-by: Larry Finger 

Larry

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: rtl8723bs: include: Fix coding style errors

[Larry Finger]

On 7/26/20 3:40 AM, Aditya Jain wrote:

On Sun, Jul 26, 2020 at 1:56 PM Greg KH  wrote:


On Sun, Jul 26, 2020 at 01:32:15PM +0530, Aditya Jain wrote:

Fixing ERROR: "foo *  bar" should be "foo *bar" in hal_phy_cfg.h
as reported by checkpatch.pl

Signed-off-by: Aditya Jain 
---
  .../staging/rtl8723bs/include/hal_phy_cfg.h| 18 +-
  1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/rtl8723bs/include/hal_phy_cfg.h 
b/drivers/staging/rtl8723bs/include/hal_phy_cfg.h
index 419ddb0733aa..fd5f377bad4f 100644
--- a/drivers/staging/rtl8723bs/include/hal_phy_cfg.h
+++ b/drivers/staging/rtl8723bs/include/hal_phy_cfg.h
@@ -42,7 +42,7 @@ u32 Data

  u32
  PHY_QueryRFReg_8723B(
-struct adapter * Adapter,
+struct adapter   *Adapter,
  u8   eRFPath,
  u32  RegAddr,
  u32  BitMask


Ick, these are all horrid.  How about just making these all on a single
line like most functions have them instead of this one cleanup?

Same for the other changes you made in this file.

thanks,

greg k-h


Agreed. I'll clean it up.


While you are at it, drop the "include;" from the subject. For staging, the 
usual subject is of the form "staging: driver: thing being done". In your case 
"staging: rtl8723bs: Fix coding style errors". The directory of the files are 
not relevant.


I am also not in favor of the large white space between the variable type and 
the name, but that is probably the subject of separate patches.


Larry

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] STAGING - REALTEK RTL8188EU DRIVERS: Fix Coding Style Error

[Larry Finger]

On 7/25/20 1:39 PM, Joe Perches wrote:

On Sat, 2020-07-25 at 12:47 -0500, Larry Finger wrote:

On 7/25/20 7:20 AM, Anant Thazhemadam wrote:

Running the checkpatch.pl script on the file for which patch was created, the
following error was found to exist.
ERROR: space required after that ',' (ctx:VxV)

Fixed the above error which was found on line #721 by inserting a blank
space at the appropriate position.

[]

diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c 
b/drivers/staging/rtl8188eu/core/rtw_security.c

[]

@@ -718,7 +718,7 @@ u32 rtw_tkip_decrypt(struct adapter *padapter, u8 
*precvframe)
res = _FAIL;
}
} else {
-   RT_TRACE(_module_rtl871x_security_c_, _drv_err_, ("%s: 
stainfo==NULL!!!\n",__func__));
+   RT_TRACE(_module_rtl871x_security_c_, _drv_err_, ("%s: 
stainfo==NULL!!!\n", __func__));
res = _FAIL;
}
}


In fixing one checkpatch.pl condition, you introduced another - the resulting
line is too long. You should fix only one such condition, but you should fix any
others that are introduced. You do need to document it.


I think that doesn't matter as it was also too long
before this change.


Patch subjects for this driver should be written as "staging: rtl8188eu: .".


How likely is it that this driver would ever be
moved to drivers/net/wireless/realtek/rtlwifi?


Very unlikely. It I wanted to undertake that kind of effort, I would switch to 
one of the later versions from Realtek that uses nl80211/cfg80211. Despite that, 
it is likely that only the USB driver from rtlwifi could be used.


Larry



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] STAGING - REALTEK RTL8188EU DRIVERS: Fix Coding Style Error

[Larry Finger]

On 7/25/20 7:20 AM, Anant Thazhemadam wrote:

Running the checkpatch.pl script on the file for which patch was created, the
following error was found to exist.
ERROR: space required after that ',' (ctx:VxV)

Fixed the above error which was found on line #721 by inserting a blank
space at the appropriate position.

Signed-off-by: Anant Thazhemadam 
---
  drivers/staging/rtl8188eu/core/rtw_security.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c 
b/drivers/staging/rtl8188eu/core/rtw_security.c
index 21f6652dd69f..57e171d3e48d 100644
--- a/drivers/staging/rtl8188eu/core/rtw_security.c
+++ b/drivers/staging/rtl8188eu/core/rtw_security.c
@@ -718,7 +718,7 @@ u32 rtw_tkip_decrypt(struct adapter *padapter, u8 
*precvframe)
res = _FAIL;
}
} else {
-   RT_TRACE(_module_rtl871x_security_c_, _drv_err_, ("%s: 
stainfo==NULL!!!\n",__func__));
+   RT_TRACE(_module_rtl871x_security_c_, _drv_err_, ("%s: 
stainfo==NULL!!!\n", __func__));
res = _FAIL;
}
}


In fixing one checkpatch.pl condition, you introduced another - the resulting 
line is too long. You should fix only one such condition, but you should fix any 
others that are introduced. You do need to document it.


Patch subjects for this driver should be written as "staging: rtl8188eu: .".

Larry


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: rtl8188eu: rtw_mlme: Fix uninitialized variable authmode

[Larry Finger]

On 7/24/20 8:28 AM, Dinghao Liu wrote:

The variable authmode will keep uninitialized if neither if
statements used to initialize this variable are not triggered.


Besides Greg's comment, you need to re-parse this sentence. I realize that 
English is probably not your first language, but this one is not what you meant.


You likely meant "The variable authmode will remain uninitialized if all 
statements used to initialize this variable are not triggered."


A possible (line-wrapped) patch to quiet the tools would be:

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c

index 9de2d421f6b1..9e4d78bc9a2e 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -1729,9 +1729,11 @@ int rtw_restruct_sec_ie(struct adapter *adapter, u8 
*in_ie, u8 *out_ie, uint in_

if ((ndisauthmode == Ndis802_11AuthModeWPA) ||
(ndisauthmode == Ndis802_11AuthModeWPAPSK))
authmode = _WPA_IE_ID_;
-   if ((ndisauthmode == Ndis802_11AuthModeWPA2) ||
-   (ndisauthmode == Ndis802_11AuthModeWPA2PSK))
+   else if ((ndisauthmode == Ndis802_11AuthModeWPA2) ||
+(ndisauthmode == Ndis802_11AuthModeWPA2PSK))
authmode = _WPA2_IE_ID_;
+   else
+   authmode = 0;

if (check_fwstate(pmlmepriv, WIFI_UNDER_WPS)) {
memcpy(out_ie + ielength, psecuritypriv->wps_ie, 
psecuritypriv->wps_ie_len);



Yes, in this routine, it would be possible for authmode to not be set; however, 
later code only compares it to either _WPA_IE_ID_ or _WPA2_IE_ID_. It is never 
used in a way that an unset value could make the program flow be different by 
arbitrarily setting the value to zero. Thus your statement "Then authmode may 
contain a garbage value and influence the execution flow of this function." is 
false.


Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: r8188eu: remove unused members of struct xmit_buf

[Larry Finger]

On 7/13/20 1:28 PM, Ivan Safonov wrote:

On 7/13/20 5:23 PM, Dan Carpenter wrote:

On Mon, Jul 13, 2020 at 04:16:07PM +0300, Dan Carpenter wrote:

On Sun, Jul 12, 2020 at 03:38:21PM +0300, Ivan Safonov wrote:

Remove unused members of struct xmit_buf: alloc_sz, ff_hwaddr,
dma_transfer_addr, bpending and last.

Signed-off-by: Ivan Safonov 
---
  drivers/staging/rtl8188eu/include/rtw_xmit.h  | 5 -
  drivers/staging/rtl8188eu/os_dep/xmit_linux.c | 1 -
  2 files changed, 6 deletions(-)

diff --git a/drivers/staging/rtl8188eu/include/rtw_xmit.h 
b/drivers/staging/rtl8188eu/include/rtw_xmit.h

index 12d16e98176a..3c03987c81a1 100644
--- a/drivers/staging/rtl8188eu/include/rtw_xmit.h
+++ b/drivers/staging/rtl8188eu/include/rtw_xmit.h
@@ -193,14 +193,9 @@ struct xmit_buf {
  void *priv_data;
  u16 ext_tag; /*  0: Normal xmitbuf, 1: extension xmitbuf. */
  u16 flags;
-    u32 alloc_sz;
  u32  len;
  struct submit_ctx *sctx;
-    u32    ff_hwaddr;
  struct urb *pxmit_urb[8];
-    dma_addr_t dma_transfer_addr;    /* (in) dma addr for transfer_buffer */
-    u8 bpending[8];
-    int last[8];
  };
  struct xmit_frame {
diff --git a/drivers/staging/rtl8188eu/os_dep/xmit_linux.c 
b/drivers/staging/rtl8188eu/os_dep/xmit_linux.c

index 017e1d628461..61ced1160951 100644
--- a/drivers/staging/rtl8188eu/os_dep/xmit_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/xmit_linux.c
@@ -24,7 +24,6 @@ int rtw_os_xmit_resource_alloc(struct adapter *padapter,
  return _FAIL;
  pxmitbuf->pbuf = PTR_ALIGN(pxmitbuf->pallocated_buf, XMITBUF_ALIGN_SZ);


Not related to this patch but kmalloc always returns data which is at
least ARCH_KMALLOC_MINALIGN aligned which is never less than
XMITBUF_ALIGN_SZ (4) so this is a no-op.


4-byte alignment for 8-byte pointer (for example void *priv_data) on 64-bit arch 
is an _error_. It’s good that kmalloc (and vmalloc) is already aligned to 8 bytes.




The alignment in the driver is pretty crazy because it's all unnecessary
and so complicated.  Every allocation is 4 bytes extra so we can align
it later.

Also every buffer is called "pbuf" which stands for pointer to buffer.
"pallocated_buf" is not really useful either.

I tried to look at this to see if we could change the alignment, and
it's complicated because of the naming and the alignment.

regards,
dan carpenter



I have already fixed 4 places with unnecessary alignment, but, alas, there is no 
great desire to test them on real hardware.


I have now tested on real hardware and it works fine.

Acked-by: Larry Finger 

Larry

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: r8188eu: remove unused members of struct xmit_buf

[Larry Finger]

On 7/12/20 7:38 AM, Ivan Safonov wrote:

Remove unused members of struct xmit_buf: alloc_sz, ff_hwaddr,
dma_transfer_addr, bpending and last.

Signed-off-by: Ivan Safonov 
---


Have you tested this change? Previously with this driver, an unused quantity was 
removed from one of the structs and the driver failed. Apparently, the alignment 
of some other quantity was affected. I do not think that this change would have 
that affect; however, you should be testing whenever the changes are more than 
cosmetic.


Larry

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: rtl8712: switch to common ieee80211 headers

[Larry Finger]

On 6/1/20 3:24 PM, Pascal Terjan wrote:

This patch switches to  and  and
deletes a lot of duplicate definitions plus many unused ones.

Non obvious changes:
- struct ieee80211_ht_cap is different enough that I preferred to keep
   (and rename) it for now.
- mcs_rate in translate_scan was not read after being set, so I deleted
   that part rather than using the renamed struct
- WLAN_CAPABILITY_BSS is replaced with WLAN_CAPABILITY_ESS which is the
   corresponding one with same value

Signed-off-by: Pascal Terjan 


This patch does not apply to the staging repo, current mainline, or 
wireless-drivers-next. Where did you intend it to go? Staging is the correct tree.


Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: rtl8188eu: Add ASUS USB-N10 Nano B1 to device table

[Larry Finger]

The ASUS USB-N10 Nano B1 has been reported as a new RTL8188EU device.
Add it to the device tables.

Signed-off-by: Larry Finger 
Reported-by: kovi 
Cc: Stable 
---
 drivers/staging/rtl8188eu/os_dep/usb_intf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c 
b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
index b5d42f411dd8..b7f65026dba8 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
@@ -32,6 +32,7 @@ static const struct usb_device_id rtw_usb_id_tbl[] = {
/** 8188EUS /
{USB_DEVICE(0x056e, 0x4008)}, /* Elecom WDC-150SU2M */
{USB_DEVICE(0x07b8, 0x8179)}, /* Abocom - Abocom */
+   {USB_DEVICE(0x0B05, 0x18F0)}, /* ASUS USB-N10 Nano B1 */
{USB_DEVICE(0x2001, 0x330F)}, /* DLink DWA-125 REV D1 */
{USB_DEVICE(0x2001, 0x3310)}, /* Dlink DWA-123 REV D1 */
{USB_DEVICE(0x2001, 0x3311)}, /* DLink GO-USB-N150 REV B1 */
-- 
2.25.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/6] staging: rtl8188eu: Fix potential security hole

[Larry Finger]

In routine rtw_hostapd_ioctl(), the user-controlled p->length is assumed
to be at least the size of struct ieee_param size, but this assumption is
never checked. This could result in out-of-bounds read/write on kernel
heap in case a p->length less than the size of struct ieee_param is
specified by the user. If p->length is allowed to be greater than the size
of the struct, then a malicious user could be wasting kernel memory.
Fixes commit a2c60d42d97c ("Add files for new driver - part 16").

Reported by: Pietro Oliva 
Cc: Pietro Oliva 
Cc: Stable 
Fixes: a2c60d42d97c ("Add files for new driver - part 16").
Signed-off-by: Larry Finger 
---
 drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c 
b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
index 9b6ea86d1dcf..7d21f5799640 100644
--- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
@@ -2796,7 +2796,7 @@ static int rtw_hostapd_ioctl(struct net_device *dev, 
struct iw_point *p)
goto out;
}
 
-   if (!p->pointer) {
+   if (!p->pointer || p->length != sizeof(struct ieee_param)) {
ret = -EINVAL;
goto out;
}
-- 
2.25.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/6] staging: rtl8188eu: Fix potential overuse of kernel memory

[Larry Finger]

In routine wpa_supplicant_ioctl(), the user-controlled p->length is
checked to be at least the size of struct ieee_param size, but the code
does not detect the case where p->length is greater than the size
of the struct, thus a malicious user could be wasting kernel memory.
Fixes commit a2c60d42d97c ("Add files for new driver - part 16").

Reported by: Pietro Oliva 
Cc: Pietro Oliva 
Cc: Stable 
Fixes commit a2c60d42d97c ("Add files for new driver - part 16").
Signed-off-by: Larry Finger 
---
 drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c 
b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
index 7d21f5799640..acca3ae8b254 100644
--- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
@@ -2009,7 +2009,7 @@ static int wpa_supplicant_ioctl(struct net_device *dev, 
struct iw_point *p)
struct ieee_param *param;
uint ret = 0;
 
-   if (p->length < sizeof(struct ieee_param) || !p->pointer) {
+   if (!p->pointer || p->length != sizeof(struct ieee_param)) {
ret = -EINVAL;
goto out;
}
-- 
2.25.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/6] staging: rtl8723bs: Fix potential security hole

[Larry Finger]

In routine rtw_hostapd_ioctl(), the user-controlled p->length is assumed
to be at least the size of struct ieee_param size, but this assumption is
never checked. This could result in out-of-bounds read/write on kernel
heap in case a p->length less than the size of struct ieee_param is
specified by the user. If p->length is allowed to be greater than the size
of the struct, then a malicious user could be wasting kernel memory.
Fixes commit 554c0a3abf216 ("0taging: Add rtl8723bs sdio wifi driver").

Reported by: Pietro Oliva 
Cc: Pietro Oliva 
Cc: Stable 
Fixes 554c0a3abf216 ("0taging: Add rtl8723bs sdio wifi driver").
Signed-off-by: Larry Finger 
---
 drivers/staging/rtl8723bs/os_dep/ioctl_linux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
index db6528a01229..3128766dd50e 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
@@ -4207,7 +4207,7 @@ static int rtw_hostapd_ioctl(struct net_device *dev, 
struct iw_point *p)
 
 
/* if (p->length < sizeof(struct ieee_param) || !p->pointer) { */
-   if (!p->pointer) {
+   if (!p->pointer || p->length != sizeof(*param)) {
ret = -EINVAL;
goto out;
}
-- 
2.25.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 5/6] staging: rtl8188eu: Remove some unneeded goto statements

[Larry Finger]

In routines rtw_hostapd_ioctl() and wpa_supplicant_ioctl(), several
error conditions involve setting a variable indicating the error,
followed by a goto. The code following the target of that goto merely
returns the value. It is simpler, therefore to return the error value
immediately, and eliminate the got  target.

Signed-off-by: Larry Finger 
Cc: Pietro Oliva 
---
 .../staging/rtl8188eu/os_dep/ioctl_linux.c| 40 ++-
 1 file changed, 12 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c 
b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
index acca3ae8b254..ba53959e1303 100644
--- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
@@ -2009,21 +2009,16 @@ static int wpa_supplicant_ioctl(struct net_device *dev, 
struct iw_point *p)
struct ieee_param *param;
uint ret = 0;
 
-   if (!p->pointer || p->length != sizeof(struct ieee_param)) {
-   ret = -EINVAL;
-   goto out;
-   }
+   if (!p->pointer || p->length != sizeof(struct ieee_param))
+   return -EINVAL;
 
param = (struct ieee_param *)rtw_malloc(p->length);
-   if (!param) {
-   ret = -ENOMEM;
-   goto out;
-   }
+   if (!param)
+   return -ENOMEM;
 
if (copy_from_user(param, p->pointer, p->length)) {
kfree(param);
-   ret = -EFAULT;
-   goto out;
+   return -EFAULT;
}
 
switch (param->cmd) {
@@ -2054,9 +2049,6 @@ static int wpa_supplicant_ioctl(struct net_device *dev, 
struct iw_point *p)
ret = -EFAULT;
 
kfree(param);
-
-out:
-
return ret;
 }
 
@@ -2791,26 +2783,19 @@ static int rtw_hostapd_ioctl(struct net_device *dev, 
struct iw_point *p)
* so, we just check hw_init_completed
*/
 
-   if (!padapter->hw_init_completed) {
-   ret = -EPERM;
-   goto out;
-   }
+   if (!padapter->hw_init_completed)
+   return -EPERM;
 
-   if (!p->pointer || p->length != sizeof(struct ieee_param)) {
-   ret = -EINVAL;
-   goto out;
-   }
+   if (!p->pointer || p->length != sizeof(struct ieee_param))
+   return -EINVAL;
 
param = (struct ieee_param *)rtw_malloc(p->length);
-   if (!param) {
-   ret = -ENOMEM;
-   goto out;
-   }
+   if (!param)
+   return -ENOMEM;
 
if (copy_from_user(param, p->pointer, p->length)) {
kfree(param);
-   ret = -EFAULT;
-   goto out;
+   return -EFAULT;
}
 
switch (param->cmd) {
@@ -2865,7 +2850,6 @@ static int rtw_hostapd_ioctl(struct net_device *dev, 
struct iw_point *p)
if (ret == 0 && copy_to_user(p->pointer, param, p->length))
ret = -EFAULT;
kfree(param);
-out:
return ret;
 }
 #endif
-- 
2.25.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 4/6] staging: rtl8723bs: Fix potential overuse of kernel memory

[Larry Finger]

In routine wpa_supplicant_ioctl(), the user-controlled p->length is
checked to be at least the size of struct ieee_param size, but the code
does not detect the case where p->length is greater than the size
of the struct, thus a malicious user could be wasting kernel memory.
Fixes commit 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver").

Reported by: Pietro Oliva 
Cc: Pietro Oliva 
Cc: Stable 
Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver").
Signed-off-by: Larry Finger 
-# Please enter the commit message for your changes. Lines starting
---
 drivers/staging/rtl8723bs/os_dep/ioctl_linux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
index 3128766dd50e..2ac0d84f090e 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
@@ -3373,7 +3373,7 @@ static int wpa_supplicant_ioctl(struct net_device *dev, 
struct iw_point *p)
 
/* down(>wx_sem); */
 
-   if (p->length < sizeof(struct ieee_param) || !p->pointer) {
+   if (!p->pointer || p->length != sizeof(struct ieee_param)) {
ret = -EINVAL;
goto out;
}
-- 
2.25.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 6/6] staging: rtl8723bs: Remove unneeded goto statements

[Larry Finger]

In routines rtw_hostapd_ioctl() and wpa_supplicant_ioctl(), several
error conditions involve setting a variable indicating the error,
followed by a goto. The code following the target of that goto merely
returns the value. It is simpler, therefore to return the error value
immediately, and eliminate the got  target.

Signed-off-by: Larry Finger 
Cc: Pietro Oliva 
---
 .../staging/rtl8723bs/os_dep/ioctl_linux.c| 47 +--
 1 file changed, 12 insertions(+), 35 deletions(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
index 2ac0d84f090e..9b9038e7deb1 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
@@ -3373,21 +3373,16 @@ static int wpa_supplicant_ioctl(struct net_device *dev, 
struct iw_point *p)
 
/* down(>wx_sem); */
 
-   if (!p->pointer || p->length != sizeof(struct ieee_param)) {
-   ret = -EINVAL;
-   goto out;
-   }
+   if (!p->pointer || p->length != sizeof(struct ieee_param))
+   return -EINVAL;
 
param = rtw_malloc(p->length);
-   if (param == NULL) {
-   ret = -ENOMEM;
-   goto out;
-   }
+   if (param == NULL)
+   return -ENOMEM;
 
if (copy_from_user(param, p->pointer, p->length)) {
kfree(param);
-   ret = -EFAULT;
-   goto out;
+   return -EFAULT;
}
 
switch (param->cmd) {
@@ -3421,12 +3416,8 @@ static int wpa_supplicant_ioctl(struct net_device *dev, 
struct iw_point *p)
 
kfree(param);
 
-out:
-
/* up(>wx_sem); */
-
return ret;
-
 }
 
 static int rtw_set_encryption(struct net_device *dev, struct ieee_param 
*param, u32 param_len)
@@ -4200,28 +4191,19 @@ static int rtw_hostapd_ioctl(struct net_device *dev, 
struct iw_point *p)
* so, we just check hw_init_completed
*/
 
-   if (!padapter->hw_init_completed) {
-   ret = -EPERM;
-   goto out;
-   }
-
+   if (!padapter->hw_init_completed)
+   return -EPERM;
 
-   /* if (p->length < sizeof(struct ieee_param) || !p->pointer) { */
-   if (!p->pointer || p->length != sizeof(*param)) {
-   ret = -EINVAL;
-   goto out;
-   }
+   if (!p->pointer || p->length != sizeof(*param))
+   return -EINVAL;
 
param = rtw_malloc(p->length);
-   if (param == NULL) {
-   ret = -ENOMEM;
-   goto out;
-   }
+   if (param == NULL)
+   return -ENOMEM;
 
if (copy_from_user(param, p->pointer, p->length)) {
kfree(param);
-   ret = -EFAULT;
-   goto out;
+   return -EFAULT;
}
 
/* DBG_871X("%s, cmd =%d\n", __func__, param->cmd); */
@@ -4321,13 +4303,8 @@ static int rtw_hostapd_ioctl(struct net_device *dev, 
struct iw_point *p)
if (ret == 0 && copy_to_user(p->pointer, param, p->length))
ret = -EFAULT;
 
-
kfree(param);
-
-out:
-
return ret;
-
 }
 
 static int rtw_wx_set_priv(struct net_device *dev,
-- 
2.25.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 0/6] staging: rtl8188eu and rtl8723bs - some fixes and cleanups

[Larry Finger]

It was recently reported that staging drivers rtl8188eu and rtl8723bs
contained a security flaw because a parameter had not been checked.
The following patches fix that flaw and cleans up the routines.

Signed-off-by: Larry Finger 


Larry Finger (6):
  staging: rtl8188eu: Fix potential security hole
  staging: rtl8723bs: Fix potential security hole
  staging: rtl8188eu: Fix potential overuse of kernel memory
  staging: rtl8723bs: Fix potential overuse of kernel memory
  staging: rtl8188eu: Remove some unneeded goto statements
  staging: rtl8723bs: Remove unneeded goto statements

 .../staging/rtl8188eu/os_dep/ioctl_linux.c| 40 +---
 .../staging/rtl8723bs/os_dep/ioctl_linux.c| 47 +--
 2 files changed, 24 insertions(+), 63 deletions(-)

-- 
2.25.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 3/3] staging: rtl8188eu: remove return variable from rtw_pwr_unassociated_idle

[Larry Finger]

On 11/23/19 9:16 AM, Michael Straube wrote:

Function rtw_pwr_unassociated_idle returns boolean values.
Remove the return variable ret and the exit label to simplify the
function a little bit. Return true or false directly instead.

Signed-off-by: Michael Straube 
---
  drivers/staging/rtl8188eu/core/rtw_pwrctrl.c | 10 +++---
  1 file changed, 3 insertions(+), 7 deletions(-)


Acked-by: Larry Finger 

Thanks,

Larry

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/3] staging: rtl8188eu: cleanup declarations in rtw_pwrctrl.c

[Larry Finger]

On 11/23/19 9:16 AM, Michael Straube wrote:

Replace tabs with spaces in declarations to cleanup whitespace.

Signed-off-by: Michael Straube 
---
  drivers/staging/rtl8188eu/core/rtw_pwrctrl.c | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)


Acked-by: Larry Finger 

Thanks,

Larry


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/3] staging: rtl8188eu: remove unnecessary parentheses in rtw_pwrctrl.c

[Larry Finger]

On 11/23/19 9:16 AM, Michael Straube wrote:

Remove unnecessary parentheses reported by checkpatch.

Signed-off-by: Michael Straube 
---
  drivers/staging/rtl8188eu/core/rtw_pwrctrl.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)


Acked-by: Larry Finger 

Thanks,

Larry

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2] staging: rtl8188eu: remove dead code/vestigial do..while loop

[Larry Finger]

On 9/24/19 9:28 AM, Connor Kuehl wrote:

The local variable 'bcmd_down' is always set to true almost immediately
before the do-while's condition is checked. As a result, !bcmd_down
evaluates to false which short circuits the logical AND operator meaning
that the second operand is never reached and is therefore dead code.

Furthermore, the do..while loop may be removed since it will always only
execute once because 'bcmd_down' is always set to true, so the
!bcmd_down evaluates to false and the loop exits immediately after the
first pass.

Fix this by removing the loop and its condition variables 'bcmd_down'
and 'retry_cnts'

While we're in there, also fix some checkpatch.pl suggestions regarding
spaces around arithmetic operators like '+'

Addresses-Coverity: ("Logically dead code")

Signed-off-by: Connor Kuehl 
---
v1 -> v2:
  - remove the loop and its condition variable bcmd_down
  - address some non-invasive checkpatch.pl suggestions as a result of
deleting the loop

  drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c | 55 +---
  1 file changed, 24 insertions(+), 31 deletions(-)

diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c 
b/drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c
index 47352f210c0b..7646167a0b36 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c
@@ -47,8 +47,6 @@ static u8 _is_fw_read_cmd_down(struct adapter *adapt, u8 
msgbox_num)
  **/
  static s32 FillH2CCmd_88E(struct adapter *adapt, u8 ElementID, u32 CmdLen, u8 
*pCmdBuffer)
  {
-   u8 bcmd_down = false;
-   s32 retry_cnts = 100;
u8 h2c_box_num;
u32 msgbox_addr;
u32 msgbox_ex_addr;
@@ -71,39 +69,34 @@ static s32 FillH2CCmd_88E(struct adapter *adapt, u8 
ElementID, u32 CmdLen, u8 *p
goto exit;
  
  	/* pay attention to if  race condition happened in  H2C cmd setting. */

-   do {
-   h2c_box_num = adapt->HalData->LastHMEBoxNum;
-
-   if (!_is_fw_read_cmd_down(adapt, h2c_box_num)) {
-   DBG_88E(" fw read cmd failed...\n");
-   goto exit;
-   }
-
-   *(u8 *)(_cmd) = ElementID;
-
-   if (CmdLen <= 3) {
-   memcpy((u8 *)(_cmd)+1, pCmdBuffer, CmdLen);
-   } else {
-   memcpy((u8 *)(_cmd)+1, pCmdBuffer, 3);
-   ext_cmd_len = CmdLen-3;
-   memcpy((u8 *)(_cmd_ex), pCmdBuffer+3, ext_cmd_len);
+   h2c_box_num = adapt->HalData->LastHMEBoxNum;
  
-			/* Write Ext command */

-   msgbox_ex_addr = REG_HMEBOX_EXT_0 + (h2c_box_num * 
RTL88E_EX_MESSAGE_BOX_SIZE);
-   for (cmd_idx = 0; cmd_idx < ext_cmd_len; cmd_idx++)
-   usb_write8(adapt, msgbox_ex_addr+cmd_idx, *((u8 
*)(_cmd_ex)+cmd_idx));
-   }
-   /*  Write command */
-   msgbox_addr = REG_HMEBOX_0 + (h2c_box_num * 
RTL88E_MESSAGE_BOX_SIZE);
-   for (cmd_idx = 0; cmd_idx < RTL88E_MESSAGE_BOX_SIZE; cmd_idx++)
-   usb_write8(adapt, msgbox_addr+cmd_idx, *((u8 
*)(_cmd)+cmd_idx));
+   if (!_is_fw_read_cmd_down(adapt, h2c_box_num)) {
+   DBG_88E(" fw read cmd failed...\n");
+   goto exit;
+   }
  
-		bcmd_down = true;

+   *(u8 *)(_cmd) = ElementID;
  
-		adapt->HalData->LastHMEBoxNum =

-   (h2c_box_num+1) % RTL88E_MAX_H2C_BOX_NUMS;
+   if (CmdLen <= 3) {
+   memcpy((u8 *)(_cmd) + 1, pCmdBuffer, CmdLen);
+   } else {
+   memcpy((u8 *)(_cmd) + 1, pCmdBuffer, 3);
+   ext_cmd_len = CmdLen - 3;
+   memcpy((u8 *)(_cmd_ex), pCmdBuffer + 3, ext_cmd_len);
+
+   /* Write Ext command */
+   msgbox_ex_addr = REG_HMEBOX_EXT_0 + (h2c_box_num * 
RTL88E_EX_MESSAGE_BOX_SIZE);
+   for (cmd_idx = 0; cmd_idx < ext_cmd_len; cmd_idx++)
+   usb_write8(adapt, msgbox_ex_addr + cmd_idx, *((u8 
*)(_cmd_ex) + cmd_idx));
+   }
+   /*  Write command */
+   msgbox_addr = REG_HMEBOX_0 + (h2c_box_num * RTL88E_MESSAGE_BOX_SIZE);
+   for (cmd_idx = 0; cmd_idx < RTL88E_MESSAGE_BOX_SIZE; cmd_idx++)
+   usb_write8(adapt, msgbox_addr + cmd_idx, *((u8 *)(_cmd) + 
cmd_idx));
  
-	} while ((!bcmd_down) && (retry_cnts--));

+   adapt->HalData->LastHMEBoxNum =
+   (h2c_box_num + 1) % RTL88E_MAX_H2C_BOX_NUMS;
  
  	ret = _SUCCESS;


Acked-by: Larry Finger 

Thanks,

Larry

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: rtl8188eu: fix HighestRate check in odm_ARFBRefresh_8188E()

[Larry Finger]

On 9/26/19 2:31 AM, Denis Efremov wrote:

It's incorrect to compare HighestRate with 0x0b twice in the following
manner "if (HighestRate > 0x0b) ... else if (HighestRate > 0x0b) ...". The
"else if" branch is constantly false. The second comparision should be
with 0x03 according to the max_rate_idx in ODM_RAInfo_Init().

Cc: Larry Finger 
Cc: Greg Kroah-Hartman 
Cc: Michael Straube 
Cc: sta...@vger.kernel.org
Signed-off-by: Denis Efremov 
---
  drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c 
b/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
index 9ddd51685063..5792f491b59a 100644
--- a/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
+++ b/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
@@ -409,7 +409,7 @@ static int odm_ARFBRefresh_8188E(struct odm_dm_struct 
*dm_odm, struct odm_ra_inf
pRaInfo->PTModeSS = 3;
else if (pRaInfo->HighestRate > 0x0b)
pRaInfo->PTModeSS = 2;
-   else if (pRaInfo->HighestRate > 0x0b)
+   else if (pRaInfo->HighestRate > 0x03)
pRaInfo->PTModeSS = 1;
else
pRaInfo->PTModeSS = 0;



I agree that the original code is wrong; however, I prefer that changes that 
alter the execution should be tested. I see no evidence that such testing has 
been done. It probably does not matter because a highest rate between 3 and 0xb 
means 802.11g is in use, and that may no longer be a real-world situation.


With any future patches, you need to indicate if testing has been done.

Acked-by: Larry Finger 

Larry

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2] staging: rtl8188eu: fix possible null dereference

[Larry Finger]

On 9/26/19 10:03 AM, Connor Kuehl wrote:

Inside a nested 'else' block at the beginning of this function is a
call that assigns 'psta' to the return value of 'rtw_get_stainfo()'.
If 'rtw_get_stainfo()' returns NULL and the flow of control reaches
the 'else if' where 'psta' is dereferenced, then we will dereference
a NULL pointer.

Fix this by checking if 'psta' is not NULL before reading its
'psta->qos_option' data member.

Addresses-Coverity: ("Dereference null return value")

Signed-off-by: Connor Kuehl 
---
v1 -> v2:
   - Add the same null check to line 779

  drivers/staging/rtl8188eu/core/rtw_xmit.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c 
b/drivers/staging/rtl8188eu/core/rtw_xmit.c
index 952f2ab51347..c37591657bac 100644
--- a/drivers/staging/rtl8188eu/core/rtw_xmit.c
+++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c
@@ -776,7 +776,7 @@ s32 rtw_make_wlanhdr(struct adapter *padapter, u8 *hdr, 
struct pkt_attrib *pattr
memcpy(pwlanhdr->addr2, get_bssid(pmlmepriv), ETH_ALEN);
memcpy(pwlanhdr->addr3, pattrib->src, ETH_ALEN);
  
-			if (psta->qos_option)

+   if (psta && psta->qos_option)
qos_option = true;
} else if (check_fwstate(pmlmepriv, WIFI_ADHOC_STATE) ||
   check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE)) {
@@ -784,7 +784,7 @@ s32 rtw_make_wlanhdr(struct adapter *padapter, u8 *hdr, 
struct pkt_attrib *pattr
memcpy(pwlanhdr->addr2, pattrib->src, ETH_ALEN);
memcpy(pwlanhdr->addr3, get_bssid(pmlmepriv), ETH_ALEN);
  
-			if (psta->qos_option)

+   if (psta && psta->qos_option)
qos_option = true;
} else {
RT_TRACE(_module_rtl871x_xmit_c_, _drv_err_, ("fw_state:%x 
is not allowed to xmit frame\n", get_fwstate(pmlmepriv)));



Acked-by: Larry Finger 

Thanks,

Larry

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: rtl8188eu: fix possible null dereference

[Larry Finger]

On 9/25/19 4:32 PM, Connor Kuehl wrote:

Inside a nested 'else' block at the beginning of this function is a
call that assigns 'psta' to the return value of 'rtw_get_stainfo()'.
If 'rtw_get_stainfo()' returns NULL and the flow of control reaches
the 'else if' where 'psta' is dereferenced, then we will dereference
a NULL pointer.

Fix this by checking if 'psta' is not NULL before reading its
'psta->qos_option' data member.

Addresses-Coverity: ("Dereference null return value")

Signed-off-by: Connor Kuehl 
---
  drivers/staging/rtl8188eu/core/rtw_xmit.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c 
b/drivers/staging/rtl8188eu/core/rtw_xmit.c
index 952f2ab51347..bf8877cbe9b6 100644
--- a/drivers/staging/rtl8188eu/core/rtw_xmit.c
+++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c
@@ -784,7 +784,7 @@ s32 rtw_make_wlanhdr(struct adapter *padapter, u8 *hdr, 
struct pkt_attrib *pattr
memcpy(pwlanhdr->addr2, pattrib->src, ETH_ALEN);
memcpy(pwlanhdr->addr3, get_bssid(pmlmepriv), ETH_ALEN);
  
-			if (psta->qos_option)

+   if (psta && psta->qos_option)
qos_option = true;
} else {
RT_TRACE(_module_rtl871x_xmit_c_, _drv_err_, ("fw_state:%x 
is not allowed to xmit frame\n", get_fwstate(pmlmepriv)));



This change is a good one, but why not get the same fix at line 779?

Larry

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: rtl8188eu: remove dead code in do-while conditional step

[Larry Finger]

On 9/23/19 2:48 PM, Connor Kuehl wrote:

The local variable 'bcmd_down' is always set to true almost immediately
before the do-while's condition is checked. As a result, !bcmd_down
evaluates to false which short circuits the logical AND operator meaning
that the second operand is never reached and is therefore dead code.

Addresses-Coverity: ("Logically dead code")

Signed-off-by: Connor Kuehl 
---
  drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c 
b/drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c
index 47352f210c0b..a4b317937b23 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c
@@ -48,7 +48,6 @@ static u8 _is_fw_read_cmd_down(struct adapter *adapt, u8 
msgbox_num)
  static s32 FillH2CCmd_88E(struct adapter *adapt, u8 ElementID, u32 CmdLen, u8 
*pCmdBuffer)
  {
u8 bcmd_down = false;
-   s32 retry_cnts = 100;
u8 h2c_box_num;
u32 msgbox_addr;
u32 msgbox_ex_addr;
@@ -103,7 +102,7 @@ static s32 FillH2CCmd_88E(struct adapter *adapt, u8 
ElementID, u32 CmdLen, u8 *p
adapt->HalData->LastHMEBoxNum =
(h2c_box_num+1) % RTL88E_MAX_H2C_BOX_NUMS;
  
-	} while ((!bcmd_down) && (retry_cnts--));

+   } while (!bcmd_down);
  
  	ret = _SUCCESS;


This patch is correct; however, the do..while loop will always be executed once, 
thus you could remove the loop and the loop variable bcmd_down.


@greg: If you would prefer a two-step process, then this one is OK.

Larry

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: rtl8188eu: make two arrays static const, makes object smaller

[Larry Finger]

On 9/6/19 12:39 PM, Colin King wrote:

From: Colin Ian King 

Don't populate two arrays on the stack but instead make them
static const. Makes the object code smaller by 49 bytes.

Before:
text   data bss dec hex filename
   26821   5616   0   324377eb5 rtl8188eu/core/rtw_ieee80211.o

After:
text   data bss dec hex filename
   26612   5776   0   323887e84 rtl8188eu/core/rtw_ieee80211.o

(gcc version 9.2.1, amd64)

Signed-off-by: Colin Ian King 
---


Acked-by: Larry Finger 

Thanks,

Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/2] staging: rtl8192e: rtllib_crypt_ccmp.c: Use crypto API ccm(aes)

[Larry Finger]

On 8/16/19 1:59 AM, Christina Quast wrote:

Use ccm(aes) aead transform instead of invoking the AES block cipher
block by block.

Signed-off-by: Christina Quast 
---
  drivers/staging/rtl8192e/Kconfig |   1 +
  drivers/staging/rtl8192e/rtllib_crypt_ccmp.c | 187 ---
  2 files changed, 78 insertions(+), 110 deletions(-)


Tested-by: Larry Finger 

This change for the RTL8192E works. I do not have the hardware for testing the 
equivalent change for r8192u, but as the changes look the same, that one is 
likely OK as well.


Thanks for the change,

Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/6] staging: rtl8188eu: add spaces around '+' in usb_halinit.c

[Larry Finger]

On 7/26/19 1:04 PM, Michael Straube wrote:

Add spaces around '+' to improve readability and follow kernel
coding style. Reported by checkpatch.

Signed-off-by: Michael Straube 
---
  drivers/staging/rtl8188eu/hal/usb_halinit.c | 76 ++---
  1 file changed, 38 insertions(+), 38 deletions(-)


If they apply, all six of these are OK.

Acked-by: Larry Finger 

Larry

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: Add rtl8821ce PCIe WiFi driver

[Larry Finger]

On 5/15/19 8:06 AM, Kai-Heng Feng wrote:

at 20:33, Greg KH  wrote:


On Wed, May 15, 2019 at 07:54:58PM +0800, Kai-Heng Feng wrote:

at 19:40, Greg KH  wrote:


On Wed, May 15, 2019 at 07:24:01PM +0800, Kai-Heng Feng wrote:

The rtl8821ce can be found on many HP and Lenovo laptops.
Users have been using out-of-tree module for a while,

The new Realtek WiFi driver, rtw88, will support rtl8821ce in 2020 or
later.


Where is that driver, and why is it going to take so long to get merged?


rtw88 is in 5.2 now, but it doesn’t support 8821ce yet.

They plan to add the support in 2020.


Who is "they" and what is needed to support this device and why wait a
full year?


“They” refers to Realtek.
It’s their plan so I can’t really answer that on behalf of Realtek.




296 files changed, 206166 insertions(+)


Ugh, why do we keep having to add the whole mess for every single one of
these devices?


Because Realtek devices are unfortunately ubiquitous so the support is
better come from kernel.


That's not the issue here.  The issue is that we keep adding the same
huge driver files to the kernel tree, over and over, with no real change
at all.  We have seen almost all of these files in other realtek
drivers, right?


Yes. They use one single driver to support different SoCs, different 
architectures and even different OSes.

That’s why it’s a mess.


Why not use the ones we already have?


It’s virtually impossible because Realtek’s mega wifi driver uses tons of 
#ifdefs, only one chip can be selected to be supported at compile time.




But better yet, why not add proper support for this hardware and not use
a staging driver?


Realtek plans to add the support in 2020, if everything goes well.
Meanwhile, many users of HP and Lenovo laptops are using out-of-tree driver, 
some of them are stuck to older kernels because they don’t know how to fix the 
driver. So I strongly think having this in kernel is beneficial to many users, 
even it’s only for a year.


Why not solve the older kernel problem the way I do with drivers for many 
Realtek devices by creating a GitHub project with the kernel API changes 
properly handled by ifdef statements? See the lwfinger projects. That solves the 
problem of users without the skills needed to adjust to kernel changes without 
burdening the entire Linux kernel with these bloated drivers. There are no 
reasons that a wifi driver should require 200K lines of code!


Larry

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: rtl8*: use help instead of ---help--- in Kconfig

[Larry Finger]

On 4/20/19 6:37 AM, MosesChristopher wrote:

From: Moses Christopher 

   - Resolve the following warning from the Kconfig,
 "WARNING: prefer 'help' over '---help---' for new help texts"

Signed-off-by: Moses Christopher 


I have never seen this warning, but your Kconfig may be newer than mine. In any 
case, the changes are harmless.


Acked-by: Larry Finger 


---
  drivers/staging/rtl8188eu/Kconfig | 4 ++--
  drivers/staging/rtl8192e/Kconfig  | 8 
  drivers/staging/rtl8712/Kconfig   | 4 ++--
  drivers/staging/rtl8723bs/Kconfig | 2 +-
  4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/rtl8188eu/Kconfig 
b/drivers/staging/rtl8188eu/Kconfig
index ff7832798a77..3f8c655856bf 100644
--- a/drivers/staging/rtl8188eu/Kconfig
+++ b/drivers/staging/rtl8188eu/Kconfig
@@ -7,7 +7,7 @@ config R8188EU
select LIB80211
select LIB80211_CRYPT_WEP
select LIB80211_CRYPT_CCMP
-   ---help---
+   help
This option adds the Realtek RTL8188EU USB device such as TP-Link 
TL-WN725N.
If built as a module, it will be called r8188eu.
  
@@ -16,7 +16,7 @@ if R8188EU

  config 88EU_AP_MODE
bool "Realtek RTL8188EU AP mode"
default y
-   ---help---
+   help
This option enables Access Point mode. Unless you know that your system
will never be used as an AP, or the target system has limited memory,
"Y" should be selected.
diff --git a/drivers/staging/rtl8192e/Kconfig b/drivers/staging/rtl8192e/Kconfig
index 4602a47cdb4a..aa571c12678f 100644
--- a/drivers/staging/rtl8192e/Kconfig
+++ b/drivers/staging/rtl8192e/Kconfig
@@ -3,7 +3,7 @@ config RTLLIB
depends on WLAN && m
default n
select LIB80211
-   ---help---
+   help
  If you have a wireless card that uses rtllib, say
  Y. Currently the only card is the rtl8192e.
  
@@ -16,7 +16,7 @@ config RTLLIB_CRYPTO_CCMP

depends on RTLLIB
select CRYPTO_AES
default y
-   ---help---
+   help
  CCMP crypto driver for rtllib.
  
  	  If you enabled RTLLIB, you want this.

@@ -27,7 +27,7 @@ config RTLLIB_CRYPTO_TKIP
select CRYPTO_ARC4
select CRYPTO_MICHAEL_MIC
default y
-   ---help---
+   help
  TKIP crypto driver for rtllib.
  
  	  If you enabled RTLLIB, you want this.

@@ -37,7 +37,7 @@ config RTLLIB_CRYPTO_WEP
select CRYPTO_ARC4
depends on RTLLIB
default y
-   ---help---
+   help
  TKIP crypto driver for rtllib.
  
  	  If you enabled RTLLIB, you want this.

diff --git a/drivers/staging/rtl8712/Kconfig b/drivers/staging/rtl8712/Kconfig
index f160eee52f09..b377d90742db 100644
--- a/drivers/staging/rtl8712/Kconfig
+++ b/drivers/staging/rtl8712/Kconfig
@@ -4,14 +4,14 @@ config R8712U
select WIRELESS_EXT
select WEXT_PRIV
select FW_LOADER
-   ---help---
+   help
This option adds the Realtek RTL8712 USB device such as the D-Link 
DWA-130.
If built as a module, it will be called r8712u.
  
  config R8712_TX_AGGR

bool "Realtek RTL8712U Transmit Aggregation code"
depends on R8712U && BROKEN
-   ---help---
+   help
This option provides transmit aggregation for the Realtek RTL8712 USB 
device.
  
  
diff --git a/drivers/staging/rtl8723bs/Kconfig b/drivers/staging/rtl8723bs/Kconfig

index deae0427ba6c..41ad6ed24860 100644
--- a/drivers/staging/rtl8723bs/Kconfig
+++ b/drivers/staging/rtl8723bs/Kconfig
@@ -4,7 +4,7 @@ config RTL8723BS
depends on m
select WIRELESS_EXT
select WEXT_PRIV
-   ---help---
+   help
This option enables support for RTL8723BS SDIO drivers, such as
the wifi found on the 1st gen Intel Compute Stick, the CHIP
and many other Intel Atom and ARM based devices.



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH -next] staging: rtl8712: drop pointless static qualifier in r8712_efuse_pg_packet_write()

[Larry Finger]

On 1/21/19 1:53 AM, YueHaibing wrote:

There is no need to have the 'intrepeat_times' variable static since new
value always be assigned before use it.

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

diff --git a/drivers/staging/rtl8712/rtl8712_efuse.c 
b/drivers/staging/rtl8712/rtl8712_efuse.c
index 8bc45ff..39eb743 100644
--- a/drivers/staging/rtl8712/rtl8712_efuse.c
+++ b/drivers/staging/rtl8712/rtl8712_efuse.c
@@ -358,7 +358,7 @@ u8 r8712_efuse_pg_packet_write(struct _adapter *padapter, 
const u8 offset,
u8 pg_header = 0;
u16 efuse_addr = 0, curr_size = 0;
u8 efuse_data, target_word_cnts = 0;
-   static int repeat_times;
+   int repeat_times;
int sub_repeat;
u8 bResult = true;


Clearly, the value of this variable is not intended to be carried over between 
calls to this routine. Your fix is correct.


Acked-by: Larry Finger 

Thanks,

Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: rtl8188eu: Add device code for D-Link DWA-121 rev B1

[Larry Finger]

On 1/7/19 11:28 AM, Michael Straube wrote:

This device was added to the stand-alone driver on github.
Add it to the staging driver as well.

Link: https://github.com/lwfinger/rtl8188eu/commit/a0619a07cd1e
Signed-off-by: Michael Straube 


Acked-by: Larry Finger 

Thanks,

Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2] staging: wilc1000: fix cast to restricted __le32

[Larry Finger]

On 1/5/19 3:10 AM, Július Milan wrote:

Fixes the following sparse warnings:

drivers/staging/wilc1000/host_interface.c:2360:30: warning:
  incorrect type in assignment (different base types)
 expected restricted __le32 [addressable] [assigned] [usertype] frame_type
 got restricted __le16 [usertype] 

Fixes: 147ccfd451024 ("staging: wilc1000: handle mgmt_frame_register ops from 
cfg82011 context")
Signed-off-by: Július Milan 
---
  drivers/staging/wilc1000/host_interface.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 5dae6e7155d3..07c3d6293573 100644
--- a/struct wilc_reg_frame
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -2357,7 +2357,7 @@ void wilc_frame_register(struct wilc_vif *vif, u16 
frame_type, bool reg)
default:
break;
}
-   reg_frame.frame_type = cpu_to_le16(frame_type);
+   reg_frame.frame_type = cpu_to_le32(frame_type);
result = wilc_send_config_pkt(vif, WILC_SET_CFG, , 1,
  wilc_get_vif_idx(vif));
if (result)


Before you send V3, are you sure this is the correct fix? As "frame_type" is 
input as u16, it seems to me that the frame_type member of struct wilc_reg_frame 
should be __le16, not __le32.


Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Larry Finger]

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

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

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

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Larry Finger]

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

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

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

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

-- 
2.16.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Larry Finger]

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

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

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

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] MAINTAINERS: Add entry for staging driver r8188eu

[Larry Finger]

This entry was missed when the driver was added.

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

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

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

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

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Revert "staging:r8188eu: use lib80211 CCMP decrypt"

[Larry Finger]

On 1/1/19 1:31 PM, Michael Straube wrote:


I've tested your patch and it solved the issue. No freezes and dmesg looks good.

I noticed that try_then_request_module() is also used in rtw_wep_encrypt() and
rtw_wep_decrypt(). I guess that also could cause problems?


Yes, I believe it would if anyone is still using WEP. My plan is to get rid of 
the try_then_request_module() there as well, and for completeness, I plan to 
restore usage of the lib80211 routines for TKIP as well.


Once I get a chance to test the TKIP and WEP changes, I plan to have a set of 4 
patches to switch the driver to using lib80211 routines for all 
decryption/encryption.


Larry


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Revert "staging:r8188eu: use lib80211 CCMP decrypt"

[Larry Finger]

On 1/1/19 3:02 AM, Ivan Safonov wrote:
I suggested a patch for loading modules from interruptible mode, but this patch 
remained unclaimed ( 
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-August/124851.html 
).


For some reason I thought that this patch had been removed and did not track the 
fate of this code ( 
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-August/124573.html 
).


That patch was quite extensive, but had only a minimal commit message. I'm 
surprised that it did not get a bad review, but I can see why it was ignored.


Where did you submit that patch? It certainly was never in my mailbox.

Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Revert "staging:r8188eu: use lib80211 CCMP decrypt"

[Larry Finger]

On 12/30/18 12:39 PM, Michael Straube wrote:

Commit 6bd082af7e36 ("staging:r8188eu: use lib80211 CCMP decrypt")
is causing hardfreeze whenever the driver tries to connect to my wifi
network. That makes the driver unusable on my system. Reverting the
commit fixes the issue and the driver works properly.

Dec 29 19:21:17 gentoo kernel: BUG: scheduling while atomic: 
swapper/6/0/0x0100


Michael,

I have verified the freezes that you see. Although I have not been able to 
capture the console dump, I think we are likely seeing the same problem.


I do have a work-around in that I have not gotten any freezes when I force 
module lib80211_crypt_ccmp to be loaded before I load module r8188eu. This clue 
was used in finding what seems to be a good fix.


I do not know anything about demand loading of modules using 
try_then_request_module(); however, I noticed that the macro actually calls 
__request_module(), which has the following comment:


 * Load a module using the user mode module loader. The function returns
 * zero on success or a negative errno code or positive exit code from
 * "modprobe" on failure. Note that a successful module load does not mean
 * the module did not then unload and exit on an error of its own. Callers
 * must check that the service they requested is now available not blindly
 * invoke it.

I note that it says "user mode module loader". Routine rtw_aes_decrypt() is 
likely inside some sort of locking, which leads to the "scheduling while atomic" 
bug that you see. As a result, I suspect that the module is not loaded, and that 
leads to the NULL dereference when the module is accessed. Please try the 
one-line patch attached, which forces lib80211 to load when r8188eu is loaded. 
With this patch, I have been connected to an AES-encrypted AP for nearly 3 hours 
with no problems.


Larry


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

[PATCH] staging: rtl8723bs: Add missing return for cfg80211_rtw_get_station

[Larry Finger]

With Androidx86 8.1, wificond returns "failed to get
nl80211_sta_info_tx_failed" and wificondControl returns "Invalid signal
poll result from wificond". The fix is to OR sinfo->filled with
BIT_ULL(NL80211_STA_INFO_TX_FAILED).

This missing bit is apparently not needed with NetworkManager, but it
does no harm in that case.

Reported-and-Tested-by: youling257 
Cc: linux-wirel...@vger.kernel.org
Cc: youling257 
Signed-off-by: Larry Finger 
---
 drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index af2234798fa8..db553f2e4c0b 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -1277,7 +1277,7 @@ static int cfg80211_rtw_get_station(struct wiphy *wiphy,
 
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_TX_PACKETS);
sinfo->tx_packets = psta->sta_stats.tx_pkts;
-
+   sinfo->filled |= BIT_ULL(NL80211_STA_INFO_TX_FAILED);
}
 
/* for Ad-Hoc/AP mode */
-- 
2.19.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[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

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2] staging: rtl8188eu: Skip unnecessary field checks

[Larry Finger]

On 9/27/18 4:19 PM, Aymen Qader wrote:

Skip unnecessary request field checks when the information element
pointer is null.

Signed-off-by: Aymen Qader 
---
v2: combine pointer check and length check & change commit message to be
more appropriate

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

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
index 834053a0ae9d..4d55bbdf8fb7 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
@@ -2971,11 +2971,11 @@ static unsigned int OnAssocReq(struct adapter *padapter,
/*  checking SSID */
p = rtw_get_ie(pframe + WLAN_HDR_A3_LEN + ie_offset, _SSID_IE_, _len,
pkt_len - WLAN_HDR_A3_LEN - ie_offset);
-   if (!p)
-   status = _STATS_FAILURE_;
  
-	if (ie_len == 0) { /*  broadcast ssid, however it is not allowed in assocreq */

+   if (!p || ie_len == 0) {
+   /*  broadcast ssid, however it is not allowed in assocreq */
status = _STATS_FAILURE_;
+   goto OnAssocReqFail;
} else {
/*  check if ssid match */
if (memcmp((void *)(p+2), cur->Ssid.Ssid, cur->Ssid.SsidLength))



ACKed-by: Larry Finger 


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: rtl8188eu: Avoid null pointer arithmetic

[Larry Finger]

On 9/27/18 12:04 PM, Aymen Qader wrote:

Avoid null pointer arithmetic in rtw_mlme_ext.c by skipping other field
checks if the information element pointer is null.

Signed-off-by: Aymen Qader 
---
  drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
index 834053a0ae9d..8a3a71456cd0 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
@@ -2971,8 +2971,10 @@ static unsigned int OnAssocReq(struct adapter *padapter,
/*  checking SSID */
p = rtw_get_ie(pframe + WLAN_HDR_A3_LEN + ie_offset, _SSID_IE_, _len,
pkt_len - WLAN_HDR_A3_LEN - ie_offset);
-   if (!p)
+   if (!p) {
status = _STATS_FAILURE_;
+   goto OnAssocReqFail;
+   }
  
  	if (ie_len == 0) { /*  broadcast ssid, however it is not allowed in assocreq */

status = _STATS_FAILURE_;


I do not think this patch avoids any pointer arithmetic. If p is NULL, then 
ie_len will be zero and the branch with the memcmp() call, where the pointer 
arithmetic is done, will be skipped.


That said, it is better to bail out with the first failure condition. I do not 
require the following, but the code would be even simpler if you test p and 
ie_len==0 in a single if statement and eliminate some code as in


diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c

index 1115050077e4..71722cec84a0 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
@@ -2982,11 +2982,10 @@ static unsigned int OnAssocReq(struct adapter *padapter,
/*  checking SSID */
p = rtw_get_ie(pframe + WLAN_HDR_A3_LEN + ie_offset, _SSID_IE_, _len,
pkt_len - WLAN_HDR_A3_LEN - ie_offset);
-   if (!p)
-   status = _STATS_FAILURE_;

-   if (ie_len == 0) { /*  broadcast ssid, however it is not allowed in 
assocreq */
+   if (!p || ie_len == 0) { /*  broadcast ssid, however it is not allowed 
in assocreq */

status = _STATS_FAILURE_;
+   goto OnAssocReqFail;
} else {
/*  check if ssid match */
if (memcmp((void *)(p+2), cur->Ssid.Ssid, cur->Ssid.SsidLength))


ACKed-by: Larry Finger 

Thanks,

Larry

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 01/21] staging:rtl8192u: Rename AdvCoding - Style

[Larry Finger]

On 08/29/2018 04:14 PM, Joe Perches wrote:

On Wed, 2018-08-29 at 21:35 +0100, John Whitmore wrote:

Rename the bit field element AdvCoding, as it causes a checkpatch issue
with CamelCase naming. As the element is not actually used in code it
has been renamed to 'not_used_adv_coding'.

The single line of code which initialises the bit has been removed,
as the  field is unused.

This is a purely coding style change which should have no impact
on runtime code execution.


Hi John.

Other than the somewhat useful code style cleanups, is there
a point at which you will feel comfortable doing actual code
changes to this driver?

Perhaps support for the chipset could be converted to use
mac80211 and moved into the directory with the other realtek
drivers in drivers/net/wireless/realtek/rtl8xxxu/...

Larry?  What do you think?


First of all, if a variable is not used, then it should be removed, not merely 
renamed to satisfy checkpatch.


All the Realtek USB devices should be added to rtl8xxxu, not merely moved into 
that directory. Jes Sorensen created a well-designed driver the is structured to 
permit addition of different initialization routines, etc. That said, the 
conversion will not be easy. In addition, it will require having your hands on a 
real device - a requirement that I cannot meet for the RTL8192U.


Larry

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[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

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[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

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[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

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[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

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[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

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging:rtl8712: Style - Removed inline block comment to fix "Statements should start on a tapstop"

[Larry Finger]

On 08/08/2018 04:22 AM, Greg KH wrote:

On Sun, Aug 05, 2018 at 09:41:06PM +0200, Frank Werner-Krippendorf wrote:

Removed 5 inline comments "/*volatile*/" rtl87x_event.h, to fix
a coding style issue "Statements should start on a tabstop"
detected by checkpatch.pl script.

Signed-off-by: Frank Werner-Krippendorf 
---
  drivers/staging/rtl8712/rtl871x_event.h | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl871x_event.h 
b/drivers/staging/rtl8712/rtl871x_event.h
index 5171379..2e59e8e 100644
--- a/drivers/staging/rtl8712/rtl871x_event.h
+++ b/drivers/staging/rtl8712/rtl871x_event.h
@@ -90,13 +90,13 @@ struct event_node {
unsigned char *node;
unsigned char evt_code;
unsigned short evt_sz;
-   /*volatile*/ int *caller_ff_tail;
+   int *caller_ff_tail;
int caller_ff_sz;
  };
  
  struct c2hevent_queue {

-   /*volatile*/ inthead;
-   /*volatile*/ inttail;


Those "volatile" seem to imply that something is needed for these
variables.  Please check to ensure that these are ok to remove in that
there is the proper locking for these types of things.


Those in-line comments are there as a warning that these variables are special. 
Just because a tool such as checkpatch says to remove them does not mean that 
you should; however, if you want to get rid of the warnings, change the space(s) 
after the "*/" into a tab. That silences the checkpatch warning without removing 
the implicit warning that these variables are special.


NACK.

Keep in mind that when this driver was submitted, it ran checkpatch cleanly. The 
fact that there are now warnings is due to changes in the tool. Following those 
will be a never-ending task.


Larry

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/2] staging: fix unneeded_variables warnings

[Larry Finger]

On 08/05/2018 02:35 PM, Umang Parmar wrote:

Directly return value and remove unneeded variables.
Signed-off-by: Umang Parmar 


This patch also has the same problem with the subject. Otherwise it is OK.

Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/2] staging: fix possible_condition_with_no_effect warnings

[Larry Finger]

On 08/05/2018 02:35 PM, Umang Parmar wrote:

Remove unnecessary conditions where if and else block had same code.
Signed-off-by: Umang Parmar 


The subject should be "staging: rtlwifi: ...". If someone wants to search for 
fixes to the modules in drivers/staging/rtlwifi/, your subject would not be helpful.

---
  .../rtlwifi/btcoexist/halbtc8822b2ant.c   |  6 
  .../staging/rtlwifi/btcoexist/halbtcoutsrc.c  |  6 ++--
  drivers/staging/rtlwifi/phydm/phydm_debug.c   | 29 ++-
  drivers/staging/rtlwifi/phydm/phydm_dig.c | 10 ++-
  .../staging/rtlwifi/phydm/phydm_hwconfig.c|  4 +--
  drivers/staging/rtlwifi/phydm/phydm_psd.c |  7 +
  6 files changed, 16 insertions(+), 46 deletions(-)


Why do some of the above have "drivers/staging/..." and others have 
".../staging/..."? This looks a bit strange.


Otherwise, this patch looks OK.

Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Larry Finger]

On 07/05/2018 02:36 AM, Pkshih wrote:

On Wed, 2018-07-04 at 10:33 -0500, Daniel Drake wrote:

On Wed, Jul 4, 2018 at 10:13 AM, Larry Finger  wrote:

We will have to agree to disagree.

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

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


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


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



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


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

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



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


diff --git a/drivers/staging/rtlwifi/rtl8822be/hw.c 
b/drivers/staging/rtlwifi/rtl8822be/hw.c
index 7947edb239a1..88ba5b2fea6a 100644
--- a/drivers/staging/rtlwifi/rtl8822be/hw.c
+++ b/drivers/staging/rtlwifi/rtl8822be/hw.c
@@ -803,7 +803,7 @@ static void _rtl8822be_enable_aspm_back_door(struct 
ieee80211_hw *hw)
    return;
  
  	pci_read_config_byte(rtlpci->pdev, 0x70f, );

-   pci_write_config_byte(rtlpci->pdev, 0x70f, tmp | BIT(7));
+   pci_write_config_byte(rtlpci->pdev, 0x70f, tmp | ASPM_L1_LATENCY << 3);


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

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


Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Larry Finger]

On 07/04/2018 09:09 AM, Dan Carpenter wrote:

On Wed, Jul 04, 2018 at 08:55:00AM -0500, Larry Finger wrote:

I do not think this is a bug.


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

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


We will have to agree to disagree.

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


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


Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Larry Finger]

On 07/04/2018 03:03 AM, Jian-Hong Pan wrote:

Hi,

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

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

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

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

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

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

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

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

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

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

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


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


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


Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH][next][V2] staging: r8822be: fix typos in header guard macros

[Larry Finger]

On 03/23/2018 01:00 PM, Colin King wrote:

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

The macros for __PHYDMKFREE_H__ and __PHYDM_FEATURES_H__ contain
typos and don't match the #if guard check. Defined them correctly.

Cleans up clang warnings:
warning: '__PHYDMKFREE_H__' is used as a header guard here, followed
by #define of a different macro [-Wheader-guard]
warning: '__PHYDM_FEATURES_H__' is used as a header guard here, followed
by #define of a different macro [-Wheader-guard]

Fixes: 9ce99b04b5b8 ("staging: r8822be: Add phydm mini driver")
Signed-off-by: Colin Ian King <colin.k...@canonical.com>


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


---
  drivers/staging/rtlwifi/phydm/phydm_features.h | 2 +-
  drivers/staging/rtlwifi/phydm/phydm_kfree.h| 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtlwifi/phydm/phydm_features.h 
b/drivers/staging/rtlwifi/phydm/phydm_features.h
index 37f6f0cd7235..a12361c6a1a0 100644
--- a/drivers/staging/rtlwifi/phydm/phydm_features.h
+++ b/drivers/staging/rtlwifi/phydm/phydm_features.h
@@ -24,7 +24,7 @@
   
*/
  
  #ifndef __PHYDM_FEATURES_H__

-#define __PHYDM_FEATURES
+#define __PHYDM_FEATURES_H__
  
  /*phydm debyg report & tools*/
  
diff --git a/drivers/staging/rtlwifi/phydm/phydm_kfree.h b/drivers/staging/rtlwifi/phydm/phydm_kfree.h

index 1ee60059afc1..2c6b0a48e76e 100644
--- a/drivers/staging/rtlwifi/phydm/phydm_kfree.h
+++ b/drivers/staging/rtlwifi/phydm/phydm_kfree.h
@@ -24,7 +24,7 @@
   
*/
  
  #ifndef __PHYDMKFREE_H__

-#define __PHYDKFREE_H__
+#define __PHYDKKFREE_H__
  
  #define KFREE_VERSION "1.0"
  



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH-next] staging: rtl8188eu: Remove unneeded cast

[Larry Finger]

On 02/20/2018 10:37 AM, Christopher Diaz Riveros wrote:

Fix Coccinelle alert:

drivers/staging//rtl8188eu/os_dep/usb_intf.c:336:13-27: WARNING: casting value 
returned by memory allocation function to (struct adapter *) is useless.

This issue was detected by using the Coccinelle software.

Signed-off-by: Christopher Diaz Riveros <chris...@gentoo.org>


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



---
  drivers/staging/rtl8188eu/os_dep/usb_intf.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c 
b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
index 32c7225a831e..127ecf896fc9 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
@@ -333,7 +333,7 @@ static struct adapter *rtw_usb_if1_init(struct dvobj_priv 
*dvobj,
struct net_device *pmondev;
int status = _FAIL;
  
-	padapter = (struct adapter *)vzalloc(sizeof(*padapter));

+   padapter = vzalloc(sizeof(*padapter));
if (padapter == NULL)
goto exit;
padapter->dvobj = dvobj;



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: rtlwifi: add identifier names to function definition arguments

[Larry Finger]

On 01/28/2018 08:05 AM, Erik Liodden wrote:

Add identifier names to function definition arguments to comply with
the kernel coding style and the naming convention in the rest of the
file.

Issues found by checkpatch.

Signed-off-by: Erik Liodden 
---


As far as I am concerned, this patch is merely churning the source. Those 
prototypes correctly describe the calling sequence to the compiler, which is all 
that is necessary. Checkpatch is a moving specification. These were NOT 
ERRORS/WARNINGS/CHECKS when this code was first introduced. Why should it be 
made to conform to it now? Besides, you should use checkpatch in an advisory role.


NACK.

Larry


  drivers/staging/rtlwifi/wifi.h | 29 +++--
  1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/rtlwifi/wifi.h b/drivers/staging/rtlwifi/wifi.h
index ca0243f..a23bb17 100644
--- a/drivers/staging/rtlwifi/wifi.h
+++ b/drivers/staging/rtlwifi/wifi.h
@@ -2379,16 +2379,17 @@ struct rtl_hal_usbint_cfg {
u32 rx_max_size;
  
  	/* op - rx */

-   void (*usb_rx_hdl)(struct ieee80211_hw *, struct sk_buff *);
-   void (*usb_rx_segregate_hdl)(struct ieee80211_hw *, struct sk_buff *,
-struct sk_buff_head *);
+   void (*usb_rx_hdl)(struct ieee80211_hw *hw, struct sk_buff *skb);
+   void (*usb_rx_segregate_hdl)(struct ieee80211_hw *hw,
+struct sk_buff *skb,
+struct sk_buff_head *skbh);
  
  	/* tx */

-   void (*usb_tx_cleanup)(struct ieee80211_hw *, struct sk_buff *);
-   int (*usb_tx_post_hdl)(struct ieee80211_hw *, struct urb *,
-  struct sk_buff *);
-   struct sk_buff *(*usb_tx_aggregate_hdl)(struct ieee80211_hw *,
-   struct sk_buff_head *);
+   void (*usb_tx_cleanup)(struct ieee80211_hw *hw, struct sk_buff *skb);
+   int (*usb_tx_post_hdl)(struct ieee80211_hw *hw, struct urb *urb,
+  struct sk_buff *skb);
+   struct sk_buff *(*usb_tx_aggregate_hdl)(struct ieee80211_hw *hw,
+   struct sk_buff_head *skbh);
  
  	/* endpoint mapping */

int (*usb_endpoint_mapping)(struct ieee80211_hw *hw);
@@ -2693,12 +2694,12 @@ struct rtl_btc_ops {
  };
  
  struct rtl_halmac_ops {

-   int (*halmac_init_adapter)(struct rtl_priv *);
-   int (*halmac_deinit_adapter)(struct rtl_priv *);
-   int (*halmac_init_hal)(struct rtl_priv *);
-   int (*halmac_deinit_hal)(struct rtl_priv *);
-   int (*halmac_poweron)(struct rtl_priv *);
-   int (*halmac_poweroff)(struct rtl_priv *);
+   int (*halmac_init_adapter)(struct rtl_priv *rtlpriv);
+   int (*halmac_deinit_adapter)(struct rtl_priv *rtlpriv);
+   int (*halmac_init_hal)(struct rtl_priv *rtlpriv);
+   int (*halmac_deinit_hal)(struct rtl_priv *rtlpriv);
+   int (*halmac_poweron)(struct rtl_priv *rtlpriv);
+   int (*halmac_poweroff)(struct rtl_priv *rtlpriv);
  
  	int (*halmac_phy_power_switch)(struct rtl_priv *rtlpriv, u8 enable);

int (*halmac_set_mac_address)(struct rtl_priv *rtlpriv, u8 hwport,



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 1/2] staging: rtl8712: Cleanup checkpatch issue WARNING:LONG_LINE

[Larry Finger]

On 12/09/2017 05:11 AM, Neil Singh wrote:

Cleanup below checkpatch issue:

WARNING:LONG_LINE: line over 80 characters
1000: FILE: rtl871x_security.c:1000:
+static void construct_ctr_preload(u8 *ctr_preload, sint a4_exists, sint 
qc_exists,

Signed-off-by: Neil Singh 
---
  drivers/staging/rtl8712/rtl871x_security.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/rtl871x_security.c 
b/drivers/staging/rtl8712/rtl871x_security.c
index 56d36f6..77a5f5d 100644
--- a/drivers/staging/rtl8712/rtl871x_security.c
+++ b/drivers/staging/rtl8712/rtl871x_security.c
@@ -997,7 +997,8 @@ static void construct_mic_header2(u8 *mic_header2, u8 
*mpdu, sint a4_exists,
  /* Builds the last MIC header block from*/
  /* header fields.   */
  //
-static void construct_ctr_preload(u8 *ctr_preload, sint a4_exists, sint 
qc_exists,
+static void construct_ctr_preload(u8 *ctr_preload,
+  sint a4_exists, sint qc_exists,
   u8 *mpdu, u8 *pn_vector, sint c)
  {
sint i;



Did you run checkpatch on these patches? My system reports the following:

---
patch_1
---
WARNING: A patch subject line should describe the change not the tool that 
found it
#95:
Subject: [PATCH v2 1/2] staging: rtl8712: Cleanup checkpatch issue 
WARNING:LONG_LINE

CHECK: Alignment should match open parenthesis
#125: FILE: drivers/staging/rtl8712/rtl871x_security.c:1001:
+static void construct_ctr_preload(u8 *ctr_preload,
+  sint a4_exists, sint qc_exists,

---
patch_2
---
WARNING: A patch subject line should describe the change not the tool that 
found it
#95:
Subject: [PATCH v2 2/2] staging: rtl8712: Cleanup checkpatch issues CODE_INDENT 
and LEADING_SPACE


Larry

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[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

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[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

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: rtl8822be: fix missing null check on dev_alloc_skb return

[Larry Finger]

On 11/17/2017 08:50 AM, Colin King wrote:

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

dev_alloc_skb can potentially return NULL, so add a null check to
avoid a null pointer dereference on skb


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

Larry



Detected by CoverityScan, CID#1454558 ("Dereference on null return")

Fixes: 7e5b796cde7e ("staging: r8822be: Add the driver code")
Signed-off-by: Colin Ian King <colin.k...@canonical.com>
---
  drivers/staging/rtlwifi/rtl8822be/fw.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/staging/rtlwifi/rtl8822be/fw.c 
b/drivers/staging/rtlwifi/rtl8822be/fw.c
index f45487122517..483ea85943c3 100644
--- a/drivers/staging/rtlwifi/rtl8822be/fw.c
+++ b/drivers/staging/rtlwifi/rtl8822be/fw.c
@@ -464,6 +464,8 @@ bool rtl8822b_halmac_cb_write_data_rsvd_page(struct 
rtl_priv *rtlpriv, u8 *buf,
int count;
  
  	skb = dev_alloc_skb(size);

+   if (!skb)
+   return false;
memcpy((u8 *)skb_put(skb, size), buf, size);
  
  	if (!_rtl8822be_send_bcn_or_cmd_packet(rtlpriv->hw, skb, BEACON_QUEUE))




___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Searching help for Linux support for RTL8812AU

[Larry Finger]

On 10/24/2017 08:24 AM, txt.file wrote:

Hey Linux wireless list,

A while ago I bought an ALFA Network AWUS036AC[0] which does not yet
seem to be supported in Linux mainline. I would like to get it supported.

The problem is that I have not that much experience doing software
development.

kind regards
txt.file

PS: Please keep me in CC as I am not subscribed to the lists.

[0] https://wikidevi.com/wiki/ALFA_Network_AWUS036AC


I can provide you with an out-of-kernel driver for the RTL8812AU. Please be 
aware that these Realtek USB drivers require many changes before they can be 
accepted into even the staging tree of the kernel. One other consideration is 
that staging drivers should (must?) have a definite path for inclusion into the 
main kernel trees. For wireless, this means using mac80211. For these Realtek 
drivers with their own MAC code, that is a major change.


My suggestion is that you work to get your device handled by driver rtl8xxxu, 
which is in the kernel. I have no idea how much effort that would be, but 
certainly a lot less than converting the Realtek driver.


Larry

PS: Please keep the list in the Cc as I tend to disregard private requests for 
consulting!

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: rtl8822be: fix wrong dma unmap len

[Larry Finger]

On 10/23/2017 04:35 AM, Stanislaw Gruszka wrote:

Patch fixes splat:

r8822be :04:00.0: DMA-API: device driver frees DMA memory with different 
size
[device address=0x78477000] [map size=4096 bytes] [unmap size=424 bytes]

Call Trace:
   debug_dma_unmap_page+0xa5/0xb0
   ? unmap_single+0x2f/0x40
   _rtl8822be_send_bcn_or_cmd_packet+0x2c5/0x300 [r8822be]
   ? _rtl8822be_send_bcn_or_cmd_packet+0x2c5/0x300 [r8822be]
   rtl8822b_halmac_cb_write_data_rsvd_page+0x51/0xc0 [r8822be]
   _halmac_write_data_rsvd_page+0x22/0x30 [r8822be]
   halmac_download_rsvd_page_88xx+0xee/0x1f0 [r8822be]
   halmac_dlfw_to_mem_88xx+0x80/0x120 [r8822be]
   halmac_download_firmware_88xx.part.47+0x477/0x600 [r8822be]
   halmac_download_firmware_88xx+0x32/0x40 [r8822be]
   rtl_halmac_dlfw+0x70/0x120 [r8822be]
   rtl_halmac_init_hal+0x5f/0x1b0 [r8822be]
   rtl8822be_hw_init+0x8a2/0x1040 [r8822be]

Signed-off-by: Stanislaw Gruszka <sgrus...@redhat.com>


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

Thanks Stanislaw. It is amazing how long I can stare at a piece of code without 
seeing the problem.


Larry


---
  drivers/staging/rtlwifi/rtl8822be/fw.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/rtlwifi/rtl8822be/fw.c 
b/drivers/staging/rtlwifi/rtl8822be/fw.c
index 8e24da1..a2cc548 100644
--- a/drivers/staging/rtlwifi/rtl8822be/fw.c
+++ b/drivers/staging/rtlwifi/rtl8822be/fw.c
@@ -419,7 +419,7 @@ static bool _rtl8822be_send_bcn_or_cmd_packet(struct 
ieee80211_hw *hw,
dma_addr = rtlpriv->cfg->ops->get_desc(
hw, (u8 *)pbd_desc, true, HW_DESC_TXBUFF_ADDR);
  
-		pci_unmap_single(rtlpci->pdev, dma_addr, skb->len,

+   pci_unmap_single(rtlpci->pdev, dma_addr, pskb->len,
 PCI_DMA_TODEVICE);
kfree_skb(pskb);
  



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[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

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Two rtlwifi drivers?

[Larry Finger]

On 10/11/2017 08:13 AM, Greg Kroah-Hartman wrote:

On Wed, Oct 11, 2017 at 12:06:00PM +0300, Kalle Valo wrote:

(Sorry for taking so long with the reply, I wanted first to check what
the rtlwifi in staging contains.)

Larry Finger <larry.fin...@lwfinger.net> writes:


On 08/24/2017 07:14 AM, Kalle Valo wrote:

Dan Carpenter <dan.carpen...@oracle.com> writes:


Smatch is distrustful of the "capab" value and marks it as user
controlled.  I think it actually comes from the firmware?  Anyway, I
looked at other drivers and they added a bounds check and it seems like
a harmless thing to have so I have added it here as well.

Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com>

diff --git a/drivers/staging/rtlwifi/base.c b/drivers/staging/rtlwifi/base.c
index f7f207cbaee3..a30b928d5ee1 100644
--- a/drivers/staging/rtlwifi/base.c
+++ b/drivers/staging/rtlwifi/base.c


I'm getting slightly annoyed that we now apparently have two duplicate
rtlwifi drivers (with the same name!) and I'm being spammed by staging
patches. Was this really a smart thing to do? And what will be the
future of these two drivers?

(Of course this is not directed to Dan, he is just fixing bugs found by
smatch, but more like a general question.)


That was the decision that you and Greg made. The version in
wireless-drivers needs many patches to handle the new device. The
progress in applying these to wireless-drivers was very slow for many
reasons. Keeping a single version of that code would have required
coordination between you and Greg, which was discouraged.


I don't recall deciding anything, all I did was asking for more info
about the new code. I was against the idea since I first saw your mail
but I tried to be diplomatic and not shot it down immeadiately. Shows
that diplomacy is not really my thing...

We always take extra measures to avoid forking code, why is it now all
of sudden ok? Also this gives the wrong message to Realtek, and other
vendors, that they can just fork the driver and push all sort of crap to
staging.

So just to make clear to everyone: I think forking drivers like this is
a HORRIBLE idea and I do not want to have anything to do with that. If
schedule goes over quality then a much better approach is to move to the
whole driver to staging than to have duplicated drivers like we have
now.


I think it's horrid too.  But, if no one is able to do the real work
here, we hurt users who just need to use their hardware to get things
done.

And it seems like the company isn't willing to do the real work, so
dumping this in staging is the best we can do at the moment.

However, if this causes you problems, that's not good at all either.
Getting "real" support for this hardware is key, and hopefully can
happen somehow.  But fixing up the staging driver is almost never the
way to do it, as you know :)

So what to do?  Any ideas?  What makes your life easier?  You can just
ignore the staging tree, as it should not affect your portion of the
kernel at all, right?


Greg and Kalle,

We can all agree that this situation is bad; however, several of the points made 
in your E-mails need to be addressed.


First of all, I am not an employee of Realtek, and I have no knowledge of the 
internals of any of their chips. I have never signed a non-disclosure agreement, 
and the only thing that I have received from them are sample chips for testing. 
My main interest is in helping the user experience. As there are a number of 
users with the new RTL8822BE device, that meant getting an in-kernel driver to 
them as soon as possible. As stated earlier, adding this particular device to 
the rtlwifi family involved roughly 120K lines of new code. Given our recent 
experience in getting code accepted into the wireless tree meant that this 
additional code would not have been accepted for many months. For that reason, 
we chose the staging route. It is important that we get this right as Realtek 
tells me that there will be two additional new drivers in the coming 6 months.


As to the convergence of the rtlwifi code between staging and wireless, I 
applied the 40 or 50 patches in my queue to the wireless version to create the 
version that went into staging. If any of the current patches to wireless do not 
seem to be in the staging version, sometimes temporary changes are necessary so 
that the intermediate drivers will build and work. Yes, it is code churn, but 
necessary to keep patches small. In keeping with Kalle's requests, only a 
fraction of those patches have been submitted to him.


My intent is to have the RTL8822BE driver moved from staging to mainline no 
later than 4.17. The affected drivers rtl_pci, rtlwifi and becoex will be moved 
in that order. Of course, the required changes will need to be in wireless 
before staging is changed, which will slow the process. As I see it, the switch 
can only occur with a new version.


My opinion is that the company has gone a long ways toward meeting

Re: [PATCH 1/2] staging: rtlwifi: silence underflow warning

[Larry Finger]

On 09/29/2017 02:51 AM, Dan Carpenter wrote:

I'm not totally certain that it's necessary to put an upper limit here.
I think it happens at lower levels.  But if we are going to do that then
we should have a lower bound as well.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/rtlwifi/core.c b/drivers/staging/rtlwifi/core.c
index 43b8b9efe25f..b55e18304a60 100644
--- a/drivers/staging/rtlwifi/core.c
+++ b/drivers/staging/rtlwifi/core.c
@@ -412,7 +412,8 @@ static void _rtl_add_wowlan_patterns(struct ieee80211_hw 
*hw,
for (i = 0; i < wow->n_patterns; i++) {
memset(_pattern, 0, sizeof(struct rtl_wow_pattern));
memset(mask, 0, MAX_WOL_BIT_MASK_SIZE);
-   if (patterns[i].pattern_len > MAX_WOL_PATTERN_SIZE) {
+   if (patterns[i].pattern_len < 0 ||
+   patterns[i].pattern_len > MAX_WOL_PATTERN_SIZE) {
RT_TRACE(rtlpriv, COMP_POWER, DBG_WARNING,
 "Pattern[%d] is too long\n", i);
continue;


In principle, both patches are correct, but perhaps the debug message should be 
something like

'"Pattern[%d] has bad length of %d\n", i, patterns[i].pattern_len'

Larry

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[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

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 3/3] staging: rtlwifi: remove unused functions

[Larry Finger]

On 09/05/2017 01:53 AM, Tobin C. Harding wrote:

Functions rtl_rfreg_delay() and rtl_bb_delay() are unused within the
driver. Both functions call rtl_addr_delay(), this function is unused
outside of these call sites.The driver (and kernel) code base is cleaner
if unused functions are removed.

Remove unused functions.


While it is true that those routines are unused in the staging instance of 
rtlwifi, they are needed in the copy in drivers/net/wireless/... I would prefer 
to keep the differences between these two versions as small as possible; 
therefore, NACK


Larry
.

---
  drivers/staging/rtlwifi/core.c | 37 -
  drivers/staging/rtlwifi/core.h |  4 
  2 files changed, 41 deletions(-)

diff --git a/drivers/staging/rtlwifi/core.c b/drivers/staging/rtlwifi/core.c
index 6ddf7e8..43b8b9ef 100644
--- a/drivers/staging/rtlwifi/core.c
+++ b/drivers/staging/rtlwifi/core.c
@@ -49,43 +49,6 @@ u8 channel5g_80m[CHANNEL_MAX_NUMBER_5G_80M] = {
42, 58, 106, 122, 138, 155, 171
  };
  
-void rtl_addr_delay(u32 addr)

-{
-   if (addr == 0xfe)
-   mdelay(50);
-   else if (addr == 0xfd)
-   msleep(5);
-   else if (addr == 0xfc)
-   msleep(1);
-   else if (addr == 0xfb)
-   usleep_range(50, 100);
-   else if (addr == 0xfa)
-   usleep_range(5, 10);
-   else if (addr == 0xf9)
-   usleep_range(1, 2);
-}
-
-void rtl_rfreg_delay(struct ieee80211_hw *hw, enum radio_path rfpath, u32 addr,
-u32 mask, u32 data)
-{
-   if (addr >= 0xf9 && addr <= 0xfe) {
-   rtl_addr_delay(addr);
-   } else {
-   rtl_set_rfreg(hw, rfpath, addr, mask, data);
-   udelay(1);
-   }
-}
-
-void rtl_bb_delay(struct ieee80211_hw *hw, u32 addr, u32 data)
-{
-   if (addr >= 0xf9 && addr <= 0xfe) {
-   rtl_addr_delay(addr);
-   } else {
-   rtl_set_bbreg(hw, addr, MASKDWORD, data);
-   udelay(1);
-   }
-}
-
  static void rtl_fw_do_work(const struct firmware *firmware, void *context,
   bool is_wow)
  {
diff --git a/drivers/staging/rtlwifi/core.h b/drivers/staging/rtlwifi/core.h
index 782ac2f..4c2b694 100644
--- a/drivers/staging/rtlwifi/core.h
+++ b/drivers/staging/rtlwifi/core.h
@@ -75,10 +75,6 @@ enum dm_dig_connect_e {
  extern const struct ieee80211_ops rtl_ops;
  void rtl_fw_cb(const struct firmware *firmware, void *context);
  void rtl_wowlan_fw_cb(const struct firmware *firmware, void *context);
-void rtl_addr_delay(u32 addr);
-void rtl_rfreg_delay(struct ieee80211_hw *hw, enum radio_path rfpath, u32 addr,
-u32 mask, u32 data);
-void rtl_bb_delay(struct ieee80211_hw *hw, u32 addr, u32 data);
  bool rtl_cmd_send_packet(struct ieee80211_hw *hw, struct sk_buff *skb);
  bool rtl_btc_status_false(void);
  void rtl_dm_diginit(struct ieee80211_hw *hw, u32 cur_igval);



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/3] staging: rtlwifi: use kcalloc instead of multiply

[Larry Finger]

On 09/05/2017 01:53 AM, Tobin C. Harding wrote:

checkpatch emits multiple warnings of type

WARNING:ALLOC_WITH_MULTIPLY: Prefer kcalloc over kzalloc with multiply

Replace two calls to kzalloc() with calls to kcalloc().


I have previously discussed this kind of change. This recommendation by 
checkpatch.pl is just plain stupid!! NACK.


Larry


---
  drivers/staging/rtlwifi/efuse.c | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtlwifi/efuse.c b/drivers/staging/rtlwifi/efuse.c
index 6d5e657..d74c80d 100644
--- a/drivers/staging/rtlwifi/efuse.c
+++ b/drivers/staging/rtlwifi/efuse.c
@@ -252,12 +252,11 @@ void read_efuse(struct ieee80211_hw *hw, u16 _offset, u16 
_size_byte, u8 *pbuf)
sizeof(u8), GFP_ATOMIC);
if (!efuse_tbl)
return;
-   efuse_word = kzalloc(EFUSE_MAX_WORD_UNIT * sizeof(u16 *), GFP_ATOMIC);
+   efuse_word = kcalloc(EFUSE_MAX_WORD_UNIT, sizeof(u16 *), GFP_ATOMIC);
if (!efuse_word)
goto out;
for (i = 0; i < EFUSE_MAX_WORD_UNIT; i++) {
-   efuse_word[i] = kzalloc(efuse_max_section * sizeof(u16),
-   GFP_ATOMIC);
+   efuse_word[i] = kcalloc(efuse_max_section, sizeof(u16), 
GFP_ATOMIC);
if (!efuse_word[i])
goto done;
}



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[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

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[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

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[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

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: rtl8723bs: remove null check before kfree

[Larry Finger]

On 08/26/2017 03:47 PM, Himanshu Jha wrote:

Kfree on NULL pointer is a no-op and therefore checking is redundant.

Signed-off-by: Himanshu Jha <himanshujha199...@gmail.com>
---


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

For some reason not fully explained, gmail is placing ALL your E-mails in my 
spam folder. You might wish to explore that situation.


Larry


  drivers/staging/rtl8723bs/os_dep/ioctl_linux.c | 18 ++
  1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
index c7bad64..d5e5f83 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
@@ -4120,10 +4120,8 @@ static int rtw_set_wps_beacon(struct net_device *dev, 
struct ieee_param *param,
ie_len = len-12-2;/*  12 = param header, 2:no packed */
  
  
-	if (pmlmepriv->wps_beacon_ie) {

-   kfree(pmlmepriv->wps_beacon_ie);
-   pmlmepriv->wps_beacon_ie = NULL;
-   }
+   kfree(pmlmepriv->wps_beacon_ie);
+   pmlmepriv->wps_beacon_ie = NULL;
  
  	if (ie_len>0) {

pmlmepriv->wps_beacon_ie = rtw_malloc(ie_len);
@@ -4160,10 +4158,8 @@ static int rtw_set_wps_probe_resp(struct net_device 
*dev, struct ieee_param *par
ie_len = len-12-2;/*  12 = param header, 2:no packed */
  
  
-	if (pmlmepriv->wps_probe_resp_ie) {

-   kfree(pmlmepriv->wps_probe_resp_ie);
-   pmlmepriv->wps_probe_resp_ie = NULL;
-   }
+   kfree(pmlmepriv->wps_probe_resp_ie);
+   pmlmepriv->wps_probe_resp_ie = NULL;
  
  	if (ie_len>0) {

pmlmepriv->wps_probe_resp_ie = rtw_malloc(ie_len);
@@ -4195,10 +4191,8 @@ static int rtw_set_wps_assoc_resp(struct net_device 
*dev, struct ieee_param *par
ie_len = len-12-2;/*  12 = param header, 2:no packed */
  
  
-	if (pmlmepriv->wps_assoc_resp_ie) {

-   kfree(pmlmepriv->wps_assoc_resp_ie);
-   pmlmepriv->wps_assoc_resp_ie = NULL;
-   }
+   kfree(pmlmepriv->wps_assoc_resp_ie);
+   pmlmepriv->wps_assoc_resp_ie = NULL;
  
  	if (ie_len>0) {

pmlmepriv->wps_assoc_resp_ie = rtw_malloc(ie_len);



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging rtlwifi efuse fix up a warning kzalloc

[Larry Finger]

On 08/26/2017 08:01 AM, Yurii Pavlenko wrote:

Hello,

I have attached a small patch to fix a warning "Prefer kcalloc over kzalloc with 
multiply"
for efuse.c as part of challenge 10 of Eudyptula.

Best regards,
Yurii Pavlenko


Signed-off-by: Yurii Pavlenko 


Before you waste any more of our time, please read the material about patch 
submission at Documentation/process/submitting-patches.rst in your source tree. 
In its present form, this patch is not usable!


I also disagree with the checkpatch warning. To me, there is no difference 
between specifying the size of the allocation as "EFUSE_MAX_WORD_UNIT, 
sizeof(u16 *)" or "EFUSE_MAX_WORD_UNIT * sizeof(u16 *)". In  fact, the only real 
difference is that the source is ONE character larger with the kzalloc version! 
Is that important? Certainly not to me! One thing that is readily apparent is 
that kzalloc() zeros the allocated space. Of course, so does kcalloc(), but it 
is not apparent from the name.


Most of the checkpatch warnings improve readability of the source, and do find 
real or potential errors. This particular one does not, and I will NACK every 
patch that tries to force code that I maintain to use kcalloc over kzalloc.


Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: r8822be: remove some dead code

[Larry Finger]

On 08/25/2017 03:42 AM, Dan Carpenter wrote:

"hdr" can't be NULL.  We take skb->data which is non-NULL and add an
offset to get "hdr".

Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com>


Thanks. Looks good.

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

Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[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: [PATCH 2/3] staging: rtlwifi: add MAC80211 dependency

[Larry Finger]

On 08/23/2017 08:22 AM, Arnd Bergmann wrote:

Like the version in drivers/net/wireless, this driver requires the
MAC80211 framework, otherwise we run into a link error:

ERROR: "ieee80211_rx_irqsafe" [drivers/staging/rtlwifi/r8822be.ko] undefined!
ERROR: "cfg80211_unlink_bss" [drivers/staging/rtlwifi/r8822be.ko] undefined!
ERROR: "ieee80211_beacon_get_tim" [drivers/staging/rtlwifi/r8822be.ko] 
undefined!
ERROR: "ieee80211_resume_disconnect" [drivers/staging/rtlwifi/r8822be.ko] 
undefined!

This adds the Kconfig dependency for it.

Fixes: 56bde846304e ("staging: r8822be: Add existing rtlwifi and rtl_pci parts for 
new driver")
Signed-off-by: Arnd Bergmann 


Greg,

I lost track of which version of this patch you are taking. The one that Randy 
Dunlap sent that added NETDEVICES was better than the initial version, but this 
one with MAC80211 is the correct one. Randy's patch is in the latest pull I did 
on staging.


Do you want an updated patch?

Larry


---
  drivers/staging/rtlwifi/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtlwifi/Kconfig b/drivers/staging/rtlwifi/Kconfig
index fc482b49f9aa..cb3a29ae764b 100644
--- a/drivers/staging/rtlwifi/Kconfig
+++ b/drivers/staging/rtlwifi/Kconfig
@@ -1,6 +1,6 @@
  config R8822BE
tristate "Realtek RTL8822BE Wireless Network Adapter"
-   depends on PCI && m
+   depends on PCI && MAC80211 && m
select FW_LOADER
---help---
This is the staging driver for Realtek RTL8822BE 802.11ac PCIe



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 3/3] staging: rtlwifi: simplify logical operation

[Larry Finger]

On 08/23/2017 08:22 AM, Arnd Bergmann wrote:

gcc notices a very complicated way to check a value
for being equal to one, and warns about it:

drivers/staging/rtlwifi/btcoexist/halbtc8822b1ant.c: In function 
'halbtc8822b1ant_set_ext_ant_switch':
drivers/staging/rtlwifi/btcoexist/halbtc8822b1ant.c:2105:9: error: '~' on a 
boolean expression [-Werror=bool-operation]
  ~switch_polatiry_inverse :
  ^
drivers/staging/rtlwifi/btcoexist/halbtc8822b1ant.c:2105:9: note: did you mean 
to use logical not?
  ~switch_polatiry_inverse :
  ^

This simplifies this expression to make it more readable
and to make gcc happy.

Fixes: 56bde846304e ("staging: r8822be: Add existing rtlwifi and rtl_pci parts for 
new driver")
Signed-off-by: Arnd Bergmann <a...@arndb.de>


Yes, it should have bee logical not rather than a bitwise inversion. Your 
version is much more readable. In a followup, I will fix the spelling of 
polarity, but yours is fine.


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

Larry


---
  drivers/staging/rtlwifi/btcoexist/halbtc8822b1ant.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/staging/rtlwifi/btcoexist/halbtc8822b1ant.c 
b/drivers/staging/rtlwifi/btcoexist/halbtc8822b1ant.c
index 933d188d52b4..157395b85405 100644
--- a/drivers/staging/rtlwifi/btcoexist/halbtc8822b1ant.c
+++ b/drivers/staging/rtlwifi/btcoexist/halbtc8822b1ant.c
@@ -2101,9 +2101,7 @@ static void halbtc8822b1ant_set_ext_ant_switch(struct 
btc_coexist *btcoexist,
 * 0xcbd[1:0] = 2b'01 => Ant to BTG,
 * 0xcbd[1:0] = 2b'10 => Ant to WLG
 */
-   switch_polatiry_inverse = (rfe_type->ext_ant_switch_ctrl_polarity == 1 ?
-  ~switch_polatiry_inverse :
-  switch_polatiry_inverse);
+   switch_polatiry_inverse = rfe_type->ext_ant_switch_ctrl_polarity == 1;
  
  	switch (pos_type) {

default:



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: r8822be: fix null pointer dereference with a null driver_adapter

[Larry Finger]

On 08/23/2017 10:07 AM, Colin King wrote:

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

The call to _rtl_dbg_trace via macro HALMAC_RT_TRACE will trigger a null
pointer deference on the null driver_adapter.  Fix this by assigning
driver_adapter earlier to halmac_adapter->driver_adapter before the tracing
call so that a non-null driver_adapter is passed instead.

Detected by CoverityScan, CID#1454613 ("Explicit null dereferenced")

Fixes: 938a0447f094 ("staging: r8822be: Add code for halmac sub-driver")
Signed-off-by: Colin Ian King <colin.k...@canonical.com>


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

Thanks,

Larry


---
  drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_api_88xx.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_api_88xx.c 
b/drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_api_88xx.c
index a6c8a87f755f..3a24e33228f8 100644
--- a/drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_api_88xx.c
+++ b/drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_api_88xx.c
@@ -4447,7 +4447,7 @@ halmac_func_p2pps_88xx(struct halmac_adapter 
*halmac_adapter,
  {
u8 h2c_buff[HALMAC_H2C_CMD_SIZE_88XX] = {0};
u16 h2c_seq_mum = 0;
-   void *driver_adapter = NULL;
+   void *driver_adapter = halmac_adapter->driver_adapter;
struct halmac_api *halmac_api;
struct halmac_h2c_header_info h2c_header_info;
enum halmac_ret_status status = HALMAC_RET_SUCCESS;
@@ -4455,7 +4455,6 @@ halmac_func_p2pps_88xx(struct halmac_adapter 
*halmac_adapter,
HALMAC_RT_TRACE(driver_adapter, HALMAC_MSG_H2C, DBG_DMESG,
"[TRACE]halmac_p2pps !!\n");
  
-	driver_adapter = halmac_adapter->driver_adapter;

halmac_api = (struct halmac_api *)halmac_adapter->halmac_api;
  
  	P2PPS_SET_OFFLOAD_EN(h2c_buff, p2p_ps->offload_en);




___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: rtlwifi: check for array overflow

[Larry Finger]

On 08/24/2017 05:08 AM, Dan Carpenter wrote:

Smatch is distrustful of the "capab" value and marks it as user
controlled.  I think it actually comes from the firmware?  Anyway, I
looked at other drivers and they added a bounds check and it seems like
a harmless thing to have so I have added it here as well.

Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com>


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

Thanks,

Larry



diff --git a/drivers/staging/rtlwifi/base.c b/drivers/staging/rtlwifi/base.c
index f7f207cbaee3..a30b928d5ee1 100644
--- a/drivers/staging/rtlwifi/base.c
+++ b/drivers/staging/rtlwifi/base.c
@@ -1414,6 +1414,10 @@ bool rtl_action_proc(struct ieee80211_hw *hw, struct 
sk_buff *skb, u8 is_tx)
  le16_to_cpu(mgmt->u.action.u.addba_req.capab);
tid = (capab &
   IEEE80211_ADDBA_PARAM_TID_MASK) >> 2;
+   if (tid >= MAX_TID_COUNT) {
+   rcu_read_unlock();
+   return true;
+   }
tid_data = _entry->tids[tid];
if (tid_data->agg.rx_agg_state ==
RTL_RX_AGG_START)



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Two rtlwifi drivers?

[Larry Finger]

On 08/24/2017 07:14 AM, Kalle Valo wrote:

Dan Carpenter  writes:


Smatch is distrustful of the "capab" value and marks it as user
controlled.  I think it actually comes from the firmware?  Anyway, I
looked at other drivers and they added a bounds check and it seems like
a harmless thing to have so I have added it here as well.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/rtlwifi/base.c b/drivers/staging/rtlwifi/base.c
index f7f207cbaee3..a30b928d5ee1 100644
--- a/drivers/staging/rtlwifi/base.c
+++ b/drivers/staging/rtlwifi/base.c


I'm getting slightly annoyed that we now apparently have two duplicate
rtlwifi drivers (with the same name!) and I'm being spammed by staging
patches. Was this really a smart thing to do? And what will be the
future of these two drivers?

(Of course this is not directed to Dan, he is just fixing bugs found by
smatch, but more like a general question.)


That was the decision that you and Greg made. The version in wireless-drivers 
needs many patches to handle the new device. The progress in applying these to 
wireless-drivers was very slow for many reasons. Keeping a single version of 
that code would have required coordination between you and Greg, which was 
discouraged.


The future, as stated in the TODO in staging, is to merge all the changes in the 
support drivers into wireless-drivers, and then move the new RTL8822BE driver 
out of staging.


I'm sorry about the fallout affecting you, and I probably should have changed 
the directory names. In any case, ignore any patches that belong in staging. If 
I see any that do not include GregKH in the "To" list, I will NACK them and 
request proper routing.


Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[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 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

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[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 v2 4/4] Staging: rtl8712 : ieee80211.c: fixed camelcase coding style issue

[Larry Finger]

On 06/29/2017 01:43 AM, Jaya Durga wrote:

The following variables and struct name
are renamed to avoid camelcase issue

Configuration to configuration
BeaconPeriod  to beacon_period
DSConfig  to ds_config
ATIMWindowto atim_window
pnic_Config   to pnic_config
FHConfig  to fh_config
HopPatternto hop_pattern
HopSetto hop_set
DwellTime to dwell_time

Signed-off-by: Jaya Durga 


You are doing more than a simple change of camelcase variables. For example

-   *(__le16 *)ie = 
cpu_to_le16((u16)pdev_network->Configuration.BeaconPeriod);
+   *(__le16 *)ie = cpu_to_le16(cfg->beacon_period);

What you did is not wrong as you set "cfg = _network->Configuration", but 
your commit message does not mention such refactoring. For that reason,


NACK

Larry


---
  drivers/staging/rtl8712/ieee80211.c   |  7 ---
  drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 21 ++---
  drivers/staging/rtl8712/rtl871x_ioctl_rtl.c   |  8 
  drivers/staging/rtl8712/rtl871x_mlme.c| 20 ++--
  drivers/staging/rtl8712/wlan_bssdef.h | 16 
  5 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/drivers/staging/rtl8712/ieee80211.c 
b/drivers/staging/rtl8712/ieee80211.c
index f35121e..4e20de6 100644
--- a/drivers/staging/rtl8712/ieee80211.c
+++ b/drivers/staging/rtl8712/ieee80211.c
@@ -168,13 +168,14 @@ int r8712_generate_ie(struct registry_priv *pregistrypriv)
  {
int sz = 0, rateLen;
struct wlan_bssid_ex *pdev_network = >dev_network;
+   struct NDIS_802_11_CONFIGURATION *cfg = _network->configuration;
u8 *ie = pdev_network->IEs;
  
  	/*timestamp will be inserted by hardware*/

sz += 8;
ie += sz;
/*beacon interval : 2bytes*/
-   *(__le16 *)ie = 
cpu_to_le16((u16)pdev_network->Configuration.BeaconPeriod);
+   *(__le16 *)ie = cpu_to_le16(cfg->beacon_period);
sz += 2;
ie += 2;
/*capability info*/
@@ -202,10 +203,10 @@ int r8712_generate_ie(struct registry_priv *pregistrypriv)
  rateLen, pdev_network->rates, );
/*DS parameter set*/
ie = r8712_set_ie(ie, _DSSET_IE_, 1,
- (u8 *)_network->Configuration.DSConfig, );
+ (u8 *)_network->configuration.ds_config, );
/*IBSS Parameter Set*/
ie = r8712_set_ie(ie, _IBSS_PARA_IE_, 2,
- (u8 *)_network->Configuration.ATIMWindow, );
+ (u8 *)_network->configuration.atim_window, );
return sz;
  }
  
diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c

index e30a5be..1711d66 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -150,12 +150,12 @@ static noinline_for_stack char *translate_scan(struct 
_adapter *padapter,
u16 cap, ht_cap = false, mcs_rate;
u8 rssi;
  
-	if ((pnetwork->network.Configuration.DSConfig < 1) ||

-   (pnetwork->network.Configuration.DSConfig > 14)) {
-   if (pnetwork->network.Configuration.DSConfig < 1)
-   pnetwork->network.Configuration.DSConfig = 1;
+   if ((pnetwork->network.configuration.ds_config < 1) ||
+   (pnetwork->network.configuration.ds_config > 14)) {
+   if (pnetwork->network.configuration.ds_config < 1)
+   pnetwork->network.configuration.ds_config = 1;
else
-   pnetwork->network.Configuration.DSConfig = 14;
+   pnetwork->network.configuration.ds_config = 14;
}
/* AP MAC address */
iwe.cmd = SIOCGIWAP;
@@ -212,18 +212,17 @@ static noinline_for_stack char *translate_scan(struct 
_adapter *padapter,
iwe.cmd = SIOCGIWFREQ;
{
/*  check legal index */
-   u8 dsconfig = pnetwork->network.Configuration.DSConfig;
+   u8 dsconfig = pnetwork->network.configuration.ds_config;
  
  		if (dsconfig >= 1 && dsconfig <= sizeof(

ieee80211_wlan_frequencies) / sizeof(long))
iwe.u.freq.m = (s32)(ieee80211_wlan_frequencies[
-  pnetwork->network.Configuration.
-  DSConfig - 1] * 10);
+  dsconfig - 1] * 10);
else
iwe.u.freq.m = 0;
}
iwe.u.freq.e = (s16)1;
-   iwe.u.freq.i = (u8)pnetwork->network.Configuration.DSConfig;
+   iwe.u.freq.i = (u8)pnetwork->network.configuration.ds_config;
start = iwe_stream_add_event(info, start, stop, ,
IW_EV_FREQ_LEN);
/* Add encryption capability */
@@ -699,9 +698,9 @@ static int r8711_wx_get_freq(struct net_device *dev,
return -ENOLINK;
  
  	wrqu->freq.m = 

Re: [PATCH 4/7] staging: rtl8723bs: Move braces to same line as conditional

[Larry Finger]

On 04/27/2017 07:09 PM, Justin Vreeland wrote:

Signed-off-by: Justin Vreeland 
---
 drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c | 15 +--
 drivers/staging/rtl8723bs/hal/rtl8723b_rf6052.c |  9 +++--
 drivers/staging/rtl8723bs/hal/rtl8723bs_xmit.c  |  6 ++
 3 files changed, 10 insertions(+), 20 deletions(-)




Fix the over-long lines and add a commit message.

Larry


diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c 
b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
index 28d1a229c3a6..2838d5cdd1de 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
@@ -385,8 +385,7 @@ s32 PHY_MACConfig8723B(struct adapter *Adapter)
/*  Config MAC */
/*  */
rtStatus = phy_ConfigMACWithParaFile(Adapter, pszMACRegFile);
-   if (rtStatus == _FAIL)
-   {
+   if (rtStatus == _FAIL) {
ODM_ConfigMACWithHeaderFile(>odmpriv);
rtStatus = _SUCCESS;
}
@@ -459,8 +458,7 @@ static int phy_BB8723b_Config_ParaFile(struct adapter 
*Adapter)
Adapter->registrypriv.RegEnableTxPowerLimit == 1 ||
(Adapter->registrypriv.RegEnableTxPowerLimit == 2 && 
pHalData->EEPROMRegulatory == 1)
) {
-   if (PHY_ConfigRFWithPowerLimitTableParaFile(Adapter, 
pszRFTxPwrLmtFile) == _FAIL)
-   {
+   if (PHY_ConfigRFWithPowerLimitTableParaFile(Adapter, 
pszRFTxPwrLmtFile) == _FAIL) {
if (HAL_STATUS_SUCCESS != 
ODM_ConfigRFWithHeaderFile(>odmpriv, CONFIG_RF_TXPWR_LMT, 
(ODM_RF_RADIO_PATH_E)0))
rtStatus = _FAIL;
}
@@ -474,8 +472,7 @@ static int phy_BB8723b_Config_ParaFile(struct adapter 
*Adapter)
/*  */
/*  1. Read PHY_REG.TXT BB INIT!! */
/*  */
-   if (phy_ConfigBBWithParaFile(Adapter, pszBBRegFile, CONFIG_BB_PHY_REG) 
== _FAIL)
-   {
+   if (phy_ConfigBBWithParaFile(Adapter, pszBBRegFile, CONFIG_BB_PHY_REG) 
== _FAIL) {
if (HAL_STATUS_SUCCESS != 
ODM_ConfigBBWithHeaderFile(>odmpriv, CONFIG_BB_PHY_REG))
rtStatus = _FAIL;
}
@@ -491,8 +488,7 @@ static int phy_BB8723b_Config_ParaFile(struct adapter 
*Adapter)
Adapter->registrypriv.RegEnableTxPowerByRate == 1 ||
(Adapter->registrypriv.RegEnableTxPowerByRate == 2 && 
pHalData->EEPROMRegulatory != 2)
) {
-   if (phy_ConfigBBWithPgParaFile(Adapter, pszBBRegPgFile) == 
_FAIL)
-   {
+   if (phy_ConfigBBWithPgParaFile(Adapter, pszBBRegPgFile) == 
_FAIL) {
if (HAL_STATUS_SUCCESS != 
ODM_ConfigBBWithHeaderFile(>odmpriv, CONFIG_BB_PHY_REG_PG))
rtStatus = _FAIL;
}
@@ -514,8 +510,7 @@ static int phy_BB8723b_Config_ParaFile(struct adapter 
*Adapter)
/*  */
/*  2. Read BB AGC table Initialization */
/*  */
-   if (phy_ConfigBBWithParaFile(Adapter, pszAGCTableFile, 
CONFIG_BB_AGC_TAB) == _FAIL)
-   {
+   if (phy_ConfigBBWithParaFile(Adapter, pszAGCTableFile, 
CONFIG_BB_AGC_TAB) == _FAIL) {
if (HAL_STATUS_SUCCESS != 
ODM_ConfigBBWithHeaderFile(>odmpriv, CONFIG_BB_AGC_TAB))
rtStatus = _FAIL;
}
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_rf6052.c 
b/drivers/staging/rtl8723bs/hal/rtl8723b_rf6052.c
index 3a85d0cddfda..b2a31a174a7e 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723b_rf6052.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723b_rf6052.c
@@ -144,15 +144,13 @@ static int phy_RF6052_Config_ParaFile(struct adapter 
*Adapter)
/*Initialize RF fom connfiguration file*/
switch (eRFPath) {
case RF_PATH_A:
-   if (PHY_ConfigRFWithParaFile(Adapter, pszRadioAFile, 
eRFPath) == _FAIL)
-   {
+   if (PHY_ConfigRFWithParaFile(Adapter, pszRadioAFile, 
eRFPath) == _FAIL) {
if (HAL_STATUS_FAILURE == 
ODM_ConfigRFWithHeaderFile(>odmpriv, CONFIG_RF_RADIO, 
(ODM_RF_RADIO_PATH_E)eRFPath))
rtStatus = _FAIL;
}
break;
case RF_PATH_B:
-   if (PHY_ConfigRFWithParaFile(Adapter, pszRadioBFile, 
eRFPath) == _FAIL)
-   {
+   if (PHY_ConfigRFWithParaFile(Adapter, pszRadioBFile, 
eRFPath) == _FAIL) {
if (HAL_STATUS_FAILURE == 
ODM_ConfigRFWithHeaderFile(>odmpriv, CONFIG_RF_RADIO, 
(ODM_RF_RADIO_PATH_E)eRFPath))
rtStatus = _FAIL;
}
@@ -186,8 +184,7 @@ static int phy_RF6052_Config_ParaFile(struct adapter 
*Adapter)
/* 3 Configuration of Tx Power Tracking */
/* 3 

Re: [PATCH 3/7] staging: rtl8723bs: Macros with complex values should be enclosed in parentheses

[Larry Finger]

On 04/27/2017 07:09 PM, Justin Vreeland wrote:

Signed-off-by: Justin Vreeland 
---
 drivers/staging/rtl8723bs/hal/odm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723bs/hal/odm.h 
b/drivers/staging/rtl8723bs/hal/odm.h
index 0b3541a91548..13c4aebd178e 100644
--- a/drivers/staging/rtl8723bs/hal/odm.h
+++ b/drivers/staging/rtl8723bs/hal/odm.h
@@ -209,7 +209,7 @@ typedef struct _ODM_RATE_ADAPTIVE {

 #define AVG_THERMAL_NUM8
 #define IQK_Matrix_REG_NUM 8
-#define IQK_Matrix_Settings_NUM14+24+21 /*  Channels_2_4G_NUM + 
Channels_5G_20M_NUM + Channels_5G */
+#define IQK_Matrix_Settings_NUM(14+24+21) /*  Channels_2_4G_NUM + 
Channels_5G_20M_NUM + Channels_5G */


You should also put spaces around the plus signs, and fix the lines with more 
then 80 columns.


The comment about non-blank commit messages also applies.

Larry



 #defineDM_Type_ByFW0
 #defineDM_Type_ByDriver1



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/7] staging: rtl8723bs: Wrap multi-line macros in do-while loop

[Larry Finger]

On 04/27/2017 07:09 PM, Justin Vreeland wrote:

Signed-off-by: Justin Vreeland 
---


The patch is OK, but most maintainers require a non-blank commit message.

Larry


 drivers/staging/rtl8723bs/hal/odm_debug.h | 80 +--
 1 file changed, 44 insertions(+), 36 deletions(-)

diff --git a/drivers/staging/rtl8723bs/hal/odm_debug.h 
b/drivers/staging/rtl8723bs/hal/odm_debug.h
index a89690ea6ba9..f720eafe46fe 100644
--- a/drivers/staging/rtl8723bs/hal/odm_debug.h
+++ b/drivers/staging/rtl8723bs/hal/odm_debug.h
@@ -105,51 +105,59 @@

 #if DBG
 #define ODM_RT_TRACE(pDM_Odm, comp, level, fmt)\
-   if (\
-   (comp & pDM_Odm->DebugComponents) &&\
-   (level <= pDM_Odm->DebugLevel || level == ODM_DBG_SERIOUS)\
-   ) {\
-   RT_PRINTK fmt;\
-   }
+   do {\
+   if (\
+   (comp & pDM_Odm->DebugComponents) &&\
+   (level <= pDM_Odm->DebugLevel || level == 
ODM_DBG_SERIOUS)\
+   ) {\
+   RT_PRINTK fmt;\
+   } \
+   } while (0)

 #define ODM_RT_TRACE_F(pDM_Odm, comp, level, fmt)\
-   if (\
-   (comp & pDM_Odm->DebugComponents) &&\
-   (level <= pDM_Odm->DebugLevel)\
-   ) {\
-   RT_PRINTK fmt;\
-   }
+   do {\
+   if (\
+   (comp & pDM_Odm->DebugComponents) &&\
+   (level <= pDM_Odm->DebugLevel)\
+   ) {\
+   RT_PRINTK fmt;\
+   } \
+   } while (0)

 #define ODM_RT_ASSERT(pDM_Odm, expr, fmt)\
-   if (!expr) {\
-   DbgPrint("Assertion failed! %s at ..\n", #expr);\
-   DbgPrint(\
-   "  ..%s,%s, line =%d\n",\
-   __FILE__,\
-   __func__,\
-   __LINE__\
-   );\
-   RT_PRINTK fmt;\
-   ASSERT(false);\
-   }
+   do {\
+   if (!expr) {\
+   DbgPrint("Assertion failed! %s at ..\n", #expr);\
+   DbgPrint(\
+   "  ..%s,%s, line =%d\n",\
+   __FILE__,\
+   __func__,\
+   __LINE__\
+   );\
+   RT_PRINTK fmt;\
+   ASSERT(false);\
+   } \
+   } while (0)
 #define ODM_dbg_enter() { DbgPrint("==> %s\n", __func__); }
 #define ODM_dbg_exit() { DbgPrint("<== %s\n", __func__); }
 #define ODM_dbg_trace(str) { DbgPrint("%s:%s\n", __func__, str); }

 #define ODM_PRINT_ADDR(pDM_Odm, comp, level, title_str, ptr)\
-   if (\
-   (comp & pDM_Odm->DebugComponents) &&\
-   (level <= pDM_Odm->DebugLevel)\
-   ) {\
-   int __i;\
-   u8 *__ptr = (u8 *)ptr;\
-   DbgPrint("[ODM] ");\
-   DbgPrint(title_str);\
-   DbgPrint(" ");\
-   for (__i = 0; __i < 6; __i++)\
-   DbgPrint("%02X%s", __ptr[__i], (__i == 5) ? "" : "-");\
-   DbgPrint("\n");\
-   }
+   do {\
+   if (\
+   (comp & pDM_Odm->DebugComponents) &&\
+   (level <= pDM_Odm->DebugLevel)\
+   ) {\
+   int __i;\
+   u8 *__ptr = (u8 *)ptr;\
+   DbgPrint("[ODM] ");\
+   DbgPrint(title_str);\
+   DbgPrint(" ");\
+   for (__i = 0; __i < 6; __i++)\
+   DbgPrint("%02X%s", __ptr[__i], (__i == 5) ? "" : 
"-");\
+   DbgPrint("\n");\
+   } \
+   } while (0)
 #else
 #define ODM_RT_TRACE(pDM_Odm, comp, level, fmt)
 #define ODM_RT_TRACE_F(pDM_Odm, comp, level, fmt)



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: rtl8723bs: remove null test before kfree

[Larry Finger]

On 04/10/2017 08:43 AM, Aishwarya Pant wrote:

kfree(..) on a NULL pointer is a no-op; the null test here is redundant.
Detected by coccicheck.

Signed-off-by: Aishwarya Pant <aishp...@gmail.com>


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

Thanks,

Larry


---
 drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c |  6 ++
 drivers/staging/rtl8723bs/hal/sdio_ops.c  |  6 ++
 drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c |  8 ++-
 drivers/staging/rtl8723bs/os_dep/ioctl_linux.c| 26 ++-
 drivers/staging/rtl8723bs/os_dep/xmit_linux.c |  6 ++
 5 files changed, 15 insertions(+), 37 deletions(-)

diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c 
b/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
index d40ad03..910f7fa 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
@@ -995,8 +995,7 @@ if (1) {
rtw_hal_set_hwreg(padapter, HW_VAR_EFUSE_USAGE, (u8 
*)_usage);
}

-   if (efuseTbl)
-   kfree(efuseTbl);
+   kfree(efuseTbl);
 }

 static void hal_ReadEFuse_BT(
@@ -1128,8 +1127,7 @@ static void hal_ReadEFuse_BT(
}

 exit:
-   if (efuseTbl)
-   kfree(efuseTbl);
+   kfree(efuseTbl);
 }

 static void Hal_ReadEFuse(
diff --git a/drivers/staging/rtl8723bs/hal/sdio_ops.c 
b/drivers/staging/rtl8723bs/hal/sdio_ops.c
index cf09a0a..6285b72 100644
--- a/drivers/staging/rtl8723bs/hal/sdio_ops.c
+++ b/drivers/staging/rtl8723bs/hal/sdio_ops.c
@@ -602,8 +602,7 @@ static s32 _sdio_local_read(
if (!err)
memcpy(pbuf, ptmpbuf, cnt);

-   if (ptmpbuf)
-   kfree(ptmpbuf);
+   kfree(ptmpbuf);

return err;
 }
@@ -646,8 +645,7 @@ s32 sdio_local_read(
if (!err)
memcpy(pbuf, ptmpbuf, cnt);

-   if (ptmpbuf)
-   kfree(ptmpbuf);
+   kfree(ptmpbuf);

return err;
 }
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index d2c6604..52aa65b 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -1170,10 +1170,7 @@ static int cfg80211_rtw_add_key(struct wiphy *wiphy, 
struct net_device *ndev,
}

 addkey_end:
-   if (param)
-   {
-   kfree((u8 *)param);
-   }
+   kfree((u8 *)param);

return ret;

@@ -1968,8 +1965,7 @@ static int rtw_cfg80211_set_wpa_ie(struct adapter 
*padapter, u8 *pie, size_t iel
pairwise_cipher, padapter->securitypriv.ndisencryptstatus, 
padapter->securitypriv.ndisauthtype));

 exit:
-   if (buf)
-   kfree(buf);
+   kfree(buf);
if (ret)
_clr_fwstate_(>mlmepriv, WIFI_UNDER_WPS);
return ret;
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
index fe3c42a..e11045f 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
@@ -766,9 +766,7 @@ static int wpa_set_encryption(struct net_device *dev, 
struct ieee_param *param,

 exit:

-   if (pwep) {
-   kfree((u8 *)pwep);
-   }
+   kfree((u8 *)pwep);
return ret;
 }

@@ -926,7 +924,7 @@ static int rtw_set_wpa_ie(struct adapter *padapter, char 
*pie, unsigned short ie

 exit:

-   if (buf) kfree(buf);
+   kfree(buf);

return ret;
 }
@@ -2502,10 +2500,7 @@ static int rtw_wx_set_enc_ext(struct net_device *dev,
ret =  wpa_set_encryption(dev, param, param_len);

 exit:
-   if (param)
-   {
-   kfree((u8 *)param);
-   }
+   kfree((u8 *)param);

return ret;
 }
@@ -4135,11 +4130,7 @@ static int rtw_set_encryption(struct net_device *dev, 
struct ieee_param *param,
}

 exit:
-
-   if (pwep)
-   {
-   kfree((u8 *)pwep);
-   }
+   kfree((u8 *)pwep);

return ret;

@@ -5785,12 +5776,9 @@ static int rtw_ioctl_wext_private(struct net_device 
*dev, union iwreq_data *wrq_
}

 exit:
-   if (input)
-   kfree(input);
-   if (buffer)
-   kfree(buffer);
-   if (output)
-   kfree(output);
+   kfree(input);
+   kfree(buffer);
+   kfree(output);

return err;
 }
diff --git a/drivers/staging/rtl8723bs/os_dep/xmit_linux.c 
b/drivers/staging/rtl8723bs/os_dep/xmit_linux.c
index 66dfec1..7696816 100644
--- a/drivers/staging/rtl8723bs/os_dep/xmit_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/xmit_linux.c
@@ -76,10 +76,8 @@ int rtw_os_xmit_resource_alloc(struct adapter *padapter, 
struct xmit_buf *pxmitb

 void rtw_os_xmit_resource_free(struct adapter *padapter, struct xmit_buf 
*pxmitbuf, u32 free_sz, u8 flag)
 {
-   if (free_sz > 0) {
-   if (pxmitbuf->pallocated_buf)
-   kfr

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


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: rtl8723bs: core: drop unneeded null tests

[Larry Finger]

On 04/08/2017 12:32 PM, Julia Lawall wrote:



On Sat, 8 Apr 2017, Hans de Goede wrote:


Hi Julia,

On 08-04-17 19:10, Julia Lawall wrote:

kfree returns immediately on NULL so the tests are not needed.

Generated by: scripts/coccinelle/free/ifnullfree.cocci

CC: Hans de Goede <hdego...@redhat.com>
Signed-off-by: Julia Lawall <julia.law...@lip6.fr>
Signed-off-by: Fengguang Wu <fengguang...@intel.com>


Thank you for these patches. Larry Finger has just
posted a large cleanup series for the rtl8723bs
driver, which will likely conflict with these.

Can you rebase and resend these patches once Larry's
series has been merged please?


OK, thanks for the update.  There were a bunch of other coccicheck
warnings.  But I will wait for the improved version.


Julia,

Rather than fixing checkpatch or coccicheck problems, my intent is to now strip 
out unneeded code such as the part that handles 5G channels. That should make a 
lot of formatting patches not be needed. I did the Smatch fixes because a number 
of them were potentially able to cause crashes.


As I am not sure how soon I will be doing the next fixes, I will not submit any 
more patches until yours are rebased and merged.


Larry


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[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

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[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

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[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

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel