from:"Larry Finger"

Re: Fix for memory leak in the wireless extensions layer

2018-11-29 Thread Larry Finger


On 11/29/18 6:50 AM, Greg Kroah-Hartman wrote:

On Wed, Oct 31, 2018 at 01:49:21PM -0500, Larry Finger wrote:

Greg,

Is the fix for a memory leak in the wext compat layer queued for stable? It
is in kernel:HEAD as commit 848e616e66d4592fe9afc40743d3504deb7632b4
("cfg80211: fix wext-compat memory leak")

I just receiv3ed a complaint about a leak for a system that is running
Ubuntu's kernel 4.19.


That would be very odd as commit
848e616e66d4592fe9afc40743d3504deb7632b4 is in 4.19, it was in 4.19-rc7.


Unfortunately, this commit has a "fixes" line, but not a Cc for Stable.


It could have gone into the 4.18-stable tree, but that is now
end-of-life, sorry.


Too bad, but thanks for the reply.

Larry

[PATCH 4.20] rtlwifi: Fix leak of skb when processing C2H_BT_INFO

2018-11-17 Thread Larry Finger

With commit 0a9f8f0a1ba9 ("rtlwifi: fix btmpinfo timeout while processing
C2H_BT_INFO"), calling rtl_c2hcmd_enqueue() with rtl_c2h_fast_cmd() true,
the routine returns without freeing that skb, thereby leaking it.

This issue has been discussed at 
https://github.com/lwfinger/rtlwifi_new/issues/401
and the fix tested there.

Fixes: 0a9f8f0a1ba9 ("rtlwifi: fix btmpinfo timeout while processing 
C2H_BT_INFO")
Reported-and-tested-by: Francisco Machado Magalhães Neto 
Cc: Francisco Machado Magalhães Neto 
Cc: Ping-Ke Shih 
Cc: Stable  # 4.18+
Signed-off-by: Larry Finger 
---
 drivers/net/wireless/realtek/rtlwifi/base.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c 
b/drivers/net/wireless/realtek/rtlwifi/base.c
index f4122c8fdd97..ef9b502ce576 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -2289,6 +2289,7 @@ void rtl_c2hcmd_enqueue(struct ieee80211_hw *hw, struct 
sk_buff *skb)
 
if (rtl_c2h_fast_cmd(hw, skb)) {
rtl_c2h_content_parsing(hw, skb);
+   kfree_skb(skb);
return;
}
 
-- 
2.16.4

Re: RTL8188EUS support

2018-11-05 Thread Larry Finger


On 11/5/18 5:37 AM, Menion wrote:

Hi all
I have a question about the support of RTL8188EUS chipset (which I
have in a TpLink 0bda:8179 usb dongle)
This dongle works with the wext staging driver r8188eu driver. Is it
meant to be supported in the rtl2xxx driver?


Assuming that you mean rtl8xxxu, the answer is no. I have no idea what rtl2xxx 
is.

If you want a cfg80211/nl80211 driver rather than the wext-based one, I am 
currently cleaning up a new driver from Realtek with the possibility of 
replacing the one now in staging with a new version. It can be obtained with the 
following command:


git clone https://github.com/lwfinger/rtl8188eu.git -b v5.2.2.4

This driver will definitely handle your device and has pretty good performance. 
Using a local speedtest.net-type web server, I get up to 50 Mbps down and 45 
Mbps up.


The driver is undergoing fairly rapid change, but mostly to remove lots of dead 
code, thus you will not need to pull that often. It will build on any kernel 
from 4.20 back to at least 2.6.13. I am only testing on 4.20-rc1.


Larry

Re: Driver for RealTek RTL8811AU dual-band USB WiFi adapter

2018-11-04 Thread Larry Finger


On 11/4/18 9:43 AM, Chris Ward wrote:
I recently bought one of these 
https://www.amazon.co.uk/gp/product/B07C4JQZSP/ref=oh_aui_detailpage_o01_s01?ie=UTF8=1 
;
a dual-band wifi adapter. It came with source for a Linux driver, which required 
some patching to get it to work with the
4.19 kernel. Can I interest a kernel developer to integrate this into kernel.org 
? It would save me

effort at further patching if someone else kept it current as the kernel 
changes.

The driver from Amazon is here 
https://drive.google.com/open?id=1AYmjFk2l5jTpnAzLPNpetSGefm4khEBi

and my patch is here http://tjcw.freeshell.org/Patches/rawhide-20181031.patch .

The Amazon driver is stated to be GPL, and I am content for my work to be GPL 
also.

If you need further information, please email me (tjcw at cantab.net)


Even though the driver is GPL, it would take roughly 6 months for an experienced 
kernel coder to rewrite the crappy code that Realtek provides, particularly for 
its USB devices, to get it into a form that would be accepted into the kernel. 
If you are offering $10K for the project, you might get some interest. :)


As I offer a number of USB drivers for Realtek USB devices at GitHub, and I keep 
them patched for changes in the kernel API, I might consider adding this one to 
the collection there. It would be useful if someone would provide me with a 
sample device. Without that, I would rely on remote testing. A quick look at 
your patches indicate that you are destroying the ability to build the driver on 
earlier kernels. That is what is done for in-kernel code, but for an external 
driver one needs to keep a lot of flexibility.


Larry

Fix for memory leak in the wireless extensions layer

2018-10-31 Thread Larry Finger


Greg,

Is the fix for a memory leak in the wext compat layer queued for stable? It is 
in kernel:HEAD as commit 848e616e66d4592fe9afc40743d3504deb7632b4 ("cfg80211: 
fix wext-compat memory leak")


I just receiv3ed a complaint about a leak for a system that is running Ubuntu's 
kernel 4.19.


Unfortunately, this commit has a "fixes" line, but not a Cc for Stable.

Larry

Re: [PATCH] mac80211: fix GFP_KERNEL under tasklet context

2018-10-23 Thread Larry Finger


On 10/22/18 10:24 PM, yhchu...@realtek.com wrote:

From: Yan-Hsuan Chuang 

cfg80211_sta_opmode_change_notify needs a gfp_t flag to hint the nl80211
stack when allocating new skb, but it is called under tasklet context
here with GFP_KERNEL and kernel will yield a warning about it.

Fixes: ff84e7bfe176 ("mac80211: Add support to notify ht/vht opmode 
modification.")
Signed-off-by: Yan-Hsuan Chuang 
---


ACKed-by: Larry Finger 

Just in case a "Fixes" is not enough, please add

Cc: Stable  # v4.17+

Larry


  net/mac80211/rx.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 64742f2..03d3964f 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -3028,7 +3028,7 @@ ieee80211_rx_h_action(struct ieee80211_rx_data *rx)
cfg80211_sta_opmode_change_notify(sdata->dev,
  rx->sta->addr,
  _opmode,
- GFP_KERNEL);
+ GFP_ATOMIC);
goto handled;
}
case WLAN_HT_ACTION_NOTIFY_CHANWIDTH: {
@@ -3065,7 +3065,7 @@ ieee80211_rx_h_action(struct ieee80211_rx_data *rx)
cfg80211_sta_opmode_change_notify(sdata->dev,
  rx->sta->addr,
  _opmode,
- GFP_KERNEL);
+ GFP_ATOMIC);
goto handled;
}
default:

Re: [PATCH 01/12] rtwlan: main files

2018-10-04 Thread Larry Finger


On 10/4/18 8:42 AM, Stanislaw Gruszka wrote:

On Thu, Oct 04, 2018 at 03:39:55PM +0300, Kalle Valo wrote:

Can we put the configuration file in the firmware directory?
Should we package them into binary files? Or just put the raw data.

We can test the performance for it. After we got the result, we will make a 
decision
about it. And if we decide to put them in the firmware directory, will send a 
patch.
For now, I think we can just leave them in the .c.


Yes, you could put the configuration files in the firmware directory.
I would put them in binary form, not as text files. That way the size
would be smaller, and it would not be possible to alter them,
particularly if the binary file is checksummed.

It would likely be OK if only the agc table was stored in this way.
That would take away about half of the lines in the 8822b table file.


So what's the worry here? The lines of source code, binary size or what?

  .../net/wireless/realtek/rtw88/rtw8822b_table.c| 20783 +++

Looking at the diffstat rtw8822b_table.c seems to be 20 kLOC, IMHO it's
not that bad as it's just data. But of course I might be missing
something as I haven't checked patches yet.


My concern was it's plenty of redundant data, for example:

 0x81C, 0xFF03,
 0x81C, 0xFE03,
 0x81C, 0xFD020003,
 0x81C, 0xFC040003,
 0x81C, 0xFB060003,
 0x81C, 0xFA080003,
 0x81C, 0xF90A0003,
 0x81C, 0xF80C0003,
 0x81C, 0xF70E0003,
 0x81C, 0xF613,

Approx 1 lines like this, braked by lines like this

 0x9012, 0x, 0x4000, 0x,

in more or less regular way.

Not big deal, but perhaps this could be coded in much more compact way.


What should be the tradeoff between large tables of redundant data and 
complicated generation and interpretation? I think this table should be 
converted to binary in its present form and added to the "firmware", the way 
that is done for b43. That way the source is smaller, and the loading will be 
only a bit more time consuming.


Larry

Re: [RFC v2 00/12] rtw88: mac80211 driver for Realtek 802.11ac wireless network chips

2018-10-03 Thread Larry Finger


On 10/3/18 11:57 AM, Sid Hayn wrote:

On Wed, Oct 3, 2018 at 12:52 PM Larry Finger  wrote:


On 10/3/18 11:15 AM, Sid Hayn wrote:

Is there a public repository where I can track development for this driver?


For the moment, this is it. Once the driver is accepted into the
wireless-drivers-next tree, I will create a new rtw88 branch in
http://github.com/lwfinger.git with this driver to accomodate people that want


I think you lost part of that link.


Yes. http://github.com/lwfinger/rtlwifi_new.git is the correct one.

Re: [RFC v2 00/12] rtw88: mac80211 driver for Realtek 802.11ac wireless network chips

2018-10-03 Thread Larry Finger


On 10/3/18 11:15 AM, Sid Hayn wrote:

Is there a public repository where I can track development for this driver?


For the moment, this is it. Once the driver is accepted into the 
wireless-drivers-next tree, I will create a new rtw88 branch in 
http://github.com/lwfinger.git with this driver to accomodate people that want 
to use the driver with an older kernel.. At the moment, it is still in too much 
of a flux.


Larry

Re: [PATCH 01/12] rtwlan: main files

2018-10-02 Thread Larry Finger

On 10/2/18 9:57 PM, Tony Chuang wrote:

-Original Message-
From: Larry Finger [mailto:larry.fin...@gmail.com] On Behalf Of Larry Finger
Sent: Tuesday, October 02, 2018 11:24 PM
To: Stanislaw Gruszka; Tony Chuang
Cc: kv...@codeaurora.org; linux-wireless@vger.kernel.org; Pkshih; Andy
Huang
Subject: Re: [PATCH 01/12] rtwlan: main files

On 10/2/18 5:29 AM, Stanislaw Gruszka wrote:

On Fri, Sep 28, 2018 at 11:32:41AM +, Tony Chuang wrote:

if (rtw_hci_tx(rtwdev, _info, skb))
dev_kfree_skb_any(skb)

just to remove 'return;' and out label.

OK, but why not use ieee80211_free_txskb, should it be better for

mac80211?

Yes, it is better as it also do some extra thing for dropped frame.

OK, but I think this is needed, our tables have different forms 

Not sure if that is better solution, but could the tables be pre-prarsed
by user-space program and then embed in the driver in ready to send
to the hardware from ?

Also there are lot of redundancy in those tables, for example:

+   0x81C, 0xFF03,
+   0x81C, 0xF503,
+   0x81C, 0xF4020003,
+   0x81C, 0xF3040003,
+   0x81C, 0xF2060003,
+   0x81C, 0xF1080003,
+   0x81C, 0xF00A0003,
+   0x81C, 0xEF0C0003,
+   0x81C, 0xEE0E0003,
+   0x81C, 0xED13,
+   0x81C, 0xEC120003,
+   0x81C, 0xEB140003,
+   0x81C, 0xEA160003,
+   0x81C, 0xE9180003,
+   0x81C, 0xE81A0003,
+   0x81C, 0xE71C0003,
+   0x81C, 0xE61E0003,
+   0x81C, 0xE523,

0x81C and 0003 repeats in many lines.

This seems to be parse data, not that we have to write 0x81C
register many times. Would be possible to remove the redundancy?

No, they cannot be removed, the sequence matters.
And it is really writing to 0x81C ...
It is really magic, I cannot believe to this, too.

This is contradiction for what I asked you before, i.e. doing parsing
in user space, but since we have this parsing mechanism in the driver
perhaps the tables can be coded in some more compact way, for example:

{ prefix, suffix, len, {data} }

{ 0x81C, 0x0003, N ,
{ 0xFF02 , 0xF500 ,  , 0xE520 } }

The rtw8822b_table.c file is quite big.

You might also consider having these tables as a configuration file read from
the firmware directory.

Hi Larry,

Can we put the configuration file in the firmware directory?
Should we package them into binary files? Or just put the raw data.

We can test the performance for it. After we got the result, we will make a 
decision
about it. And if we decide to put them in the firmware directory, will send a 
patch.
For now, I think we can just leave them in the .c.

Yes, you could put the configuration files in the firmware directory. I would 
put them in binary form, not as text files. That way the size would be smaller, 
and it would not be possible to alter them, particularly if the binary file is 
checksummed.

It would likely be OK if only the agc table was stored in this way. That would 
take away about half of the lines in the 8822b table file.

Larry

Re: [PATCH 01/12] rtwlan: main files

2018-10-02 Thread Larry Finger


On 10/2/18 5:29 AM, Stanislaw Gruszka wrote:

On Fri, Sep 28, 2018 at 11:32:41AM +, Tony Chuang wrote:

if (rtw_hci_tx(rtwdev, _info, skb))
dev_kfree_skb_any(skb)

just to remove 'return;' and out label.



OK, but why not use ieee80211_free_txskb, should it be better for mac80211?


Yes, it is better as it also do some extra thing for dropped frame.


OK, but I think this is needed, our tables have different forms 


Not sure if that is better solution, but could the tables be pre-prarsed
by user-space program and then embed in the driver in ready to send
to the hardware from ?

Also there are lot of redundancy in those tables, for example:

+   0x81C, 0xFF03,
+   0x81C, 0xF503,
+   0x81C, 0xF4020003,
+   0x81C, 0xF3040003,
+   0x81C, 0xF2060003,
+   0x81C, 0xF1080003,
+   0x81C, 0xF00A0003,
+   0x81C, 0xEF0C0003,
+   0x81C, 0xEE0E0003,
+   0x81C, 0xED13,
+   0x81C, 0xEC120003,
+   0x81C, 0xEB140003,
+   0x81C, 0xEA160003,
+   0x81C, 0xE9180003,
+   0x81C, 0xE81A0003,
+   0x81C, 0xE71C0003,
+   0x81C, 0xE61E0003,
+   0x81C, 0xE523,

0x81C and 0003 repeats in many lines.

This seems to be parse data, not that we have to write 0x81C
register many times. Would be possible to remove the redundancy?



No, they cannot be removed, the sequence matters.
And it is really writing to 0x81C ...
It is really magic, I cannot believe to this, too.


This is contradiction for what I asked you before, i.e. doing parsing
in user space, but since we have this parsing mechanism in the driver
perhaps the tables can be coded in some more compact way, for example:

{ prefix, suffix, len, {data} }

{ 0x81C, 0x0003, N ,
   { 0xFF02 , 0xF500 ,  , 0xE520 } }

The rtw8822b_table.c file is quite big.


You might also consider having these tables as a configuration file read from 
the firmware directory.


Larry

Re: Problems and suggestions to the kernel module r8723bs

2018-09-30 Thread Larry Finger


On 9/30/18 12:57 PM, Simon Beginn wrote:

Hi Larry,

I experience some other strange behaviors. The chip cant connect to my old ASUS 
router (RT-N12E_B1) and cant even see the mobile hotspot of my smartphone. So, 
logically it cant take the best network, if it doesn't connect to my router or 
my smartphone - even directly lying beside it. I also cant reconnect to my 
test-network. The networks "Gonzales" and "TPC_install*" are both hosted by my 
router.


On 09/28/2018 05:59 PM, Larry Finger wrote:
sudo iw dev wlan0 scan | egrep "associated|SSID|signal" 


Here the requested outputs:

-> Desk
BSS d4:6e:0e:5b:bf:ae(on wlan0) -- associated
     signal: -93.00 dBm
     SSID: Gonzales
     signal: -60.00 dBm
     SSID: Gonzales
     signal: -52.00 dBm
     SSID: Gonzales
     signal: -50.00 dBm
     SSID: TPC_Install

-> Place A (beside an other access point)

BSS d4:6e:0e:5b:bf:ae(on wlan0) -- associated
     signal: -78.00 dBm
     SSID: Gonzales
     signal: -45.00 dBm
     SSID: Gonzales
     signal: -65.00 dBm
     SSID: Gonzales


And here the full output (only for diagnostic reasons) [at my desk]:

BSS d4:6e:0e:5b:bf:ae(on wlan0) -- associated
     TSF: 337615491 usec (0d, 00:05:37)
     freq: 2447
     beacon interval: 100 TUs
     capability: ESS Privacy ShortPreamble ShortSlotTime (0x0431)
     signal: -93.00 dBm
     last seen: 0 ms ago
     SSID: Gonzales
     Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
     DS Parameter set: channel 8
     ERP: 
     Extended supported rates: 24.0 36.0 48.0 54.0
     HT capabilities:
         Capabilities: 0x106e
             HT20/HT40
             SM Power Save disabled
             RX HT20 SGI
             RX HT40 SGI
             No RX STBC
             Max AMSDU length: 3839 bytes
             DSSS/CCK HT40
         Maximum RX AMPDU length 32767 bytes (exponent: 0x002)
         Minimum RX AMPDU time spacing: 16 usec (0x07)
         HT RX MCS rate indexes supported: 0-15
         HT TX MCS rate indexes are undefined
     HT operation:
          * primary channel: 8
          * secondary channel offset: below
          * STA channel width: any
          * RIFS: 0
          * HT protection: no
          * non-GF present: 0
          * OBSS non-GF present: 0
          * dual beacon: 0
          * dual CTS protection: 0
          * STBC beacon: 0
          * L-SIG TXOP Prot: 0
          * PCO active: 0
          * PCO phase: 0
     WPA:     * Version: 1
          * Group cipher: TKIP
          * Pairwise ciphers: TKIP CCMP
          * Authentication suites: PSK
     RSN:     * Version: 1
          * Group cipher: TKIP
          * Pairwise ciphers: TKIP CCMP
          * Authentication suites: PSK
          * Capabilities: 1-PTKSA-RC 1-GTKSA-RC (0x)
     WMM:     * Parameter version 1
          * BE: CW 15-1023, AIFSN 3
          * BK: CW 15-1023, AIFSN 7
          * VI: CW 7-15, AIFSN 2, TXOP 3008 usec
          * VO: CW 3-7, AIFSN 2, TXOP 1504 usec
BSS 30:b5:c2:68:07:2c(on wlan0)
     TSF: 337615505 usec (0d, 00:05:37)
     freq: 2412
     beacon interval: 100 TUs
     capability: ESS Privacy ShortPreamble ShortSlotTime (0x0431)
     signal: -65.00 dBm
     last seen: 0 ms ago
     SSID: Gonzales
     Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
     DS Parameter set: channel 1
     ERP: 
     Extended supported rates: 24.0 36.0 48.0 54.0
     HT capabilities:
         Capabilities: 0x106e
             HT20/HT40
             SM Power Save disabled
             RX HT20 SGI
             RX HT40 SGI
             No RX STBC
             Max AMSDU length: 3839 bytes
             DSSS/CCK HT40
         Maximum RX AMPDU length 32767 bytes (exponent: 0x002)
         Minimum RX AMPDU time spacing: 16 usec (0x07)
         HT RX MCS rate indexes supported: 0-15
         HT TX MCS rate indexes are undefined
     HT operation:
          * primary channel: 1
          * secondary channel offset: above
          * STA channel width: any
          * RIFS: 0
          * HT protection: no
          * non-GF present: 0
          * OBSS non-GF present: 0
          * dual beacon: 0
          * dual CTS protection: 0
          * STBC beacon: 0
          * L-SIG TXOP Prot: 0
          * PCO active: 0
          * PCO phase: 0
     WPA:     * Version: 1
          * Group cipher: TKIP
          * Pairwise ciphers: TKIP CCMP
          * Authentication suites: PSK
     RSN:     * Version: 1
          * Group cipher: TKIP
          * Pairwise ciphers: TKIP CCMP
          * Authentication suites: PSK
          * Capabilities: 1-PTKSA-RC 1-GTKSA-RC (0x)
     WMM:     * Parameter version 1
          * BE: CW 15-1023, AIFSN 3
          * BK: CW 15-1023, AIFSN 7
          * VI: CW 7-15, AIFSN 2, TXOP 3008 usec
          * VO: CW 3-7, AIFSN 2, TXOP 1504 usec
BSS 1c:b7:2c:7c:9b:30(on wlan0)
     TSF: 337615512 usec (0d, 00:05:37)
     freq: 2472
     beacon interval: 100 TUs
     capability: ESS Privacy ShortSlotTime APSD (0x0c1

Re: Problems and suggestions to the kernel module r8723bs

2018-09-28 Thread Larry Finger


On 9/28/18 5:02 AM, Simon Beginn wrote:
That value means that the signal strength is way too low. One other 
possibility is that the chip has retained the setting and is not obeying the 
antenna number command. To check that, create a file (as root) named 
/etc/modprobe.d/50-r8723bs.conf, and add a single line containing "options 
r8723bs rtw_ant_num=2" (without the quotation marks). After that file is 
ready, then do a cold boot so that the chip has been power cycled. Finally, 
redo the signal test. Note: If your patch is applied, the above will not work! 
I've applied my patch and got the following results (btw good idea with the cold 
boot!):


***FILE CREATED***
options rtl8723bs rtw_ant_num=1

***POWEROFF + 2 MINUTES WAITING***

***REBOOT + COMMAND***
sudo iw dev wlan0 scan | egrep "SSID|signal"
-> Desk
     signal: -93.00 dBm
     SSID: Gonzales
     signal: -63.00 dBm
     SSID: Gonzales
     signal: -63.00 dBm
     SSID: Gonzales
     signal: -50.00 dBm
     SSID: TPC_Install
-> Place A
     signal: -93.00 dBm
     SSID: Gonzales
     signal: -45.00 dBm
     SSID: Gonzales
     signal: -62.00 dBm
     SSID: Gonzales
     signal: -64.00 dBm
     SSID: TPC_Install

***FILE MODIFIED***
options rtl8723bs rtw_ant_num=2

***POWEROFF + 2 MINUTES WAITING***

***REBOOT + COMMAND***
sudo iw dev wlan0 scan | egrep "SSID|signal"
-> Desk
     signal: -85.00 dBm
     SSID: Gonzales
     signal: -64.00 dBm
     SSID: Gonzales
     signal: -65.00 dBm
     SSID: Gonzales
     signal: -48.00 dBm
     SSID: Gonzales
     signal: -48.00 dBm
     SSID: TPC_Install
-> Place A
     signal: -79.00 dBm
     SSID: Gonzales
     signal: -45.00 dBm
     SSID: Gonzales
     signal: -63.00 dBm
     SSID: Gonzales
     signal: -63.00 dBm
     SSID: TPC_Install


ccepted. Even if it had been correctly done, I would have NACKed it.
Sry, would you reformulate this, please? I just can't understand/determine what 
the word "NACKed" means in this situation (Neither google or the raw translation 
helps me).




I do not think that changing rtw_ant_num made any difference. In each location, 
both tests had one AP with a signal greater than -50, which should be strong 
enough. We do not know if the driver is roaming correctly. At each location, is 
that AP with the strongest signal actually the one that is selected? To see 
that, change the scan command to


sudo iw dev wlan0 scan | egrep "associated|SSID|signal"

Check the output to see if the AP with the strongest signal is preceded by a BSS 
line.


Sorry about using jargon that you could not run through a translator. As Bastien 
explained, NACK means to reject a patch. You accept a patch by providing an 
"ACKed-by: name " line. Thus NACK is the opposite.


Larry

Re: [PATCH 01/12] rtwlan: main files

2018-09-27 Thread Larry Finger


On 9/27/18 8:50 AM, Stanislaw Gruszka wrote:
--snip




+#define BIT_LEN_MASK_32(__bitlen) (0x >> (32 - (__bitlen)))
+#define BIT_OFFSET_LEN_MASK_32(__bitoffset, __bitlen)  
\
+   (BIT_LEN_MASK_32(__bitlen) << (__bitoffset))
+#define LE_P4BYTE_TO_HOST_4BYTE(__start) (le32_to_cpu(*((__le32 *)(__start
+#define LE_BITS_CLEARED_TO_4BYTE(__start, __bitoffset, __bitlen)   
\
+   (LE_P4BYTE_TO_HOST_4BYTE(__start) &\
+(~BIT_OFFSET_LEN_MASK_32(__bitoffset, __bitlen)))
+#define LE_BITS_TO_4BYTE(__start, __bitoffset, __bitlen)   
\
+   ((LE_P4BYTE_TO_HOST_4BYTE(__start) >> (__bitoffset)) & \
+BIT_LEN_MASK_32(__bitlen))
+#define SET_BITS_TO_LE_4BYTE(__start, __bitoffset, __bitlen, __value)  
\
+   do {   \
+   *((__le32 *)(__start)) = \
+   cpu_to_le32( \
+   LE_BITS_CLEARED_TO_4BYTE(__start, __bitoffset, __bitlen) | \
+   u32)__value) & BIT_LEN_MASK_32(__bitlen)) << (__bitoffset))\
+   ); \
+   } while (0)


Stanislaw,

I have never loved these macros, and it took a lot of time to get them to be 
endian correct. Could you point me to a method that would overwrite a portion of 
a 32-bit little-endian word that would be correct for both little- and 
big-endian machines? Keep in mind that Kalle hates the use of compile tests on 
__LITTLE_ENDIAN.


Thanks,

Larry

Re: Problems and suggestions to the kernel module r8723bs

2018-09-27 Thread Larry Finger


On 9/27/18 3:33 AM, Simon Beginn wrote:
Use the following command to get the baseline values: 
Done - aand nothing changes (The access point has a strength of -60dB on my 
desk). Well maybe the manufacturer has two antennas builtin. Yay - sorry for that.


That value means that the signal strength is way too low. One other possibility 
is that the chip has retained the setting and is not obeying the antenna number 
command. To check that, create a file (as root) named 
/etc/modprobe.d/50-r8723bs.conf, and add a single line containing "options 
r8723bs rtw_ant_num=2" (without the quotation marks). After that file is ready, 
then do a cold boot so that the chip has been power cycled. Finally, redo the 
signal test. Note: If your patch is applied, the above will not work!





In dmesg
Yep, too late. I've already installed the necessary firmware-files. But I didn't 
wrote it, because the WiFi test wasn't performed until yet.



o the work to get the driver into the condition necessary for it to be in the 
regular tree. 

Did my patch made it?


Your patch was not in the correct format to be accepted. Even if it had been 
correctly done, I would have NACKed it. Given the location of the driver, the 
name is what it should be. Once you, or someone else, has done the many hours to 
put that Realtek crap into proper kernel form, then it could be placed in the 
normal wireless tree and given the name rtl8723bs.


Larry

Re: Problems and suggestions to the kernel module r8723bs

2018-09-26 Thread Larry Finger


On 9/26/18 3:54 AM, Simon Beginn wrote:


The convention has long been to use rxx for the Realtek drivers in 
staging, and rtlxx when they are moved to the regular wireless tree. If 
you want it renamed, then you need to do the work to get the driver into the 
condition necessary for it to be in the regular tree.

I'll see what I can do...

Module parameter ant_sel for rtl8723be and rtl8723de was created because some 
vendors saved a few pennies by only supplying one antenna. The problem is that 
they encoded the WRONG value into the EFUSE, thus code that uses that setting 
(Linux) essentially has no antenna attached. The simple measure of opening the 
case and moving the antenna to the other connector was not viable for warranty 
conditions. In addition, it broke the Windows driver. Do you have a case where 
there is a single antenna for the rtl8723bs, and the PROM shows the wrong 
value? If not, then any antenna number option is not needed. 
Hmm. I cant answer this for sure. The symptoms on my tablet are that the wifi 
chip works OK using Windows (10) and is slow as  under Linux. Under Linux 
the system also didn't connect directly to my router (or any other of its 
guest-networks) and prefers a far away adapter - which are all spread over my 
house. And I think the chip does select the wrong antenna, because my router 
(which the tablet doesn't like) discard all connection attempts if they are too 
weak. The, as mentioned before, other adapters doesn't have such a feature AND 
the wifi works only well if I stand directly beside the "i-take-everything" 
adapters. To make this analysis stand on something: How can I read the PROM 
values? The tablets BIOS is not the key - it only provides the EFI selection.


This driver is not reading any PROM data. It sets the antenna to 1 unless it is 
overridden by the rtw_ant_num option. We need to use signal strengths to decide 
if using ant_num 2 would be better. Use the following command to get the 
baseline values:


sudo iw dev wlan0 scan | egrep "SSID|signal"

Change the wlan0 to the actual device name on your system.

Next, do the command sequence

sudo modprobe -rv r8723bs
sudo modprobe -v r8723bs rtw_ant_num=2

Then repeat the iw command.

If the second set of signals is something like 30 dBm greater, then prepare an 
options file to force antenna #2. Post all the scan data for the AP you want to use.


Larry

Re: [RFC 00/12] rtwlan: mac80211 driver for Realtek 802.11ac wireless network chips

2018-09-24 Thread Larry Finger


On 9/21/18 1:03 AM, yhchu...@realtek.com wrote:

From: Yan-Hsuan Chuang 

This is a new mac80211 driver for Realtek 802.11ac wireless network chips.
rtwlan supports 8822BE and 8822CE chips, and will be able to support
multi-vif combinations in run-time.

For now, only PCI bus is supported, but rtwlan was originally designed
to optionally support three buses includes USB & SDIO. USB & SDIO modules
will soon be supported by rtwlan, with configurable core module to fit
with different bus modules in the same time.

For example, if we choose 8822BE and 8822CU, only PCI & USB modules will
be selected, built, loaded into kernel. This is one of the major
difference from rtlwifi, which can only support specific combinations.

Another difference from rtlwifi is that rtwlan is designed to support
the latest Realtek 802.11ac wireless network chips like 8822B and
8822C series. Compared to the earlier chips supported by rtlwifi like
the 802.11n 8192EE chipset or 802.11ac 8821AE/8812AE chips, newer ICs
have different MAC & PHY settings, such as new multi-port feature for the
MAC layer design and Jaguar2/Jaguar3 PHY layer IPs.

Multi-Port feature is also supported under rtwlan's software architecture.
rtlwifi can only support one vif in the same time, most because of the
hardware limitations for early chips, hence the original design of it
also restricts the usage of multi-vif support, so latest chipset seems not
take advantages from its new MAC engine.

However, rtwlan can run multiple vifs concurrently by holding them on
hardware ports provided by MAC engine, so we can easily start different
roles on a single device.

Based on the reasons mentioned before, we implemented rtwlan. It had many
authors, they are listed here alphabetically:


I have found two problems with the initial code:

1. There is a missing zero entry at the end of the struct pci_device_id.
2. You have no MODULE_DEVICE_TABLE macro call.

The effect is that the device is not autoloaded on boot. The fix is

diff --git a/drivers/net/wireless/realtek/rtwlan/pci.c 
b/drivers/net/wireless/realtek/rtwlan/pci.c

index 2ff5a152d77b..f8b1267520a7 100644
--- a/drivers/net/wireless/realtek/rtwlan/pci.c
+++ b/drivers/net/wireless/realtek/rtwlan/pci.c
@@ -1184,6 +1184,7 @@ static const struct pci_device_id rtw_pci_id_table[] = {
 #ifdef CONFIG_RTWLAN_8822CE
{ RTK_PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0xC822, rtw8822c_hw_spec) },
 #endif
+   {},
 };

 static struct pci_driver rtw_pci_driver = {
@@ -1210,6 +1211,8 @@ struct rtw_hci_ops rtw_pci_ops = {
.check_avail_desc = rtw_pci_check_avail_desc,
 };

+MODULE_DEVICE_TABLE(pci, rtw_pci_id_table);
+
 module_pci_driver(rtw_pci_driver);

 MODULE_AUTHOR("Realtek Corporation");

Larry

Re: [Regression]BCM4312 is broken in kernel 4.18[Root cause found]

2018-09-04 Thread Larry Finger


On 09/04/2018 09:21 AM, prabhu wrote:

Larry,

I didn't find this patch in 4.18.6 stable review mail.
forgot to push or any other reason?


The patch is listed as "Under review".

Larry

Re: [PATCH] b43: Fix regression in kernel 4.18

2018-08-31 Thread Larry Finger


On 08/31/2018 10:38 AM, Kalle Valo wrote:

Larry Finger  wrote:


In commit 66cffd6daab7 ("b43: fix transmit failure when VT is switched"),
a condition is noted where the network controller needs to be reset. Note
that this situation happens when running the open-source firmware
(http://netweb.ing.unibs.it/~openfwwf/), plus a number of other special
conditions.

for a different card model, it is reported that this change breaks
operation running the proprietary firmware
(https://marc.info/?l=linux-wireless=153504546924558=2). Rather
than reverting the previous patch, the code is tweaked to avoid the
reset unless the open-source firmware is being used.

Fixes: 66cffd6daab7 ("b43: fix transmit failure when VT is switched")
Cc: Stable  # 4.18+
Cc: Taketo Kabe 
Reported-and-tested-by: D. Prabhu 
Signed-off-by: Larry Finger 


I'll change the title to something more descriptive:

b43: fix DMA error related regression with proprietary firmware

Does that make sense?


Yes, that is fine.

Larry

[PATCH] b43: Fix regression in kernel 4.18

2018-08-27 Thread Larry Finger

In commit 66cffd6daab7 ("b43: fix transmit failure when VT is switched"),
a condition is noted where the network controller needs to be reset. Note
that this situation happens when running the open-source firmware
(http://netweb.ing.unibs.it/~openfwwf/), plus a number of other special
conditions.

for a different card model, it is reported that this change breaks
operation running the proprietary firmware
(https://marc.info/?l=linux-wireless=153504546924558=2). Rather
than reverting the previous patch, the code is tweaked to avoid the
reset unless the open-source firmware is being used.

Fixes: 66cffd6daab7 ("b43: fix transmit failure when VT is switched")
Cc: Stable  # 4.18+
Cc: Taketo Kabe 
Reported-and-tested-by: D. Prabhu 
Signed-off-by: Larry Finger 
---
 drivers/net/wireless/broadcom/b43/dma.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/b43/dma.c 
b/drivers/net/wireless/broadcom/b43/dma.c
index 6b0e1ec346cb..d46d57b989ae 100644
--- a/drivers/net/wireless/broadcom/b43/dma.c
+++ b/drivers/net/wireless/broadcom/b43/dma.c
@@ -1518,13 +1518,15 @@ void b43_dma_handle_txstatus(struct b43_wldev *dev,
}
} else {
/* More than a single header/data pair were missed.
-* Report this error, and reset the controller to
+* Report this error. If running with open-source
+* firmware, then reset the controller to
 * revive operation.
 */
b43dbg(dev->wl,
   "Out of order TX status report on DMA ring %d. 
Expected %d, but got %d\n",
   ring->index, firstused, slot);
-   b43_controller_restart(dev, "Out of order TX");
+   if (dev->fw.opensource)
+   b43_controller_restart(dev, "Out of order TX");
return;
}
}
-- 
2.18.0

[PATCH] rtl8187: Fix warning generated when strncpy() destination length matches the sixe argument

2018-08-20 Thread Larry Finger

In gcc8, when the 3rd argument (size) of a call to strncpy() matches the
length of the first argument, the compiler warns of the possibility of an
unterminated string. Using strlcpy() forces a null at the end.

Signed-off-by: Larry Finger 
---
 drivers/net/wireless/realtek/rtl818x/rtl8187/leds.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtl818x/rtl8187/leds.c 
b/drivers/net/wireless/realtek/rtl818x/rtl8187/leds.c
index c2d5b495c179..c089540116fa 100644
--- a/drivers/net/wireless/realtek/rtl818x/rtl8187/leds.c
+++ b/drivers/net/wireless/realtek/rtl818x/rtl8187/leds.c
@@ -146,7 +146,7 @@ static int rtl8187_register_led(struct ieee80211_hw *dev,
led->dev = dev;
led->ledpin = ledpin;
led->is_radio = is_radio;
-   strncpy(led->name, name, sizeof(led->name));
+   strlcpy(led->name, name, sizeof(led->name));
 
led->led_dev.name = led->name;
led->led_dev.default_trigger = default_trigger;
-- 
2.18.0

Re: wireless dongle causing entire machine to hang

2018-08-08 Thread Larry Finger


On 08/08/2018 12:58 PM, Randy Oostdyk wrote:

Good day all,

I'm writing to report an issue with the linux kernel, and I'm hoping
this is the right place to report it. (short aside: I tried to ask in
the #linux-wireless IRC channel, but wasn't permitted to speak!)

I'm aware that this is a USB protocol issue, and so this may be the
wrong place to report the bug, but the warning seems to be generated
by the wireless driver, and that appears to be the key issue here.

My USB wifi dongle is on the end of a very long USB cable, and was
connected to a USB hub. On two different occasions (after hours or
days of use), the machine it was attached to (Raspberry Pi 3) stopped
responding. I was unable to SSH in, even over ethernet. After a hard
reboot, I found that the following error was repeated **many thousands
of times per second** in three different log files:

Rpi kernel: [857011.857581] ieee80211 phy1:
rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed
-71

As the machine continued in that state for hours, those log files had
grown to several gigabytes in size each! (/var/log/syslog,
/var/log/kern.log, and /var/log/messages)

It appears to be a very similar (if not same) bug referenced here:
https://www.spinics.net/lists/linux-wireless/msg150555.html

He resolved the "soft lockup" issue with some changes to the driver
(diff included in that thread), so I'm hoping this is the right place
to bring this issue up.

Output of uname -a:
Linux RCBLpi 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux


My browsing shows that error 71 (EPROTO) is some kind of protocol error. Was the 
one you noted the first, or had others been logged? If that was the first, that 
infrequent an error will be hard to find.


I suspect some subtle USB timing issue. Is that very long cable within specs of 
5 meters for USB2 or 3 for USB3? Was the hub powered? If your setup permits, you 
might try with a shorter cable.


Larry

Re: [PATCH v2] rtlwifi: rtl8821ae: fix firmware is not ready to run

2018-06-27 Thread Larry Finger


On 06/27/2018 03:01 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih 

rtl8821ae uses two kinds of firmwares for normal and WoWlan cases, and
each firmware has firmware data buffer and size individually. Original
code always overwrite size of normal firmware rtlpriv->rtlhal.fwsize, and
this mismatch causes firmware checksum error, then firmware can't start.

In this situation, driver gives message "Firmware is not ready to run!".

Fixes: fe89707f0afa ("rtlwifi: rtl8821ae: Simplify loading of WOWLAN firmware")
Signed-off-by: Ping-Ke Shih 
---
v2: fix commit log typo.
---
  drivers/net/wireless/realtek/rtlwifi/core.c | 1 -
  1 file changed, 1 deletion(-)


This change is a good one, and I approve of it. The only change is that it 
should have a Cc to stable as this code was added in kernel 4.0!


Larry

Re: [PATCH] rtlwifi: Fix kernel Oops "Fw download fail!!"

2018-06-21 Thread Larry Finger


On 06/21/2018 02:06 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih 

When connecting to AP, mac80211 asks driver to enter and leave PS quickly,
but driver deinit doesn't wait for delayed work complete when entering PS,
then driver reinit procedure and delay work are running simultaneously.
This will cause unpredictable kernel oops or crash like

rtl8723be: error H2C cmd because of Fw download fail!!!
WARNING: CPU: 3 PID: 159 at drivers/net/wireless/realtek/rtlwifi/
 rtl8723be/fw.c:227 rtl8723be_fill_h2c_cmd+0x182/0x510 [rtl8723be]
CPU: 3 PID: 159 Comm: kworker/3:2 Tainted: G   O 4.16.13-2-ARCH #1
Hardware name: ASUSTeK COMPUTER INC. X556UF/X556UF, BIOS X556UF.406
   10/21/2016
Workqueue: rtl8723be_pci rtl_c2hcmd_wq_callback [rtlwifi]
RIP: 0010:rtl8723be_fill_h2c_cmd+0x182/0x510 [rtl8723be]
RSP: 0018:a6ab01e1bd70 EFLAGS: 00010282
RAX:  RBX: a26069071520 RCX: 0001
RDX: 8001 RSI: 8be70e9c RDI: 
RBP:  R08: 0048 R09: 0348
R10:  R11: 0001 R12: 
R13: a26069071520 R14:  R15: a2607d205f70
FS:  () GS:a26081d8() knlGS:000
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0443b39d3000 CR3: 00037700a005 CR4: 003606e0
Call Trace:
  ? halbtc_send_bt_mp_operation.constprop.17+0xd5/0xe0 [btcoexist]
  ? ex_btc8723b1ant_bt_info_notify+0x3b8/0x820 [btcoexist]
  ? rtl_c2hcmd_launcher+0xab/0x110 [rtlwifi]
  ? process_one_work+0x1d1/0x3b0
  ? worker_thread+0x2b/0x3d0
  ? process_one_work+0x3b0/0x3b0
  ? kthread+0x112/0x130
  ? kthread_create_on_node+0x60/0x60
  ? ret_from_fork+0x35/0x40
Code: 00 76 b4 e9 e2 fe ff ff 4c 89 ee 4c 89 e7 e8 56 22 86 ca e9 5e ...

This patch ensures all delayed works done before entering PS to satisfy
our expectation, so use cancel_delayed_work_sync() instead. An exception
is delayed work ips_nic_off_wq because running task may be itself, so add
a parameter ips_wq to deinit function to handle this case.

This issue is reported and fixed in below threads:
https://github.com/lwfinger/rtlwifi_new/issues/367
https://github.com/lwfinger/rtlwifi_new/issues/366

Tested-by: Evgeny Kapun  # 8723DE
Tested-by: Shivam Kakkar  # 8723BE on 4.18-rc1
Signed-off-by: Ping-Ke Shih 
---
Hi Kalle,

I'd like to queue this fix to 4.18, because kernel oops in users' laptop.


Reviewed by Larry Finger 

Is is sufficient for this patch to go to 4.18, or should it be sent to stable, 
as well.


Larry

Re: rtl8188eu: link is not ready error on lm816

2018-05-15 Thread Larry Finger


On 05/15/2018 02:42 AM, Mylène Josserand wrote:

Hi Larry,

On Mon, 14 May 2018 08:55:21 +0200

I tested it and it was still not working but after searching on the
net, I found other commands to scan for networks.

Instead of using:

# iw wlan0 scan
command failed: No such device (-19)

I used:

# iwlist wlan0 scan

And it is able to scan available networks (even with the 4.14.0 kernel)

I noticed that I got a warning about a recursive locking:

   # iwlist wlan0 scan
   [   87.149647]
   [   87.151176] 
   [   87.156506] WARNING: possible recursive locking detected
   [   87.161843] 4.14.0 #1 Tainted: G C
   [   87.166390] 
   [   87.171721] RTW_CMD_THREAD/278 is trying to acquire lock:
   [   87.177136]  (&(>lock)->rlock){+.-.}, at: [] 
_rtw_alloc_network+0x1c/0xc8 [r8188eu]
   [   87.186763]
   [   87.186763] but task is already holding lock:
   [   87.192615]  (&(>lock)->rlock){+.-.}, at: [] 
rtw_update_scanned_network+0x20/0x240 [r8188eu]
   [   87.202970]
   [   87.202970] other info that might help us debug this:
   [   87.209517]  Possible unsafe locking scenario:
   [   87.209517]
   [   87.215454]CPU0
   [   87.217915]
   [   87.220376]   lock(&(>lock)->rlock);
   [   87.224677]   lock(&(>lock)->rlock);
   [   87.228979]
   [   87.228979]  *** DEADLOCK ***
   [   87.228979]
   [   87.234919]  May be due to missing lock nesting notation
   [   87.234919]
   [   87.241731] 2 locks held by RTW_CMD_THREAD/278:
   [   87.246277]  #0:  (&(&(pmlmepriv->lock))->rlock){+...}, at: 
[] rtw_survey_event_callback+0x84/0x1cc [r8188eu]
   [   87.257417]  #1:  (&(>lock)->rlock){+.-.}, at: [] 
rtw_update_scanned_network+0x20/0x240 [r8188eu]
   [   87.268206]
   [   87.268206] stack backtrace:
   [   87.272593] CPU: 2 PID: 278 Comm: RTW_CMD_THREAD Tainted: G C 
 4.14.0 #1
   [   87.280354] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
   [   87.286896] Backtrace:
   [   87.289390] [] (dump_backtrace) from [] 
(show_stack+0x18/0x1c)
   [   87.296986]  r7: r6:600e0093 r5: r4:c0e771e0
   [   87.302678] [] (show_stack) from [] 
(dump_stack+0xb4/0xe8)
   [   87.309937] [] (dump_stack) from [] 
(__lock_acquire+0x898/0x1968)
   [   87.317796]  r9:c12f1bd8 r8: r7:c1585410 r6:c15d8958 
r5:ecf61ea0 r4:c12f1bd8
   [   87.325568] [] (__lock_acquire) from [] 
(lock_acquire+0x70/0x90)
   [   87.38]  r10:bf08a71c r9:f13a9064 r8:0001 r7:0001 
r6:600e0013 r5:
   [   87.341185]  r4:e000
   [   87.343754] [] (lock_acquire) from [] 
(_raw_spin_lock_bh+0x4c/0x5c)
   [   87.351784]  r8:f13a9000 r7:f13a905c r6:eceffc08 r5:bf0438f8 
r4:f13a903c
   [   87.358816] [] (_raw_spin_lock_bh) from [] 
(_rtw_alloc_network+0x1c/0xc8 [r8188eu])
   [   87.368234]  r5:f13a903c r4:f13a9004
   [   87.372418] [] (_rtw_alloc_network [r8188eu]) from 
[] (rtw_update_scanned_network+0xe8/0x240 [r8188eu])
   [   87.383573]  r5: r4:f13a905c
   [   87.387765] [] (rtw_update_scanned_network [r8188eu]) from 
[] (rtw_survey_event_callback+0x100/0x1cc [r8188eu])
   [   87.399623]  r10:bf08a71c r9:f13aa378 r8:bf03b434 r7:f13a9004 
r6:f13a9000 r5:0800
   [   87.407473]  r4:eceffc08 r3:0043
   [   87.411660] [] (rtw_survey_event_callback [r8188eu]) from 
[] (mlme_evt_hdl+0x64/0xf0 [r8188eu])
   [   87.422127]  r9:f13aa378 r8:bf03b434 r7:ecf36000 r6: 
r5:f13ac000 r4:0008
   [   87.430476] [] (mlme_evt_hdl [r8188eu]) from [] 
(rtw_cmd_thread+0x110/0x2bc [r8188eu])
   [   87.440158]  r7:ecf36000 r6:f13aa3d0 r5:f13ac000 r4:eca20ec0
   [   87.446140] [] (rtw_cmd_thread [r8188eu]) from [] 
(kthread+0x120/0x160)
   [   87.454522]  r10:ece13d34 r9:ecc793b8 r8:f13a9000 r7:ecf36000 
r6:eca20800 r5:
   [   87.462370]  r4:ecc79380
   [   87.464943] [] (kthread) from [] 
(ret_from_fork+0x14/0x2c)
   [   87.472192]  r10: r9: r8: r7: 
r6: r5:c01477f4
   [   87.480039]  r4:eca20800

Otherwise, it works correctly using "iwlist" and not "iw".
I have seen that "iwlist/iwconfig" are now replaced by "iw", right?


Not exactly. The use of "iw" requires that the wireless driver utilize the 
cfg80211 set of commands to control the driver, whereas iwconfig uses the 
wireless extension commands. The version of the driver for RTL8188EU in staging 
does not. If you wish to use iw, then you should implement the driver at 
https://github.com/lwfinger/rtl8188eu.git.



Do you think it would be difficult to update the driver to make it work
with "iw"? If you think it is possible (and not so complicated for a
person that never looked at a wifi driver), we will be pleased to have a
look and contribute to

Re: [PATCH V2 1/2] Revert "ssb: Prevent build of PCI host features in module"

2018-05-11 Thread Larry Finger


On 05/11/2018 05:13 AM, Kalle Valo wrote:

Rafał Miłecki  writes:


On 11 May 2018 at 11:17, Rafał Miłecki  wrote:

From: Rafał Miłecki 

This reverts commit 882164a4a928bcaa53280940436ca476e6b1db8e.

Above commit added "SSB = y" dependency to the wrong symbol
SSB_DRIVER_PCICORE_POSSIBLE and prevented SSB_DRIVER_PCICORE from being
selected when needed. PCI core driver for core running in clienthost
mode is important for bus initialization. It's perfectly valid scenario
to have ssb built as module and use it with buses on PCI cards.

This fixes regression that affected all *module* users with PCI cards.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1572349
Signed-off-by: Rafał Miłecki 


As these patches fix regression/build error, I believe both should get
into 4.17.


How much confidence do we have that we don't need to end up reverting
patch 2 as well? I rather be pushing patch 2 to 4.18 so that there's
more time for testing and waiting for feedback.


Although I do not have the hardware to test the builds, I worked closely with 
the OP in the bug at b.r.c noted above. From that effort, it became clear what 
configuration variables were missing to cause the x86 failures. Patch 2 
satisfies the requirement, and prevents the build problems found by the MIPS 
users. Both patches are needed in 4.17.


Larry

Re: [PATCH 4.17 2/2] ssb: make SSB_PCICORE_HOSTMODE depend on SSB = y

2018-05-10 Thread Larry Finger


On 05/10/2018 06:14 AM, Rafał Miłecki wrote:

From: Rafał Miłecki <ra...@milecki.pl>

SSB_PCICORE_HOSTMODE protects MIPS specific code that calls not exported
symbols pcibios_enable_device and register_pci_controller. This code is
supposed to be compiled only with ssb builtin.

This fixes:
ERROR: "pcibios_enable_device" [drivers/ssb/ssb.ko] undefined!
ERROR: "register_pci_controller" [drivers/ssb/ssb.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:92: __modpost] Error 1

Signed-off-by: Rafał Miłecki <ra...@milecki.pl>


This patch needs a "Reported-by: Matt Redfearn <matt.redfe...@mips.com>".

Applying both patches leads to a correct configuration for PCI. I cannot test on 
my present hardware, but the patches seem to be correct.


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

@Kalle: Please drop my patch from yesterday. This solution is much better.

Larry


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

diff --git a/drivers/ssb/Kconfig b/drivers/ssb/Kconfig
index b3f5cae98ea6..c574dd210500 100644
--- a/drivers/ssb/Kconfig
+++ b/drivers/ssb/Kconfig
@@ -131,7 +131,7 @@ config SSB_DRIVER_PCICORE
  
  config SSB_PCICORE_HOSTMODE

bool "Hostmode support for SSB PCI core"
-   depends on SSB_DRIVER_PCICORE && SSB_DRIVER_MIPS
+   depends on SSB_DRIVER_PCICORE && SSB_DRIVER_MIPS && SSB = y
help
  PCIcore hostmode operation (external PCI bus).

Re: [PATCH] ssb: Fix regression caused by disabling PCI cores on non-MIPS architecture

2018-05-09 Thread Larry Finger


On 05/09/2018 11:57 AM, Jeff Johnson wrote:

On 2018-05-09 09:42, Larry Finger wrote:

Some MPIS-based SoCs use chips driven by b43 for wireless capability.

typo: MPIS=>MIPS


Jeff,

Thanks. I will fix this with V2.

Larry

[PATCH] ssb: Fix regression caused by disabling PCI cores on non-MIPS architecture

2018-05-09 Thread Larry Finger

Some MPIS-based SoCs use chips driven by b43 for wireless capability.
When ssb is configured as a module, build errors happen on these
platforms as described in the commit 882164a4a928 ("ssb: Prevent build
of PCI host features in module"). Unfortunately that change leads to
the removal of code needed for correct operation on platforms that use
PCI cores on the chip bus. The fix allows ssb to be build as a module
for all architectures other than MIPS. This approach is ad-hoc, but it
is the same as done in commit a9e6d44ddecc ("ssb: Do not disable PCI
host on non-Mips").

This problem was reported and discussed in
https://bugzilla.redhat.com/show_bug.cgi?id=1572349.

Fixes: commit 882164a4a928 ("ssb: Prevent build of PCI host features in module")
Tested-by: Matt Redfearn <matt.redfe...@mips.com>
Tested-by: Bruno Wolff III <br...@wolff.to>
Cc: Michael Büsch <m...@bues.ch>
Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---

Kalle,

This patch fixes the regression in 4.17 that was discussed on the
wireless mailing list. I'm not really happy about the ad-hoc rejection
of ssb as a module only on MIPS; however, that seems to be a unique
implementation of this hardware.

Larry

Michael,

Although I think your version of the patch is superior, this is the one that
Matt tested, thus I'm submitting this version.

Larry

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

diff --git a/drivers/ssb/Kconfig b/drivers/ssb/Kconfig
index 9371651d8017..3743533c8057 100644
--- a/drivers/ssb/Kconfig
+++ b/drivers/ssb/Kconfig
@@ -117,7 +117,7 @@ config SSB_SERIAL
 
 config SSB_DRIVER_PCICORE_POSSIBLE
bool
-   depends on SSB_PCIHOST && SSB = y
+   depends on SSB_PCIHOST && (SSB = y || !MIPS)
default y
 
 config SSB_DRIVER_PCICORE
-- 
2.16.3

Regression caused by commit 882164a4a928

2018-05-07 Thread Larry Finger


Matt,

Although commit 882164a4a928 ("ssb: Prevent build of PCI host features in 
module") appeared to be harmless, it leads to complete failure of drivers b43. 
and b43legacy, and likely affects b44 as well. The problem is that 
CONFIG_SSB_PCIHOST is undefined, which prevents the compilation of the code that 
controls the PCI cores of the device. See 
https://bugzilla.redhat.com/show_bug.cgi?id=1572349 for details.


As the underlying errors ("pcibios_enable_device" undefined, and 
"register_pci_controller" undefined) do not appear on the architectures that I 
have tested (x86_64, x86, and ppc), I suspect something in the arch-specific 
code for your setup (MIPS?). As I have no idea on how to fix that problem, would 
the following patch work for you?


diff --git a/drivers/ssb/Kconfig b/drivers/ssb/Kconfig
index 9371651d8017..3743533c8057 100644
--- a/drivers/ssb/Kconfig
+++ b/drivers/ssb/Kconfig
@@ -117,7 +117,7 @@ config SSB_SERIAL

 config SSB_DRIVER_PCICORE_POSSIBLE
bool
-   depends on SSB_PCIHOST && SSB = y
+   depends on SSB_PCIHOST && (SSB = y || !MIPS)
default y

 config SSB_DRIVER_PCICORE

Thanks,

Larry

Re: rtl8188eu: link is not ready error on lm816

2018-05-05 Thread Larry Finger


On 05/04/2018 02:20 PM, Mylène Josserand wrote:

Hello everyone,

I am currently testing a USB Wifi dongle LM816 [1] on a custom platform
based on an IMX6.

My configuration:
kernel from mainline: v4.14
driver: staging R8188EU
firmware: rtl8188eu from linux-firmware, last commit
a3a26af24e29c818ef9b5661856018e21a5c49fb

When I tried to set the wlan interface up, it says that "link is not
ready" and that's all. Because of that, it fails to scan available
networks.

Here are commands used and their output:

# dmesg
[...]
[   14.690152] r8188eu: module is from the staging directory, the
quality is unknown, you have been warned.
[   14.703105] Chip Version
Info: CHIP_8188E_Normal_Chip_TSMC_D_CUT_1T1R_RomVer(0)
[...]

# lsusb
Bus 002 Device 004: ID 0bda:8179  <-- LM816
Bus 002 Device 003: ID 0424:9e00
Bus 002 Device 002: ID 0424:2517
Bus 002 Device 001: ID 1d6b:0002
Bus 001 Device 001: ID 1d6b:0002

# lsmod
Module  Size  Used byTainted: G
dw_hdmi_ahb_audio  16384  0
r8188eu   401408  0
coda   61440  0
imx_vdoa   16384  1 coda
v4l2_mem2mem   24576  1 coda
videobuf2_vmalloc  16384  1 coda
evbug  16384  0

# ifconfig wlan0 up
[  447.639524] MAC Address = 5c:f3:70:3d:5c:71
[  447.653636] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
#
#
# iw wlan0 scan
command failed: No such device (-19)


Does anyone already have this issue with this dongle?
If it is not the case, what is your setup? Which firmware? Which driver?
Any help will be very appreciated.

Thanks in advance,
Best regards,

[1]:
https://www.lm-technologies.com/product/wifi-usb-nano-adapter-150mbps-lm816/


I am running kernel 4.17.0-rc3 under openSUSE Tumbleweed KDE on a Toshiba 
laptop, and controlling networks with NetworkManager. When I plug my dongle in, 
the device connects automatically. The firmware I am using has the following md5sum:


aaef52a47852e599cbff63a3e7f96a94  /lib/firmware/rtlwifi/rtl8188eufw.bin

My dongle shows the following with lsusb:
ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network 
Adapter

Mine shows as an A-cut:
Chip Version Info: CHIP_8188E_Normal_Chip_TSMC_A_CUT_1T1R_RomVer(0)

Yours is a D-cut, but I would not expect any difference from that. The only 
place that information is used is in the log entry shown above.


If you want to try a different driver, there is one at
http://github.com/lwfinger/rtl8188eu.git

Larry

Re: [PATCH v2] rtlwifi: cleanup 8723be ant_sel definition

2018-04-23 Thread Larry Finger


On 04/23/2018 08:47 AM, Kalle Valo wrote:

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


On 04/20/2018 07:01 AM, Kalle Valo wrote:

<pks...@realtek.com> writes:


From: Ping-Ke Shih <pks...@realtek.com>

The module parameter ant_sel is used to control antenna number and path.
There is an existing enum ANT_{X2,X1} defined the antenna number, so
add a new enum ANT_{MAIN,AUX} to make it readable. After this work,
incorrect given values depend on ant_sel were exposed, so refill values
according following definition:
ant_sel   ant_num   ant_path  print_label
   1  ANT_X1ANT_AUX#2
   2  ANT_X2ANT_MAIN   #1
Then, a workaround resulted from the incorrect values in halbtcoutsrc.c was
removed. These is a existing bug in the workaround while ant_sel=2, but the
case is rare use so user is hard to observe this bug.

The experimental results with single antenna connected to specific path
are in following:
ant_sel  ANT_MAIN(#1)  ANT_AUX(#2)
   0-8-62
   1-62   -10
   2-6-60

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>
Cc: Stable <sta...@vger.kernel.org> # 4.7+
Reviewed-by: Larry Finger <larry.fin...@lwfinger.net>
---
v2: Add more description about fixed bugs in end of first paragraph.


Sorry, I still don't understand the bug you are fixing. It shouldn't
take more than one minute to understand a commit log.

I prose that you rewrite the commit log, or at least parts of if it.
When you are describing a bug don't talk about enums or source files,
that's an implementation detail, and instead talk how the bug looks like
from users point of view. For example:

"On HP laptop model 1234 with Realtex 4321 device users are supposed
 to use ant_sel module parameter with value 77 to use the correct
 antenna. But instead rtlwifi incorrectly chose antenna 88 with lower
 transmit power and that caused packet loss. Fix it so that the user
 gets better transmit power and..."

(that's of course all made up information as I don't know what the
actual bug is)

And after that you can write rtlwifi internals in the commit log as much
as you want :) But there needs to be a clear generic description of the
bug first and it needs to understandable in one read.

To make this faster I propose that you send the new commit log as a
reply to this mail and I can then comment faster.


Kalle,

As I have some responsibility in creating this mess, let me try to
write a new commit log. I hope this answers your questions.

Thanks,

Larry



Some HP laptops have only a single wifi antenna. This would not be a
problem except that they were shipped with an incorrectly encoded
EFUSE. It should have been possible to open the computer and transfer
the antenna connection to the other terminal except that such action
might void the warranty, and moving the antenna broke the Windows
driver. The fix was to add a module option that would override the
EFUSE encoding. That was done with commit c18d8f509571 ("rtlwifi:
rtl8723be: Add antenna select module parameter"). There was still a
problem with Bluetooth coexistence, which was addressed with commit
baa170229095 ("rtlwifi: btcoexist: Implement antenna selection").
There were still problems, thus there were commit 0ff78adeef11
("rtlwifi: rtl8723be: fix ant_sel code") and commit 6d6226928369
("rtlwifi: btcoexist: Fix antenna selection code"). Despite all these
attempts at fixing the problem, the code is not yet right. A proper
fix is important as there are now instances of laptops having
RTL8723DE chips with the same problem.


This looks better, thanks.


The module parameter ant_sel is used to control antenna number and path.
At present enum ANT_{X2,X1} is used to define the antenna number, but
this choice is not intuitive, thus change to a new enum ANT_{MAIN,AUX}
to make it more readable. This change showed examples where incorrect
values were used. It was also possible to remove a workaround in
halbtcoutsrc.c

The experimental results with single antenna connected to specific path
are now as follows:
   ant_sel  ANT_MAIN(#1)  ANT_AUX(#2)
  0-8-62
  1-62   -10
  2-6-60


But after reading this I'm still not sure if users are supposed to do
anything. I guess they will continue using existing values with the
ant_sel module parameter and nothing changes in that regard?


If users have two antennas, or a vendor that correctly encoded the EFUSE, this 
patch will change nothing for them. If they have the low-signal problem, then 
their choice of a value for ant_sel should not change. At least we are now sure 
that using that module option will provide correct operation.


Larry

Re: [PATCH v2] rtlwifi: cleanup 8723be ant_sel definition

2018-04-20 Thread Larry Finger


On 04/20/2018 07:01 AM, Kalle Valo wrote:

<pks...@realtek.com> writes:


From: Ping-Ke Shih <pks...@realtek.com>

The module parameter ant_sel is used to control antenna number and path.
There is an existing enum ANT_{X2,X1} defined the antenna number, so
add a new enum ANT_{MAIN,AUX} to make it readable. After this work,
incorrect given values depend on ant_sel were exposed, so refill values
according following definition:
   ant_sel   ant_num   ant_path  print_label
  1  ANT_X1ANT_AUX#2
  2  ANT_X2ANT_MAIN   #1
Then, a workaround resulted from the incorrect values in halbtcoutsrc.c was
removed. These is a existing bug in the workaround while ant_sel=2, but the
case is rare use so user is hard to observe this bug.

The experimental results with single antenna connected to specific path
are in following:
   ant_sel  ANT_MAIN(#1)  ANT_AUX(#2)
  0-8-62
  1-62   -10
  2-6-60

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>
Cc: Stable <sta...@vger.kernel.org> # 4.7+
Reviewed-by: Larry Finger <larry.fin...@lwfinger.net>
---
v2: Add more description about fixed bugs in end of first paragraph.


Sorry, I still don't understand the bug you are fixing. It shouldn't
take more than one minute to understand a commit log.

I prose that you rewrite the commit log, or at least parts of if it.
When you are describing a bug don't talk about enums or source files,
that's an implementation detail, and instead talk how the bug looks like
from users point of view. For example:

   "On HP laptop model 1234 with Realtex 4321 device users are supposed
to use ant_sel module parameter with value 77 to use the correct
antenna. But instead rtlwifi incorrectly chose antenna 88 with lower
transmit power and that caused packet loss. Fix it so that the user
gets better transmit power and..."

(that's of course all made up information as I don't know what the
actual bug is)

And after that you can write rtlwifi internals in the commit log as much
as you want :) But there needs to be a clear generic description of the
bug first and it needs to understandable in one read.

To make this faster I propose that you send the new commit log as a
reply to this mail and I can then comment faster.


Kalle,

As I have some responsibility in creating this mess, let me try to write a new 
commit log. I hope this answers your questions.


Thanks,

Larry



Some HP laptops have only a single wifi antenna. This would not be a problem 
except that they were shipped with an incorrectly encoded EFUSE. It should have 
been possible to open the computer and transfer the antenna connection to the 
other terminal except that such action might void the warranty, and moving the 
antenna broke the Windows driver. The fix was to add a module option that would 
override the EFUSE encoding. That was done with commit c18d8f509571 ("rtlwifi: 
rtl8723be: Add antenna select module parameter"). There was still a problem with 
Bluetooth coexistence, which was addressed with commit baa170229095 ("rtlwifi: 
btcoexist: Implement antenna selection"). There were still problems, thus there 
were commit 0ff78adeef11 ("rtlwifi: rtl8723be: fix ant_sel code") and commit 
6d6226928369 ("rtlwifi: btcoexist: Fix antenna selection code"). Despite all 
these attempts at fixing the problem, the code is not yet right. A proper fix is 
important as there are now instances of laptops having RTL8723DE chips with the 
same problem.


The module parameter ant_sel is used to control antenna number and path.
At present enum ANT_{X2,X1} is used to define the antenna number, but this 
choice is not intuitive, thus change to a new enum ANT_{MAIN,AUX} to make it 
more readable. This change showed examples where incorrect values were used. It 
was also possible to remove a workaround in halbtcoutsrc.c.


The experimental results with single antenna connected to specific path
are now as follows:
  ant_sel  ANT_MAIN(#1)  ANT_AUX(#2)
 0-8-62
 1-62   -10
 2-6-60

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>
Fixes: c18d8f509571 ("rtlwifi: rtl8723be: Add antenna select module parameter")
Fixes: baa170229095 ("rtlwifi: btcoexist: Implement antenna selection")
Fixes: 0ff78adeef11 ("rtlwifi: rtl8723be: fix ant_sel code")
Fixes: 6d6226928369 ("rtlwifi: btcoexist: Fix antenna selection code")
Cc: Stable <sta...@vger.kernel.org> # 4.7+
Reviewed-by: Larry Finger <larry.fin...@lwfinger.net>

Re: iwlwifi-7265-ucode-25.30.14.0.tgz. in Centos 7

2018-04-09 Thread Larry Finger


On 04/08/2018 11:56 PM, Dusan Bruncko wrote:

Dear Larry,

Thank you for your mail. But concerning to "capa flags index 3", I am not sure. 
Please look

following message receiving for command "ps aux",

/usr/bin/abrt-watch-log -F BUG: WARNING: at WARNING:
CPU: INFO: possible recursive locking detected ernel BUG at list_del corruption 
list_add corruption do_IRQ: stack over
flow: ear stack overflow (cur: eneral protection fault nable to handle kernel 
ouble fault: RTNL: assertion failed eek!
  page_mapcount(page) went negative! adness at NETDEV WATCHDOG ysctl table check 
failed : nobody cared IRQ handler type
  mismatch Machine Check Exception: Machine check events logged divide error: 
bounds: coprocessor segment overrun: inva
lid TSS: segment not present: invalid opcode: alignment check: stack segment: 
fpu exception: simd exception: iret exce

ption: /var/log/messages -- /usr/bin/abrt-dump-oops -xtD

I am not software expert, but also looking on message from abrt:

Subject: [abrt] : divide error:  [#1] SMP => look attachment.

Maybe it is direct consequence connected with my wi-fi problem...

Regards,
           Dusan

Larry Finger wrote:

On 04/08/2018 01:58 AM, Dusan Bruncko wrote:

Hello,

Allow me to ask you the following question:

I have laptop with: "02:00.0 Network controller: Intel Corporation Wireless 
7265 (rev 59)".

For this device I found firmware iwlwifi-7265-ucode-25.30.14.0.tgz.

My problem is following: This firmware was created for kernel 4.2+, but I am 
using
Centos 7 with kernels a la 3.10. Therefore I see during booting and after 
switch off some

problematic messages a la:
capa flags index 3 larger than supported by driver  or
failed to remove key (2, ff:ff:ff:ff:ff:ff) from hardware ...

Wi-fi works properly, not to look on the previous messages.

My question to you: do you have in schedule to include proper firmware also for
centos 7/redhat 7?


If your kernel were newer, I would recommend running the backports drivers, 
but I think 3.10 is too old. That said, this code change would not fix the 
"failed to remove key" message as I get that on my 7260 device with kernel 
4.16.0. I think you may safely ignore this one if for no other reason than it 
only happens when the device is being shut down.


If the "capa flags index 3" message is not causing any problems, I would 
ignore it as well.


On this and most mailing lists, one should not top post. It is most inconvenient 
to have to continually scroll up and down to get to your comments while writing 
mine.


In your first posting, you said "Wi-fi works properly". That certainly does not 
imply any problems other than the strange messages in the log. If you are 
getting BUG and/or WARNING dumps, then the output of the dmesg command will list 
the traceback. I do not see any of those. They may be a consequence of using 
such an old kernel. I am only an Intel wifi user, not a developer, and it is 
unlikely that I will be able to fix any of your problems. In any case, you need 
to post the full tracebacks of those BUGS/WARNINGS here. Remember, do not post 
at the top.


Larry

A: Because it puts things out of order.
Q: Why is top posting bad?

Re: iwlwifi-7265-ucode-25.30.14.0.tgz. in Centos 7

2018-04-08 Thread Larry Finger


On 04/08/2018 01:58 AM, Dusan Bruncko wrote:

Hello,

Allow me to ask you the following question:

I have laptop with: "02:00.0 Network controller: Intel Corporation Wireless 7265 
(rev 59)".

For this device I found firmware iwlwifi-7265-ucode-25.30.14.0.tgz.

My problem is following: This firmware was created for kernel 4.2+, but I am 
using
Centos 7 with kernels a la 3.10. Therefore I see during booting and after switch 
off some

problematic messages a la:
capa flags index 3 larger than supported by driver  or
failed to remove key (2, ff:ff:ff:ff:ff:ff) from hardware ...

Wi-fi works properly, not to look on the previous messages.

My question to you: do you have in schedule to include proper firmware also for
centos 7/redhat 7?


If your kernel were newer, I would recommend running the backports drivers, but 
I think 3.10 is too old. That said, this code change would not fix the "failed 
to remove key" message as I get that on my 7260 device with kernel 4.16.0. I 
think you may safely ignore this one if for no other reason than it only happens 
when the device is being shut down.


If the "capa flags index 3" message is not causing any problems, I would ignore 
it as well.


Larry

Re: RTL8723BE performance regression

2018-04-03 Thread Larry Finger


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

On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger <larry.fin...@lwfinger.net> wrote:

(...)


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


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


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



What is the recommended way to monitor the signal strength?


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


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


sudo iw dev  scan | egrep "SSID|signal"

Larry

Re: [PATCH 1/9] rtlwifi: btcoex: Add 8822b1ant coex files

2018-04-03 Thread Larry Finger


On 03/28/2018 02:27 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih 

This file supports 8822be WiFi module with two physical antenna that
means one antenna will share with BT.

Signed-off-by: Ping-Ke Shih 
---
  .../realtek/rtlwifi/btcoexist/halbtc8822b1ant.c| 5303 
  .../realtek/rtlwifi/btcoexist/halbtc8822b1ant.h|  413 ++
  2 files changed, 5716 insertions(+)
  create mode 100644 
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.c
  create mode 100644 
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.h


--snip--


+/*anttenna control by bb mac bt antdiv pta to write 0x4c 0xcb4,0xcbd*/
+
+static
+void hallbtc882b1ant_set_ant_switch(struct btc_coexist *btcoexist,
+   bool force_exec, u8 ctrl_type,
+   u8 pos_type)
+{
+   struct rtl_priv *rtlpriv = btcoexist->adapter;
+   bool switch_polatiry_inverse = false;
+   u8 regval_0xcbd = 0, regval_0x64;
+   u32 u32tmp1 = 0, u32tmp2 = 0, u32tmp3 = 0;
+
+   /* Ext switch buffer mux */
+   btcoexist->btc_write_1byte(btcoexist, 0x974, 0xff);
+   btcoexist->btc_write_1byte_bitmask(btcoexist, 0x1991, 0x3, 0x0);
+   btcoexist->btc_write_1byte_bitmask(btcoexist, 0xcbe, 0x8, 0x0);
+
+   if (!rfe_type->ext_ant_switch_exist)
+   return;
+
+   coex_dm->cur_ext_ant_switch_status = (ctrl_type << 8) + pos_type;
+
+   if (!force_exec) {
+   if (coex_dm->pre_ext_ant_switch_status ==
+   coex_dm->cur_ext_ant_switch_status)
+   return;
+   }
+
+   coex_dm->pre_ext_ant_switch_status = coex_dm->cur_ext_ant_switch_status;
+
+   /* swap control polarity if use different switch control polarity*/
+   /* Normal switch polarity for SPDT,
+* 0xcbd[1:0] = 2b'01 => Ant to BTG, WLA
+* 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);


gcc 7.3.1 reports the following:

  CC [M]  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.o
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.c: In function 
‘hallbtc882b1ant_set_ant_switch’:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.c:2193:9: 
warning: ‘~’ on a boolean expression [-Wbool-operation]

 ~switch_polatiry_inverse :
 ^
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.c:2193:9: note: 
did you mean to use logical not?

 ~switch_polatiry_inverse :
 ^

For a boolean, you should use !bool, not -bool. In addition, it would be better 
to use switch_polarity_inverse, not switch_polatiry_inverse. The same "typo" 
happens in other places in this file. I suggest


sed -i 's/polatiry_inverse/polarity_inverse/g' \
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.c.


+
+   switch (pos_type) {


Larry

Re: RTL8723BE performance regression

2018-04-03 Thread Larry Finger


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

Hello,

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

My first bisect attempt pointed me to the following commit:

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

Which I later found to be already fixed by

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

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

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

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

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

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

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

VersionCommitPingDownUp

v4.11a351e9b1225.445.99
v4.11a351e9b131  17.025.89

v4.13569dbb8174  14.080.00
v4.13569dbb8261  8.41  0.00

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



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


Larry

License info

2018-03-29 Thread Larry Finger


Kalle,

What is your position regarding license information? Should the standard GPL-V2 
boiler plate be replaced with "SPDX-License-Identifier: GPL-2.0" in wireless files?


Thanks,

Larry

Re: [PATCH 1/3] ieee80211: Replace bit shifts with the BIT() macro for WLAN_CAPABILITY_*.

2018-03-24 Thread Larry Finger


On 03/23/2018 11:10 PM, Quytelda Kahja wrote:

It is neater and more consistent with the rest of the document to use the
BIT() macro from 'linux/bitops.h' to define the WLAN_CAPABILITY_*
bitmasks.  In the case of WLAN_CAPABILITY_DMG_TYPE_{IBSS, PBSS, AP},
bitshifting integers by 0 does nothing, so there is no reason to do it in
the code; replace these values with plain integers.

Signed-off-by: Quytelda Kahja 


In the commit message for all of these, what is the "document" to which you 
refer?

I'm not quite sure why you split these changes into 3 parts, but I guess that 
is OK.

Larry

Re: [PATCH v2 12/15] rtlwifi: btcoex: Add 8822b 1ant/2ant coex files

2018-03-19 Thread Larry Finger


On 03/05/2018 07:25 PM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>


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

Re: [PATCH v2 15/15] rtlwifi: btcoex: Add 8822b routine to btc interfaces

2018-03-19 Thread Larry Finger


On 03/05/2018 07:25 PM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

Add 8822b routines to run btcoex algorithm

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


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


---
  .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c   | 100 +
  1 file changed, 100 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index 8b6b07a936f5..e0f9985582f9 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -1441,6 +1441,11 @@ void exhalbtc_power_on_setting(struct btc_coexist 
*btcoexist)
ex_btc8723b2ant_power_on_setting(btcoexist);
else if (btcoexist->board_info.btdm_ant_num == 1)
ex_btc8723b1ant_power_on_setting(btcoexist);
+   } else if (IS_HARDWARE_TYPE_8822B(btcoexist->adapter)) {
+   if (btcoexist->board_info.btdm_ant_num == 1)
+   ex_btc8822b1ant_power_on_setting(btcoexist);
+   else if (btcoexist->board_info.btdm_ant_num == 2)
+   ex_btc8822b2ant_power_on_setting(btcoexist);
}
  }
  
@@ -1454,6 +1459,11 @@ void exhalbtc_pre_load_firmware(struct btc_coexist *btcoexist)

if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8723b2ant_pre_load_firmware(btcoexist);
+   } else if (IS_HARDWARE_TYPE_8822B(btcoexist->adapter)) {
+   if (btcoexist->board_info.btdm_ant_num == 1)
+   ex_btc8822b1ant_pre_load_firmware(btcoexist);
+   else if (btcoexist->board_info.btdm_ant_num == 2)
+   ex_btc8822b2ant_pre_load_firmware(btcoexist);
}
  }
  
@@ -1479,11 +1489,21 @@ void exhalbtc_init_hw_config(struct btc_coexist *btcoexist, bool wifi_only)

} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_init_hwconfig(btcoexist);
+   } else if (IS_HARDWARE_TYPE_8822B(btcoexist->adapter)) {
+   if (btcoexist->board_info.btdm_ant_num == 1)
+   ex_btc8822b1ant_init_hw_config(btcoexist, wifi_only);
+   else if (btcoexist->board_info.btdm_ant_num == 2)
+   ex_btc8822b2ant_init_hw_config(btcoexist, wifi_only);
+
+   halbtc_set_default_port_id_cmd(btcoexist);
+   halbtc_send_wifi_port_id_cmd(btcoexist);
}
  }
  
  void exhalbtc_init_hw_config_wifi_only(struct wifi_only_cfg *wifionly_cfg)

  {
+   if (IS_HARDWARE_TYPE_8822B(wifionly_cfg->adapter))
+   ex_hal8822b_wifi_only_hw_config(wifionly_cfg);
  }
  
  void exhalbtc_init_coex_dm(struct btc_coexist *btcoexist)

@@ -1506,6 +1526,11 @@ void exhalbtc_init_coex_dm(struct btc_coexist *btcoexist)
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_init_coex_dm(btcoexist);
+   } else if (IS_HARDWARE_TYPE_8822B(btcoexist->adapter)) {
+   if (btcoexist->board_info.btdm_ant_num == 1)
+   ex_btc8822b1ant_init_coex_dm(btcoexist);
+   else if (btcoexist->board_info.btdm_ant_num == 2)
+   ex_btc8822b2ant_init_coex_dm(btcoexist);
}
  
  	btcoexist->initilized = true;

@@ -1541,6 +1566,11 @@ void exhalbtc_ips_notify(struct btc_coexist *btcoexist, 
u8 type)
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_ips_notify(btcoexist, ips_type);
+   } else if (IS_HARDWARE_TYPE_8822B(btcoexist->adapter)) {
+   if (btcoexist->board_info.btdm_ant_num == 1)
+   ex_btc8822b1ant_ips_notify(btcoexist, ips_type);
+   else if (btcoexist->board_info.btdm_ant_num == 2)
+   ex_btc8822b2ant_ips_notify(btcoexist, ips_type);
}
  
  	halbtc_normal_low_power(btcoexist);

@@ -1574,6 +1604,11 @@ void exhalbtc_lps_notify(struct btc_coexist *btcoexist, 
u8 type)
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_lps_notify(btcoexist, lps_type);
+   } else if (IS_HARDWARE_TYPE_8822B(btcoexist->adapter)) {
+   if (btcoexist->board_info.btdm_ant_num == 1)
+   ex_btc8822b1ant_lps_notify(btcoexist, lps_type);
+   else if (btcoexist->board_info.btdm_ant_num == 2)
+

Re: [PATCH v2 14/15] rtlwifi: btcoex: Add 8822b to Makefile

2018-03-19 Thread Larry Finger


On 03/05/2018 07:25 PM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

Add btcoex of 8822b to Makefile.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


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


---
  drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile
index d15c58737388..37108c379bd0 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile
@@ -4,6 +4,9 @@ btcoexist-objs :=   halbtc8192e2ant.o   \
halbtc8723b2ant.o   \
halbtc8821a1ant.o   \
halbtc8821a2ant.o   \
+   halbtc8822b1ant.o   \
+   halbtc8822b2ant.o   \
+   halbtc8822bwifionly.o   \
halbtcoutsrc.o  \
rtl_btc.o

Re: [PATCH v2 13/15] rtlwifi: btcoex: Add 8822b header files to precomp.h

2018-03-19 Thread Larry Finger


On 03/05/2018 07:25 PM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

Add 8822b header files to precomp.h for routing functions.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


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


---
  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h
index 02dff4c3f664..858318fd3d63 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h
@@ -48,6 +48,9 @@
  #include "halbtc8723b2ant.h"
  #include "halbtc8821a2ant.h"
  #include "halbtc8821a1ant.h"
+#include "halbtc8822b1ant.h"
+#include "halbtc8822b2ant.h"
+#include "halbtc8822bwifionly.h"
  
  #define GetDefaultAdapter(padapter)	padapter

Re: [PATCH v2 07/15] rtlwifi: btcoex: Add interaction with phydm

2018-03-19 Thread Larry Finger


On 03/05/2018 07:25 PM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

Get phydm's counter and version from the module phydm that is not
submitted so we implement dummy functions.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


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


---
  .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c   | 38 ++
  .../realtek/rtlwifi/btcoexist/halbtcoutsrc.h   |  6 
  2 files changed, 44 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index 1a24aed34094..bfb32d476a70 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -680,6 +680,21 @@ static bool halbtc_get(void *void_btcoexist, u8 get_type, 
void *out_buf)
case BTC_GET_U4_BT_FORBIDDEN_SLOT_VAL:
*u32_tmp = halbtc_get_bt_forbidden_slot_val(btcoexist);
break;
+   case BTC_GET_U4_WIFI_IQK_TOTAL:
+   *u32_tmp =
+   btcoexist->btc_phydm_query_phy_counter(btcoexist,
+  DM_INFO_IQK_ALL);
+   break;
+   case BTC_GET_U4_WIFI_IQK_OK:
+   *u32_tmp =
+   btcoexist->btc_phydm_query_phy_counter(btcoexist,
+  DM_INFO_IQK_OK);
+   break;
+   case BTC_GET_U4_WIFI_IQK_FAIL:
+   *u32_tmp =
+   btcoexist->btc_phydm_query_phy_counter(btcoexist,
+  DM_INFO_IQK_NG);
+   break;
case BTC_GET_U1_WIFI_DOT11_CHNL:
*u8_tmp = rtlphy->current_channel;
break;
@@ -1122,6 +1137,25 @@ static bool halbtc_under_ips(struct btc_coexist 
*btcoexist)
return false;
  }
  
+static

+u32 halbtc_get_phydm_version(void *btc_context)
+{
+   return 0;
+}
+
+static
+void halbtc_phydm_modify_ra_pcr_threshold(void *btc_context,
+ u8 ra_offset_direction,
+ u8 ra_threshold_offset)
+{
+}
+
+static
+u32 halbtc_phydm_query_phy_counter(void *btc_context, enum dm_info_query dm_id)
+{
+   return 0;
+}
+
  static u8 halbtc_get_ant_det_val_from_bt(void *btc_context)
  {
struct btc_coexist *btcoexist = (struct btc_coexist *)btc_context;
@@ -1245,6 +1279,10 @@ bool exhalbtc_initlize_variables(struct rtl_priv 
*rtlpriv)
halbtc_get_bt_coex_supported_feature;
btcoexist->btc_get_bt_coex_supported_version =
halbtc_get_bt_coex_supported_version;
+   btcoexist->btc_get_bt_phydm_version = halbtc_get_phydm_version;
+   btcoexist->btc_phydm_modify_ra_pcr_threshold =
+   halbtc_phydm_modify_ra_pcr_threshold;
+   btcoexist->btc_phydm_query_phy_counter = halbtc_phydm_query_phy_counter;
btcoexist->btc_get_ant_det_val_from_bt = halbtc_get_ant_det_val_from_bt;
btcoexist->btc_get_ble_scan_type_from_bt =
halbtc_get_ble_scan_type_from_bt;
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
index bc2388f3f953..1f12449363c2 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
@@ -730,6 +730,12 @@ struct btc_coexist {
   u32 value);
u32 (*btc_get_bt_coex_supported_feature)(void *btcoexist);
u32 (*btc_get_bt_coex_supported_version)(void *btcoexist);
+   u32 (*btc_get_bt_phydm_version)(void *btcoexist);
+   void (*btc_phydm_modify_ra_pcr_threshold)(void *btcoexist,
+ u8 ra_offset_direction,
+ u8 ra_threshold_offset);
+   u32 (*btc_phydm_query_phy_counter)(void *btcoexist,
+  enum dm_info_query dm_id);
u8 (*btc_get_ant_det_val_from_bt)(void *btcoexist);
u8 (*btc_get_ble_scan_type_from_bt)(void *btcoexist);
u32 (*btc_get_ble_scan_para_from_bt)(void *btcoexist, u8 scan_type);

Re: [PATCH v2 11/15] rtlwifi: btcoex: Add new but dummy definitions introduced by 8822b

2018-03-19 Thread Larry Finger


On 03/05/2018 07:25 PM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

btcoex support multiple platforms, but this drivers doesn't support full
functions yet, so this commit adds dummy definitions.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


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


---
  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 9 +
  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h | 3 +++
  2 files changed, 12 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index 05300b466d34..8b6b07a936f5 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -656,6 +656,9 @@ static bool halbtc_get(void *void_btcoexist, u8 get_type, 
void *out_buf)
case BTC_GET_BL_IS_ASUS_8723B:
*bool_tmp = false;
break;
+   case BTC_GET_BL_RF4CE_CONNECTED:
+   *bool_tmp = false;
+   break;
case BTC_GET_S4_WIFI_RSSI:
*s32_tmp = halbtc_get_wifi_rssi(rtlpriv);
break;
@@ -1141,6 +1144,11 @@ static void halbtc_display_dbg_msg(void *bt_context, u8 
disp_type,
}
  }
  
+static u32 halbtc_get_bt_reg(void *btc_context, u8 reg_type, u32 offset)

+{
+   return 0;
+}
+
  static bool halbtc_under_ips(struct btc_coexist *btcoexist)
  {
struct rtl_priv *rtlpriv = btcoexist->adapter;
@@ -1291,6 +1299,7 @@ bool exhalbtc_initlize_variables(struct rtl_priv *rtlpriv)
btcoexist->btc_get = halbtc_get;
btcoexist->btc_set = halbtc_set;
btcoexist->btc_set_bt_reg = halbtc_set_bt_reg;
+   btcoexist->btc_get_bt_reg = halbtc_get_bt_reg;
  
  	btcoexist->bt_info.bt_ctrl_buf_size = false;

btcoexist->bt_info.agg_buf_size = 5;
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
index 049e92a8afbe..9eae87d19120 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
@@ -338,6 +338,7 @@ enum btc_set_type {
BTC_SET_ACT_GET_BT_RSSI,
BTC_SET_ACT_AGGREGATE_CTRL,
BTC_SET_ACT_ANTPOSREGRISTRY_CTRL,
+   BTC_SET_MIMO_PS_MODE,
  
  	/* for 1Ant **/

/* type bool */
@@ -356,6 +357,7 @@ enum btc_set_type {
BTC_SET_ACT_POST_NORMAL_LPS,
BTC_SET_ACT_INC_FORCE_EXEC_PWR_CMD_CNT,
BTC_SET_ACT_DISABLE_LOW_POWER,
+   BTC_SET_BL_BT_LNA_CONSTRAIN_LEVEL,
BTC_SET_ACT_UPDATE_RAMASK,
BTC_SET_ACT_SEND_MIMO_PS,
/* BT Coex related */
@@ -738,6 +740,7 @@ struct btc_coexist {
  
  	void (*btc_set_bt_reg)(void *btc_context, u8 reg_type, u32 offset,

   u32 value);
+   u32 (*btc_get_bt_reg)(void *btc_context, u8 reg_type, u32 offset);
u32 (*btc_get_bt_coex_supported_feature)(void *btcoexist);
u32 (*btc_get_bt_coex_supported_version)(void *btcoexist);
u32 (*btc_get_bt_phydm_version)(void *btcoexist);

Re: [PATCH v2 10/15] rtlwifi: btcoex: new definitions introduced by 8822be

2018-03-19 Thread Larry Finger


On 03/05/2018 07:25 PM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

New constant and variables definitions are used by btcoex of 8822b, so
this commit add them.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


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


---
  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
index 0a7b09305bc3..049e92a8afbe 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
@@ -62,6 +62,8 @@
  #define   BTC_ANT_PATH_WIFI   0
  #define   BTC_ANT_PATH_BT 1
  #define   BTC_ANT_PATH_PTA2
+#defineBTC_ANT_PATH_WIFI5G 3
+#defineBTC_ANT_PATH_AUTO   4
  /* dual Antenna definition */
  #define   BTC_ANT_WIFI_AT_MAIN0
  #define   BTC_ANT_WIFI_AT_AUX 1
@@ -205,6 +207,7 @@ enum btc_wifi_traffic_dir {
  enum btc_wifi_pnp {
BTC_WIFI_PNP_WAKE_UP = 0x0,
BTC_WIFI_PNP_SLEEP = 0x1,
+   BTC_WIFI_PNP_SLEEP_KEEP_ANT = 0x2,
BTC_WIFI_PNP_MAX
  };
  
@@ -387,6 +390,7 @@ enum btc_notify_type_lps {

  enum btc_notify_type_scan {
BTC_SCAN_FINISH = 0x0,
BTC_SCAN_START = 0x1,
+   BTC_SCAN_START_2G = 0x2,
BTC_SCAN_MAX
  };
  
@@ -561,6 +565,7 @@ struct btc_bt_info {

u16 bt_hci_ver;
u16 bt_real_fw_ver;
u8 bt_fw_ver;
+   u32 bt_get_fw_ver;
  
  	bool bt_disable_low_pwr;
  
@@ -632,6 +637,7 @@ struct btc_bt_link_info {

bool pan_exist;
bool pan_only;
bool slave_role;
+   bool acl_busy;
  };
  
  enum btc_antenna_pos {

Re: [PATCH v2 08/15] rtlwifi: btcoex: Add pre- and post- normal LPS function

2018-03-19 Thread Larry Finger


On 03/05/2018 07:25 PM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

Normal LPS is decomposed into pre- and post- parts, so we can issue H2C
with TDMA parameters in the "critical section" that dirver can't change
LPS state at the moment.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


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


---
  .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c   | 22 ++
  .../realtek/rtlwifi/btcoexist/halbtcoutsrc.h   |  2 ++
  2 files changed, 24 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index bfb32d476a70..0f664a0490a7 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -363,6 +363,22 @@ static void halbtc_normal_lps(struct btc_coexist 
*btcoexist)
}
  }
  
+static void halbtc_pre_normal_lps(struct btc_coexist *btcoexist)

+{
+   struct rtl_priv *rtlpriv = btcoexist->adapter;
+
+   if (btcoexist->bt_info.bt_ctrl_lps) {
+   btcoexist->bt_info.bt_lps_on = false;
+   rtl_lps_leave(rtlpriv->mac80211.hw);
+   }
+}
+
+static void halbtc_post_normal_lps(struct btc_coexist *btcoexist)
+{
+   if (btcoexist->bt_info.bt_ctrl_lps)
+   btcoexist->bt_info.bt_ctrl_lps = false;
+}
+
  static void halbtc_leave_low_power(struct btc_coexist *btcoexist)
  {
  }
@@ -806,6 +822,12 @@ static bool halbtc_set(void *void_btcoexist, u8 set_type, 
void *in_buf)
case BTC_SET_ACT_NORMAL_LPS:
halbtc_normal_lps(btcoexist);
break;
+   case BTC_SET_ACT_PRE_NORMAL_LPS:
+   halbtc_pre_normal_lps(btcoexist);
+   break;
+   case BTC_SET_ACT_POST_NORMAL_LPS:
+   halbtc_post_normal_lps(btcoexist);
+   break;
case BTC_SET_ACT_DISABLE_LOW_POWER:
halbtc_disable_low_power(btcoexist, *bool_tmp);
break;
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
index 1f12449363c2..ad80ec05975e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
@@ -349,6 +349,8 @@ enum btc_set_type {
BTC_SET_ACT_LEAVE_LPS,
BTC_SET_ACT_ENTER_LPS,
BTC_SET_ACT_NORMAL_LPS,
+   BTC_SET_ACT_PRE_NORMAL_LPS,
+   BTC_SET_ACT_POST_NORMAL_LPS,
BTC_SET_ACT_INC_FORCE_EXEC_PWR_CMD_CNT,
BTC_SET_ACT_DISABLE_LOW_POWER,
BTC_SET_ACT_UPDATE_RAMASK,

Re: [PATCH v2 09/15] rtlwifi: btcoex: add assoc type v2 to connection notify

2018-03-19 Thread Larry Finger


On 03/05/2018 07:25 PM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

In connection notify v1, btcoex only need to know start/end association,
and it will discriminate 2G and 5G band in v2.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


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


---
  .../net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c  | 14 +++---
  .../net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h  |  2 ++
  2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index 0f664a0490a7..05300b466d34 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -1610,7 +1610,8 @@ void exhalbtc_scan_notify_wifi_only(struct wifi_only_cfg 
*wifionly_cfg,
  
  void exhalbtc_connect_notify(struct btc_coexist *btcoexist, u8 action)

  {
-   u8 asso_type;
+   u8 asso_type, asso_type_v2;
+   bool wifi_under_5g;
  
  	if (!halbtc_is_bt_coexist_available(btcoexist))

return;
@@ -1618,10 +1619,17 @@ void exhalbtc_connect_notify(struct btc_coexist 
*btcoexist, u8 action)
if (btcoexist->manual_control)
return;
  
-	if (action)

+   btcoexist->btc_get(btcoexist, BTC_GET_BL_WIFI_UNDER_5G, _under_5g);
+
+   if (action) {
asso_type = BTC_ASSOCIATE_START;
-   else
+   asso_type_v2 = wifi_under_5g ? BTC_ASSOCIATE_5G_START :
+  BTC_ASSOCIATE_START;
+   } else {
asso_type = BTC_ASSOCIATE_FINISH;
+   asso_type_v2 = wifi_under_5g ? BTC_ASSOCIATE_5G_FINISH :
+  BTC_ASSOCIATE_FINISH;
+   }
  
  	halbtc_leave_low_power(btcoexist);
  
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h

index ad80ec05975e..0a7b09305bc3 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
@@ -401,6 +401,8 @@ enum btc_notify_type_switchband {
  enum btc_notify_type_associate {
BTC_ASSOCIATE_FINISH = 0x0,
BTC_ASSOCIATE_START = 0x1,
+   BTC_ASSOCIATE_5G_FINISH = 0x2,
+   BTC_ASSOCIATE_5G_START = 0x3,
BTC_ASSOCIATE_MAX
  };

Re: [PATCH v2 06/15] rtlwifi: btcoex: Add rate table for the use of btcoex

2018-03-19 Thread Larry Finger


On 03/05/2018 07:25 PM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

The btcoex use the rate to rsolve IOT issue that some APs reduce TX
rate quickly, so it uses the RX rate as a clue to decide TDMA.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


Acked-by: Larry Finger <Larry.Finger#lwfinger.net>



---
  .../realtek/rtlwifi/btcoexist/halbtcoutsrc.h   | 94 ++
  1 file changed, 94 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
index fe793b787716..bc2388f3f953 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
@@ -437,6 +437,100 @@ enum btc_notify_type_stack_operation {
BTC_STACK_OP_MAX
  };
  
+enum {

+   BTC_CCK_1,
+   BTC_CCK_2,
+   BTC_CCK_5_5,
+   BTC_CCK_11,
+   BTC_OFDM_6,
+   BTC_OFDM_9,
+   BTC_OFDM_12,
+   BTC_OFDM_18,
+   BTC_OFDM_24,
+   BTC_OFDM_36,
+   BTC_OFDM_48,
+   BTC_OFDM_54,
+   BTC_MCS_0,
+   BTC_MCS_1,
+   BTC_MCS_2,
+   BTC_MCS_3,
+   BTC_MCS_4,
+   BTC_MCS_5,
+   BTC_MCS_6,
+   BTC_MCS_7,
+   BTC_MCS_8,
+   BTC_MCS_9,
+   BTC_MCS_10,
+   BTC_MCS_11,
+   BTC_MCS_12,
+   BTC_MCS_13,
+   BTC_MCS_14,
+   BTC_MCS_15,
+   BTC_MCS_16,
+   BTC_MCS_17,
+   BTC_MCS_18,
+   BTC_MCS_19,
+   BTC_MCS_20,
+   BTC_MCS_21,
+   BTC_MCS_22,
+   BTC_MCS_23,
+   BTC_MCS_24,
+   BTC_MCS_25,
+   BTC_MCS_26,
+   BTC_MCS_27,
+   BTC_MCS_28,
+   BTC_MCS_29,
+   BTC_MCS_30,
+   BTC_MCS_31,
+   BTC_VHT_1SS_MCS_0,
+   BTC_VHT_1SS_MCS_1,
+   BTC_VHT_1SS_MCS_2,
+   BTC_VHT_1SS_MCS_3,
+   BTC_VHT_1SS_MCS_4,
+   BTC_VHT_1SS_MCS_5,
+   BTC_VHT_1SS_MCS_6,
+   BTC_VHT_1SS_MCS_7,
+   BTC_VHT_1SS_MCS_8,
+   BTC_VHT_1SS_MCS_9,
+   BTC_VHT_2SS_MCS_0,
+   BTC_VHT_2SS_MCS_1,
+   BTC_VHT_2SS_MCS_2,
+   BTC_VHT_2SS_MCS_3,
+   BTC_VHT_2SS_MCS_4,
+   BTC_VHT_2SS_MCS_5,
+   BTC_VHT_2SS_MCS_6,
+   BTC_VHT_2SS_MCS_7,
+   BTC_VHT_2SS_MCS_8,
+   BTC_VHT_2SS_MCS_9,
+   BTC_VHT_3SS_MCS_0,
+   BTC_VHT_3SS_MCS_1,
+   BTC_VHT_3SS_MCS_2,
+   BTC_VHT_3SS_MCS_3,
+   BTC_VHT_3SS_MCS_4,
+   BTC_VHT_3SS_MCS_5,
+   BTC_VHT_3SS_MCS_6,
+   BTC_VHT_3SS_MCS_7,
+   BTC_VHT_3SS_MCS_8,
+   BTC_VHT_3SS_MCS_9,
+   BTC_VHT_4SS_MCS_0,
+   BTC_VHT_4SS_MCS_1,
+   BTC_VHT_4SS_MCS_2,
+   BTC_VHT_4SS_MCS_3,
+   BTC_VHT_4SS_MCS_4,
+   BTC_VHT_4SS_MCS_5,
+   BTC_VHT_4SS_MCS_6,
+   BTC_VHT_4SS_MCS_7,
+   BTC_VHT_4SS_MCS_8,
+   BTC_VHT_4SS_MCS_9,
+   BTC_MCS_32,
+   BTC_UNKNOWN,
+   BTC_PKT_MGNT,
+   BTC_PKT_CTRL,
+   BTC_PKT_UNKNOWN,
+   BTC_PKT_NOT_FOR_ME,
+   BTC_RATE_MAX
+};
+
  enum {
BTC_MULTIPORT_SCC,
BTC_MULTIPORT_MCC_2CHANNEL,

Re: [PATCH v2 05/15] rtlwifi: btcoex: Get status of multichannel concurrence

2018-03-19 Thread Larry Finger


On 03/05/2018 07:25 PM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

btcoex does different decision according to MCC or SCC status, but
driver is still SCC currently.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


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


---
  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 3 +++
  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h | 8 
  2 files changed, 11 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index 823694cb4fdb..1a24aed34094 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -577,6 +577,9 @@ static bool halbtc_get(void *void_btcoexist, u8 get_type, 
void *out_buf)
tmp = true;
*bool_tmp = tmp;
break;
+   case BTC_GET_BL_WIFI_DUAL_BAND_CONNECTED:
+   *u8_tmp = BTC_MULTIPORT_SCC;
+   break;
case BTC_GET_BL_WIFI_BUSY:
if (halbtc_is_wifi_busy(rtlpriv))
*bool_tmp = true;
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
index 3c6a1e8851ec..fe793b787716 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
@@ -251,6 +251,7 @@ enum btc_get_type {
BTC_GET_BL_HS_OPERATION,
BTC_GET_BL_HS_CONNECTING,
BTC_GET_BL_WIFI_CONNECTED,
+   BTC_GET_BL_WIFI_DUAL_BAND_CONNECTED,
BTC_GET_BL_WIFI_BUSY,
BTC_GET_BL_WIFI_SCAN,
BTC_GET_BL_WIFI_LINK,
@@ -436,6 +437,13 @@ enum btc_notify_type_stack_operation {
BTC_STACK_OP_MAX
  };
  
+enum {

+   BTC_MULTIPORT_SCC,
+   BTC_MULTIPORT_MCC_2CHANNEL,
+   BTC_MULTIPORT_MCC_2BAND,
+   BTC_MULTIPORT_MAX
+};
+
  struct btc_bt_info {
bool bt_disabled;
u8 rssi_adjust_for_agc_table_on;

Re: [PATCH v2 03/15] rtlwifi: btcoex: Add enum DM_INFO for btcoex to query dm's counters

2018-03-19 Thread Larry Finger


On 03/05/2018 07:25 PM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

btcoex uses dm's counters to check the environment is noisy or not. If it
is clean, btcoex set more time slots to WiFi so that it can transmit as
soon as possible. That will save time, and BT will have more time slots
after WiFi traffic is complete.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


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



---
  drivers/net/wireless/realtek/rtlwifi/wifi.h | 32 +
  1 file changed, 32 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h 
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 4f48b934ec01..438678c2d14a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -977,6 +977,38 @@ enum rtl_spec_ver {
RTL_SPEC_EXT_C2H = BIT(2),  /* extend FW C2H (e.g. TX REPORT) */
  };
  
+enum dm_info_query {

+   DM_INFO_FA_OFDM,
+   DM_INFO_FA_CCK,
+   DM_INFO_FA_TOTAL,
+   DM_INFO_CCA_OFDM,
+   DM_INFO_CCA_CCK,
+   DM_INFO_CCA_ALL,
+   DM_INFO_CRC32_OK_VHT,
+   DM_INFO_CRC32_OK_HT,
+   DM_INFO_CRC32_OK_LEGACY,
+   DM_INFO_CRC32_OK_CCK,
+   DM_INFO_CRC32_ERROR_VHT,
+   DM_INFO_CRC32_ERROR_HT,
+   DM_INFO_CRC32_ERROR_LEGACY,
+   DM_INFO_CRC32_ERROR_CCK,
+   DM_INFO_EDCCA_FLAG,
+   DM_INFO_OFDM_ENABLE,
+   DM_INFO_CCK_ENABLE,
+   DM_INFO_CRC32_OK_HT_AGG,
+   DM_INFO_CRC32_ERROR_HT_AGG,
+   DM_INFO_DBG_PORT_0,
+   DM_INFO_CURR_IGI,
+   DM_INFO_RSSI_MIN,
+   DM_INFO_RSSI_MAX,
+   DM_INFO_CLM_RATIO,
+   DM_INFO_NHM_RATIO,
+   DM_INFO_IQK_ALL,
+   DM_INFO_IQK_OK,
+   DM_INFO_IQK_NG,
+   DM_INFO_SIZE,
+};
+
  struct octet_string {
u8 *octet;
u16 length;

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

2018-03-19 Thread Larry Finger


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

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

Trivial fix to spelling mistake in RT_TRACE message text.

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


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

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

2018-03-11 Thread Larry Finger


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


Larry

Re: [PATCH 05/15] rtlwifi: btcoex: Get status of multichannel concurrence

2018-03-02 Thread Larry Finger


On 02/27/2018 09:07 PM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

btcoex does different decision according to MCC or SCC status, but
driver is still SCC currently.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


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


---
  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 3 +++
  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h | 8 
  2 files changed, 11 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index 823694cb4fdb..1a24aed34094 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -577,6 +577,9 @@ static bool halbtc_get(void *void_btcoexist, u8 get_type, 
void *out_buf)
tmp = true;
*bool_tmp = tmp;
break;
+   case BTC_GET_BL_WIFI_DUAL_BAND_CONNECTED:
+   *u8_tmp = BTC_MULTIPORT_SCC;
+   break;
case BTC_GET_BL_WIFI_BUSY:
if (halbtc_is_wifi_busy(rtlpriv))
*bool_tmp = true;
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
index 3c6a1e8851ec..fe793b787716 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
@@ -251,6 +251,7 @@ enum btc_get_type {
BTC_GET_BL_HS_OPERATION,
BTC_GET_BL_HS_CONNECTING,
BTC_GET_BL_WIFI_CONNECTED,
+   BTC_GET_BL_WIFI_DUAL_BAND_CONNECTED,
BTC_GET_BL_WIFI_BUSY,
BTC_GET_BL_WIFI_SCAN,
BTC_GET_BL_WIFI_LINK,
@@ -436,6 +437,13 @@ enum btc_notify_type_stack_operation {
BTC_STACK_OP_MAX
  };
  
+enum {

+   BTC_MULTIPORT_SCC,
+   BTC_MULTIPORT_MCC_2CHANNEL,
+   BTC_MULTIPORT_MCC_2BAND,
+   BTC_MULTIPORT_MAX
+};
+
  struct btc_bt_info {
bool bt_disabled;
u8 rssi_adjust_for_agc_table_on;

Re: [PATCH 03/15] rtlwifi: btcoex: Add enum DM_INFO for btcoex to query dm's counters

2018-03-02 Thread Larry Finger


On 02/27/2018 09:07 PM, pks...@realtek.com wrote:

From: Ping-Ke Shih 

btcoex uses dm's counters to check the envoriment is nosiy or not. If it
is clean, btcoex set more time solts to WiFi so that it can transimt as
soon as possible. That will save time, and BT will have more time solts
after WiFi traffic is complete.

Signed-off-by: Ping-Ke Shih 


The commit message needs to have the following typos fixed:
envoriment should be environment
nosiy should be noisy
solts should be slots (2 places)
transimt should be transmit

Yes, I know it is difficult to write in a second language.

Larry




---
  drivers/net/wireless/realtek/rtlwifi/wifi.h | 32 +
  1 file changed, 32 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h 
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 4f48b934ec01..438678c2d14a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -977,6 +977,38 @@ enum rtl_spec_ver {
RTL_SPEC_EXT_C2H = BIT(2),  /* extend FW C2H (e.g. TX REPORT) */
  };
  
+enum dm_info_query {

+   DM_INFO_FA_OFDM,
+   DM_INFO_FA_CCK,
+   DM_INFO_FA_TOTAL,
+   DM_INFO_CCA_OFDM,
+   DM_INFO_CCA_CCK,
+   DM_INFO_CCA_ALL,
+   DM_INFO_CRC32_OK_VHT,
+   DM_INFO_CRC32_OK_HT,
+   DM_INFO_CRC32_OK_LEGACY,
+   DM_INFO_CRC32_OK_CCK,
+   DM_INFO_CRC32_ERROR_VHT,
+   DM_INFO_CRC32_ERROR_HT,
+   DM_INFO_CRC32_ERROR_LEGACY,
+   DM_INFO_CRC32_ERROR_CCK,
+   DM_INFO_EDCCA_FLAG,
+   DM_INFO_OFDM_ENABLE,
+   DM_INFO_CCK_ENABLE,
+   DM_INFO_CRC32_OK_HT_AGG,
+   DM_INFO_CRC32_ERROR_HT_AGG,
+   DM_INFO_DBG_PORT_0,
+   DM_INFO_CURR_IGI,
+   DM_INFO_RSSI_MIN,
+   DM_INFO_RSSI_MAX,
+   DM_INFO_CLM_RATIO,
+   DM_INFO_NHM_RATIO,
+   DM_INFO_IQK_ALL,
+   DM_INFO_IQK_OK,
+   DM_INFO_IQK_NG,
+   DM_INFO_SIZE,
+};
+
  struct octet_string {
u8 *octet;
u16 length;

Re: [PATCH 04/15] rtlwifi: btcoex: Add customer_id to do special deal to oem vendor

2018-03-02 Thread Larry Finger


On 02/27/2018 09:07 PM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

Add customer_id field in structure, and then this is a clue to implement
the behavior defined by vendor LENOVO_CHINA.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


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


---
  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h | 1 +
  drivers/net/wireless/realtek/rtlwifi/wifi.h   | 1 +
  2 files changed, 2 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
index f5d8159a88eb..3c6a1e8851ec 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
@@ -154,6 +154,7 @@ struct btc_board_info {
  
  	u8 rfe_type;

u8 ant_div_cfg;
+   u8 customer_id;
  };
  
  enum btc_dbg_opcode {

diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h 
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 438678c2d14a..d27e33960e77 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -556,6 +556,7 @@ enum rt_oem_id {
RT_CID_NETGEAR = 36,
RT_CID_PLANEX = 37,
RT_CID_CC_C = 38,
+   RT_CID_LENOVO_CHINA = 40,
  };
  
  enum hw_descs {

Re: [PATCH 02/15] rtlwifi: remove redundant statement found by static checker

2018-03-02 Thread Larry Finger


On 02/27/2018 09:07 PM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

smatch reports "rtl_is_special_data() warn: inconsistent indenting", but
it is an obvious redundant statement so remove it.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


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


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

diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c 
b/drivers/net/wireless/realtek/rtlwifi/base.c
index 6db3389e2ced..762a29cdf7ad 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -1549,7 +1549,6 @@ u8 rtl_is_special_data(struct ieee80211_hw *hw, struct 
sk_buff *skb, u8 is_tx,
/* EAPOL is seens as in-4way */
rtlpriv->btcoexist.btc_info.in_4way = true;
rtlpriv->btcoexist.btc_info.in_4way_ts = jiffies;
-   rtlpriv->btcoexist.btc_info.in_4way_ts = jiffies;
  
  		RT_TRACE(rtlpriv, (COMP_SEND | COMP_RECV), DBG_DMESG,

 "802.1X %s EAPOL pkt!!\n", (is_tx) ? "Tx" : "Rx");

Re: [PATCH 01/15] rtlwifi: Add modifier static to functions reported by sparse

2018-03-02 Thread Larry Finger


On 02/27/2018 09:07 PM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

sparse reports some functions were not declared, so add 'static' as
modifier. Remove an unused function btc8821a1ant_is_wifi_status_changed()
exposed due to 'static'.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


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


---
  .../realtek/rtlwifi/btcoexist/halbtc8723b1ant.c|  1 +
  .../realtek/rtlwifi/btcoexist/halbtc8723b2ant.c|  6 ++--
  .../realtek/rtlwifi/btcoexist/halbtc8821a1ant.c| 33 --
  .../realtek/rtlwifi/btcoexist/halbtc8821a2ant.c|  4 +--
  4 files changed, 6 insertions(+), 38 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
index 05beb16f0a0a..59553db020ef 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
@@ -1436,6 +1436,7 @@ static void halbtc8723b1ant_ps_tdma(struct btc_coexist 
*btcoexist,
coex_dm->pre_ps_tdma = coex_dm->cur_ps_tdma;
  }
  
+static

  void btc8723b1ant_tdma_dur_adj_for_acl(struct btc_coexist *btcoexist,
   u8 wifi_status)
  {
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
index 4907c2ffadfe..73ec31972944 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
@@ -833,9 +833,9 @@ static void btc8723b2ant_set_sw_fulltime_dac_swing(struct 
btc_coexist *btcoex,
btc8723b2ant_set_dac_swing_reg(btcoex, 0x18);
  }
  
-void btc8723b2ant_dac_swing(struct btc_coexist *btcoexist,

-   bool force_exec, bool dac_swing_on,
-   u32 dac_swing_lvl)
+static void btc8723b2ant_dac_swing(struct btc_coexist *btcoexist,
+  bool force_exec, bool dac_swing_on,
+  u32 dac_swing_lvl)
  {
struct rtl_priv *rtlpriv = btcoexist->adapter;
  
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c

index 0b26419881c0..202597cf8915 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c
@@ -426,39 +426,6 @@ static void btc8821a1ant_query_bt_info(struct btc_coexist 
*btcoexist)
btcoexist->btc_fill_h2c(btcoexist, 0x61, 1, h2c_parameter);
  }
  
-bool btc8821a1ant_is_wifi_status_changed(struct btc_coexist *btcoexist)

-{
-   static bool pre_wifi_busy = true;
-   static bool pre_under_4way = true;
-   static bool pre_bt_hs_on = true;
-   bool wifi_busy = false, under_4way = false, bt_hs_on = false;
-   bool wifi_connected = false;
-
-   btcoexist->btc_get(btcoexist, BTC_GET_BL_WIFI_CONNECTED,
-  _connected);
-   btcoexist->btc_get(btcoexist, BTC_GET_BL_WIFI_BUSY, _busy);
-   btcoexist->btc_get(btcoexist, BTC_GET_BL_HS_OPERATION, _hs_on);
-   btcoexist->btc_get(btcoexist, BTC_GET_BL_WIFI_4_WAY_PROGRESS,
-  _4way);
-
-   if (wifi_connected) {
-   if (wifi_busy != pre_wifi_busy) {
-   pre_wifi_busy = wifi_busy;
-   return true;
-   }
-   if (under_4way != pre_under_4way) {
-   pre_under_4way = under_4way;
-   return true;
-   }
-   if (bt_hs_on != pre_bt_hs_on) {
-   pre_bt_hs_on = bt_hs_on;
-   return true;
-   }
-   }
-
-   return false;
-}
-
  static void btc8821a1ant_update_bt_link_info(struct btc_coexist *btcoexist)
  {
struct btc_bt_link_info *bt_link_info = >bt_link_info;
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
index d5f282cb9d24..2202d5e18977 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
@@ -359,7 +359,7 @@ static void btc8821a2ant_query_bt_info(struct btc_coexist 
*btcoexist)
btcoexist->btc_fill_h2c(btcoexist, 0x61, 1, h2c_parameter);
  }
  
-bool btc8821a2ant_is_wifi_status_changed(struct btc_coexist *btcoexist)

+static bool btc8821a2ant_is_wifi_status_changed(struct btc_coexist *btcoexist)
  {
static bool pre_wifi_busy = true;
static bool pre_under_4way = true;
@@ -1517,7 +1517,7 @@ static void btc8821a2ant_action_bt_inquiry(struct 
btc_coexist *btcoexist)
btc8821a2ant_sw_mechanism2(btc

Re: [PATCH v2] bcma: Prevent build of PCI host features in module

2018-03-02 Thread Larry Finger


On 03/01/2018 04:45 AM, Kalle Valo wrote:

Matt Redfearn  writes:


Attempting to build bcma.ko with BCMA_DRIVER_PCI_HOSTMODE=y results in
a build error due to use of symbols not exported from vmlinux:

ERROR: "pcibios_enable_device" [drivers/bcma/bcma.ko] undefined!
ERROR: "register_pci_controller" [drivers/bcma/bcma.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:92: __modpost] Error 1

To prevent this, don't allow the host mode feature to be built if
CONFIG_BCMA=m

Signed-off-by: Matt Redfearn 

---

Changes in v2:
Rebase on v4.16-rc1

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

diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig
index ba8acca036df..cb0f1aad20b7 100644
--- a/drivers/bcma/Kconfig
+++ b/drivers/bcma/Kconfig
@@ -55,7 +55,7 @@ config BCMA_DRIVER_PCI
  
  config BCMA_DRIVER_PCI_HOSTMODE

bool "Driver for PCI core working in hostmode"
-   depends on MIPS && BCMA_DRIVER_PCI && PCI_DRIVERS_LEGACY
+   depends on MIPS && BCMA_DRIVER_PCI && PCI_DRIVERS_LEGACY && BCMA = y


Due to the recent regression in bcma I would prefer extra careful review
before I apply this. So does this look ok to everyone?


I have a preference for wireless device drivers to be modules. For that reason, 
I would have submitted a patch exporting those two missing globals rather than 
forcing bcma to be built in. That said, it seems that the patch will do no 
further harm.


Larry

Re: Support on vendor id and device id

2018-02-27 Thread Larry Finger


On 02/27/2018 07:30 AM, Harsha Rao wrote:

On Tue, Feb 27, 2018 at 4:45 PM, Arend van Spriel
 wrote:

On 2/27/2018 11:16 AM, Harsha Rao wrote:


Hi folks,
I am developing a new wifi driver for our sdio based wifi device.

I see that SDIO_VENDOR_ID and SDIO_DEVICE_ID for our device (We had
bought the SDIO IP from 3rd party)  is already  been used by some
other vendor and its already into staging .

Please suggest me how can I move forward to submit the driver for staging.



Can you be more specific about the conflicting vendor id and device id?


Hi,
My driver kicks in  with vendor id 0x296 and device id 0x5347.
But when I grepped the the kernel source I could see an other driver
wilc1000 using the same vendor ID and device ID
( We have a different hw than them !)


Is there a way to reconfigure the values in the SDIO host for
different value or does Linux allow two drivers with same values to
survive mutual exclusively



First come first serve. When a device is detected, the driver core looks for
drivers supporting it based on device table and the first that successfully
returns from the .probe() callback is bound to the device.

Regards,
Arend


Does Linux allow two drivers with conflicting device and vendor IDs to
stay on in kernel ?


Yes. We have a similar situation with the rtl8192e driver in staging and the 
rtl8192se driver in the wireless tree, which share PCI ID 0bda:8192. Our 
solution was to insert code in the probe routine that tests some value in 
addition to the PCI ID. In our case, that was the PCI revision id. Line 2496 of 
file drivers/staging/rtl8192e/rtl8192e/rtl_core.c shows the test in the staging 
driver.


The downsides of this unfortunate duplication are that if the wrong driver loads 
first, then it remains loaded, you will need to cooperate with the maintainer of 
the other driver to insert the extra detection code, and you may need to do 
quite a bit of processing to be able to determine whether you have the correct 
device.


Larry

Re: [PATCH] ath9k: introduce endian_check module parameter

2018-02-26 Thread Larry Finger


On 02/26/2018 04:07 AM, Bas Vermeulen wrote:

On 26-02-18 10:54, Kalle Valo wrote:

Bas Vermeulen  writes:


A random (little endian eeprom'd) ar9278 card didn't work on my
PowerMac G5 without allowing the driver to byte-swap the eeprom.

Introduce a module parameter endian_check to allow this to happen,
and the PCIe card to function correctly on BE powerpc.

Signed-off-by: Bas Vermeulen 
---
  drivers/net/wireless/ath/ath9k/init.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c

index fa58a32227f5..421039dc060a 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -67,6 +67,9 @@ static int ath9k_ps_enable;
  module_param_named(ps_enable, ath9k_ps_enable, int, 0444);
  MODULE_PARM_DESC(ps_enable, "Enable WLAN PowerSave");
+static int ath9k_endian_check;
+module_param_named(endian_check, ath9k_endian_check, int, 0444);
+MODULE_PARM_DESC(endian_check, "Check EEPROM for endianness compatibility");
  #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
  int ath9k_use_chanctx;
@@ -587,7 +590,8 @@ static int ath9k_of_init(struct ath_softc *sc)
  ether_addr_copy(common->macaddr, mac);
  ah->ah_flags &= ~AH_USE_EEPROM;
-    ah->ah_flags |= AH_NO_EEP_SWAP;
+    if (!ath9k_endian_check)
+    ah->ah_flags |= AH_NO_EEP_SWAP;

A bit annoying to have a module parameter, isn't there any automatic way
to detect/try this? But on the other hand I guess this isn't a common
problem as nobody has reported this before?
There is an automatic way to detect this, but that is disabled by the 
AH_NO_EEP_SWAP flag.
The platform initialisation does not set this flag if the endian_check member of 
pdata is set
to true, but there is no way to not set this when using a device tree. I used a 
module
parameter instead of a device tree variable because I don't know of a way to 
modify the

device tree my PowerMac boots with.


Shouldn't you be able to set ath9k_endian_check inside #ifdef __BIG_ENDIAN ... 
#endif in the initialization? I think that would achieve the same functionality 
without requiring the user to set a module parameter.


I agree that you want to stay away from the device tree in a PPC computer.

Larry

Re: [PATCH] rtlwifi: rtl8723be: Fix loss of signal

2018-02-23 Thread Larry Finger


On 02/23/2018 03:18 AM, Kalle Valo wrote:

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


In commit c713fb071edc ("rtlwifi: rtl8821ae: Fix connection lost problem
correctly") a problem in rtl8821ae that caused loss of signal was fixed.
That same problem has now been reported for rtl8723be. Accordingly,
the ASPM L1 latency has been increased from 0 to 7 to fix the instability.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
Cc: Stable <sta...@vger.kernel.org>
---
Kalle,

This patch should be sent to 4.16.


Ok, I'll queue this for 4.16.


Thanks,

Larry

[PATCH] rtlwifi: rtl8723be: Fix loss of signal

2018-02-22 Thread Larry Finger

In commit c713fb071edc ("rtlwifi: rtl8821ae: Fix connection lost problem
correctly") a problem in rtl8821ae that caused loss of signal was fixed.
That same problem has now been reported for rtl8723be. Accordingly,
the ASPM L1 latency has been increased from 0 to 7 to fix the instability.

Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
Cc: Stable <sta...@vger.kernel.org>
---
Kalle,

This patch should be sent to 4.16.

Thanks,
Larry
---
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
index f9ccd13c79f9..e7bbbc95cdb1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
@@ -1125,7 +1125,8 @@ static void _rtl8723be_enable_aspm_back_door(struct 
ieee80211_hw *hw)
 
/* Configuration Space offset 0x70f BIT7 is used to control L0S */
tmp8 = _rtl8723be_dbi_read(rtlpriv, 0x70f);
-   _rtl8723be_dbi_write(rtlpriv, 0x70f, tmp8 | BIT(7));
+   _rtl8723be_dbi_write(rtlpriv, 0x70f, tmp8 | BIT(7) |
+ASPM_L1_LATENCY << 3);
 
/* Configuration Space offset 0x719 Bit3 is for L1
 * BIT4 is for clock request
-- 
2.16.2

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

2018-02-11 Thread Larry Finger

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

These files were provided by the Realtek developer.

Signed-off-by: 陆朱伟 <alex...@realsil.com.cn>
Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---
 WHENCE |   5 +
 rtl_bt/rtl8723d_config.bin | Bin 0 -> 10 bytes
 rtl_bt/rtl8723d_fw.bin | Bin 0 -> 47028 bytes
 rtl_bt/rtl8821c_config.bin | Bin 0 -> 10 bytes
 rtl_bt/rtl8821c_fw.bin | Bin 0 -> 37356 bytes
 5 files changed, 5 insertions(+)
 create mode 100644 rtl_bt/rtl8723d_config.bin
 create mode 100644 rtl_bt/rtl8723d_fw.bin
 create mode 100644 rtl_bt/rtl8821c_config.bin
 create mode 100644 rtl_bt/rtl8821c_fw.bin

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

literal 0
HcmV?d1

diff --git a/rtl_bt/rtl8723d_fw.bin b/rtl_bt/rtl8723d_fw.bin
new file mode 100644
index 
..57f3a5997a8685fb0ead20d8f79d7c012a264f00
GIT binary patch
literal 47028
zcmd443tSXemIqwbbT<t_(G+yJ;{gpiw~0JEem0(PWHy5u=%E5evJkAwiRICNZfP
z^O}Kd6nw<TY};UB6f)Y~nC$Lkr_<;pqd2SJE3aMRBZ2Nl8#S7pWVXNmsipy)%*^iZ
zx8Hsr{BG5)TeoiAx{q_uJ?DQ;FD$c4tIA5tSH32#jbm6w#l$glIPSLGipdPa_)
z=OWVg_vcd0(s6En>p0KMg0%(mky|{nu_T8-GS+j8Tlnmj-s3pL$9ba1@raLicZADa
z9pQB@A-^Wr5q`xb7sv)AsFG1n-~<gE!VE$9d@^LK<__A}R(=C8$-h^trp!#yKV
z#)#hINW@2aqQ_B)kMht_vzfURSIU$X?~7=!!}!u~y+98NUI8+UT@4>(_VkCP?N
zAP>X&2faaF)4<7D2?kj}UVNZj^DZYh=nV4hICHrF7M{yWGRQ}fuNCP#aNUUf#~X2t
zbL9FMyA+ZwQi!?2E|$6(o5m^^M~bEH$dVG#)X9`FWk@N$6SYH{rO>pN`|p{=qoD
z;xEAQRev&$ulW~Bj9ut?-TySMO8r8Q4dGV^5`qJv0-+M~mst{KC=?zqOoNW~6
z8`-OIRYR<L^pACBeC9~|>Oi8$5SV)|(Np?a;(%0*lBz{2J!_0N$b2Q*#l^`Z5r66(
zPQG+~j7{yS4)A$=o+A+FF?I5vQycx($?RinaUTANl6K_&)dqPU0%Mz#uk${29^dgr
zd~;#J`U^rUJ5On$K;ohvE7ebpe7Oiel*TXB9!qsc%Bwry+G8@#9<A0ys#1kD;+(xH
zfu!t?%er|bojSLnb4Eu;c&?LOR3fq*V~gLceUrJQF5UeM`ggrS{=PI}sqT3EvB(Oh
z{1%V1J|gKuns(W^e!TjmdZVVcDZsa%yZ3E#WoY)5#Gi>(@DRp*WJ%st2NNipm4
zM|d6Qg>8=q+3X9QhQO>YR(L=}tyfsO*f}`cES-rZ$E}g47@JCn*m47$mv7}f$!6!?
z_s{yS*B89eU3($!p?E9n(0iS&{1Fw$@8w$)HtW{Mqpq4#7T-!GW+Ft}
z0dFbShoY@8JbQ^)zDKEZFj?uNj_{k9H@jSn@#H0@EWso9aFTPc+P*BH?{;)E##yuV
z-LZC|_q@q62WXC}k5ReRoy=u}M7j2f%;ogH*pR-Mu{WmKtVVs~O1~>jU7B({nVw#u
zTGiS$|QW??^n!7%vnho#xLZZcN%-v}=fY}(`S7moRaz@+AL=%R*Z6<7OUFHe
z6tsrjprowcmF5=wOT;OM*N7^cDO}WIx`MG9KHsw7i1uWXd+pZvO$i%xn;GK+W_4Q}
z#~4@bJ1(YfPFbIf+UPK!sjnHd)nZe$zxnOV!r=mIQ@5qMHEq^LWt>V<;7<<Uw`@hj
z6@8`2*zmNrP3MV7vV*VR+g%-K3Sb!WIo|8WTO`&<wQ#xwt$m1i9
zMQqgp#-7;ryqg*MN0Z=R<57u1Pj3BlZp`RyQb28H?MdzWb}g6F<-2a4!Z`HDlTNO3
z7jEU+R-xUVaj`20Tem1PL#N@gzZ9Q*Pni?Jirz8tQ<vH<1>#Un8QOP+TiBCoOMRS1
zs1y)AtR%O*DKaBZng+KC9#hy`ZwhZhc)EV9SkpDE-O=?^Pe=Wu9-%(w9${~F@G=QD{up8xe;_`5V7}M+dp_LWka9Bl
z)X-ZP2OstvymWoIG`MXDW?$F%^wY&`=yKB0c%fl?uQJTJaNbTSa_fd%s<{DEj
zH&%D=5Z$ebo5BU$=A)h5rr@QcmweaHPVb!F9U8Xz>a?RF<EAr+r*8fM@mvJ`rlieB
zyC#OtBOa+pTi+U@b)=@Vpun(xGIAD}_*MvLU`q46FU0!iljyKoMyX1z}t_68p
z3TguJQe(5le3q_$gd}`7qVjGPIGsZ*GhQy7+HTM3A7(EV*F72@)?a?uj
zwAnN*as80m?u!#I?h{p*KR--!TpYD|<oXd9v#A(gcYr3B6k*&(m`IFPEx;IFNaGmc
zK7<$@cpLN81e!Zs#T*!o_#)hU41vZxjZ=k29M>FM;Nkb8<s^1qHRvgSWVp51{q=
z9E+RZlVE10`EJ=i-_1yL6b`GnxuDQ<FfIyl#n@(g9zMb|BX>_=LU#g$HU7AwR|
zuOa9-?+e@NH7nJaxp!eiX}Nyd9kSkmr(|ROc)>r-owYU22HKdxuE<9z|KJjOnq1Vn
zj9qQcaSJZ?@zvrj?)4YghfLwYt}P<FYKy3zT+@jW=;Ff-uGi2zrf{8WQg=0C5vjU!
z$V5}K(9^h!56^PF7f8)Ep)^_r#<-oXk%+$+&}3so<{-W&`6n=npF_h2T~4|X
zBsU)}_4DB@KPZjMfVwlbG<+!q(8cu{^obgMLTeQD1@(gkf%<~hF6s;FE25o5t7jvq
z5Qsig9}z80aSK}+TQcX|`xSbiF_hH|eB0$5O?G^9bSy9xF
zf_4#q6B|!d=ATNFmL?ugIA+>@uf0*Uxh9_4xL_=$dRV^>cQ6usUe<
zJGas}RY`NX%#|u@rZkgFTUlgfx0>^2=2ZuVnN>IzEQ+^|xz5_=2P~c1%ZyFOr7wyX
zVkxStjIFqnxn|A>N9P~Hjq~s=j4h$+7Ehe@1?lw`HOETD=YAEEThK0`PPFQe@tTbP
zQoxi^KSu14c~T%{ky=<Unv7Qp_KD*p>P@DMwT

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

2018-02-09 Thread Larry Finger


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

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

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

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

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

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


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

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

Sorry about the noise.

Larry

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

2018-02-09 Thread Larry Finger


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

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

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

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

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

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


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


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

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


NACK.

Larry

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

2018-02-08 Thread Larry Finger


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

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

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

Delete the branch with the self-assignment.

Signed-off-by: Matthias Kaehlcke <m...@chromium.org>
---
Changes in v2:
- Delete the 'else if' branch entirely

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


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




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

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

2018-02-07 Thread Larry Finger


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

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

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

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

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

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



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


Larry

[PATCH] rtlwifi: rtl8821ae: Fix connection lost problem correctly

2018-02-05 Thread Larry Finger

There has been a coding error in rtl8821ae since it was first introduced,
namely that an 8-bit register was read using a 16-bit read in
_rtl8821ae_dbi_read(). This error was fixed with commit 40b368af4b75
("rtlwifi: Fix alignment issues"); however, this change led to
instability in the connection. To restore stability, this change
was reverted in commit b8b8b16352cd ("rtlwifi: rtl8821ae: Fix connection
lost problem").

Unfortunately, the unaligned access causes machine checks in ARM
architecture, and we were finally forced to find the actual cause of the
problem on x86 platforms. Following a suggestion from Pkshih
<pks...@realtek.com>, it was found that increasing the ASPM L1
latency from 0 to 7 fixed the instability. This parameter was varied to
see if a smaller value would work; however, it appears that 7 is the
safest value. A new symbol is defined for this quantity, thus it can be
easily changed if necessary.

Fixes: b8b8b16352cd ("rtlwifi: rtl8821ae: Fix connection lost problem")
Cc: Stable <sta...@vger.kernel.org> # 4.14+
Fix-suggested-by: Pkshih <pks...@realtek.com>
Signed-off-by: Larry Finger <larry.fin...@lwfinger.net>
---

Kalle,

This patch should be submitted to 4.16.

Larry
---
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 5 +++--
 drivers/net/wireless/realtek/rtlwifi/wifi.h | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
index f20e77b4bb65..317c1b3101da 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
@@ -1123,7 +1123,7 @@ static u8 _rtl8821ae_dbi_read(struct rtl_priv *rtlpriv, 
u16 addr)
}
if (0 == tmp) {
read_addr = REG_DBI_RDATA + addr % 4;
-   ret = rtl_read_word(rtlpriv, read_addr);
+   ret = rtl_read_byte(rtlpriv, read_addr);
}
return ret;
 }
@@ -1165,7 +1165,8 @@ static void _rtl8821ae_enable_aspm_back_door(struct 
ieee80211_hw *hw)
}
 
tmp = _rtl8821ae_dbi_read(rtlpriv, 0x70f);
-   _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7));
+   _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7) |
+ASPM_L1_LATENCY << 3);
 
tmp = _rtl8821ae_dbi_read(rtlpriv, 0x719);
_rtl8821ae_dbi_write(rtlpriv, 0x719, tmp | BIT(3) | BIT(4));
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h 
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 1c9ed28b42da..4f48b934ec01 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -99,6 +99,7 @@
 #define RTL_USB_MAX_RX_COUNT   100
 #define QBSS_LOAD_SIZE 5
 #define MAX_WMMELE_LENGTH  64
+#define ASPM_L1_LATENCY7
 
 #define TOTAL_CAM_ENTRY32
 
-- 
2.16.1

Re: rtl8821ae keep alive not set, connection lost

2018-02-04 Thread Larry Finger


On 02/02/2018 10:45 PM, Pkshih wrote:

On Fri, 2018-02-02 at 14:13 -0600, Larry Finger wrote:

On 02/02/2018 01:50 AM, Pkshih wrote:

Hi James,
  
In my experiment, unaligned-word-access may get wrong values that

are different from the value by byte-access. Actually, it can simply
verified by using 'lspci' to check PCI configuration space.
  
DBI read 0x70f:

_rtl8821ae_dbi_read:1127 r8 0x34f = 0x0017
_rtl8821ae_dbi_read:1131 r8 0x350 = 0x000c
_rtl8821ae_dbi_read:1136 r16 0x350 = 0x
  
DBI read 0x719:

_rtl8821ae_dbi_read:1127 r8 0x34d = 0x
_rtl8821ae_dbi_read:1131 r8 0x34e = 0x0002
_rtl8821ae_dbi_read:1136 r16 0x34e = 0x0200
  
  
According to the wrong and original value of 0x70f is 0xff, I think

larger L1 latency 0x70f[5:3] may be helpful. Please help to try
below patch. If it works, quirk table won't be necessary.
  
PK
  
  
diff --git a/rtl8821ae/hw.c b/rtl8821ae/hw.c

index 7d43ba002..e53af06ed 100644
--- a/rtl8821ae/hw.c
+++ b/rtl8821ae/hw.c
@@ -1123,7 +1123,8 @@ static u8 _rtl8821ae_dbi_read(struct rtl_priv *rtlpriv, 
u16 addr)
    }
    if (0 == tmp) {
    read_addr = REG_DBI_RDATA + addr % 4;
-   ret = rtl_read_word(rtlpriv, read_addr);
+
+   ret = rtl_read_byte(rtlpriv, read_addr);
    }
    return ret;
    }
@@ -1165,7 +1166,7 @@ static void _rtl8821ae_enable_aspm_back_door(struct 
ieee80211_hw *hw)
    }

    	tmp = _rtl8821ae_dbi_read(rtlpriv, 0x70f);

-   _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7));
+   _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7) | 0x38);

    	tmp = _rtl8821ae_dbi_read(rtlpriv, 0x719);

    _rtl8821ae_dbi_write(rtlpriv, 0x719, tmp | BIT(3) | BIT(4));
  



PK,

This patch works perfectly on my x86_64 system. With it, the interface handled a
10 million count flood ping with <1000 packets dropped. It has now been running
for at least 11 hours. Good work.

Can you explain that magic 0x38? I'm quite sure that Kalle will not accept the
patch as is. He already thinks that rtlwifi and friends already have too many
magic numbers.


The magic 0x38 represents L1 latency 0x70f[5:3]=b'111, and I will add definition
or macro to describe
0x70f and move all ASPM code into pci.c, if the problem was
solved. Hence, rtl8723de and rtl8723be
will use the same values, too.

Could you also help to test L1 latency as recommended value b'100?
(i.e. 0x20 instead)


I have run several tests with the following results:

b'010   Failed very quickly
b'100   Did not fail, but the ping test had errors
b'110   No failure and no errors

My tests seem to indicate that we should use at least 0x30 in the field, and 
perhaps we should stay at b'111 or 0x38.


To fix the current alignment errors for ARM architecture, I will push a patch 
for mainline and stable that fixes rtl8821ae. Then you can do the patch that 
moves all ASPM code into pci.c.


Larry

Re: rtl8821ae keep alive not set, connection lost

2018-02-02 Thread Larry Finger


On 02/02/2018 01:50 AM, Pkshih wrote:


Hi James,

In my experiment, unaligned-word-access may get wrong values that
are different from the value by byte-access. Actually, it can simply
verified by using 'lspci' to check PCI configuration space.

DBI read 0x70f:
_rtl8821ae_dbi_read:1127 r8 0x34f = 0x0017
_rtl8821ae_dbi_read:1131 r8 0x350 = 0x000c
_rtl8821ae_dbi_read:1136 r16 0x350 = 0x

DBI read 0x719:
_rtl8821ae_dbi_read:1127 r8 0x34d = 0x
_rtl8821ae_dbi_read:1131 r8 0x34e = 0x0002
_rtl8821ae_dbi_read:1136 r16 0x34e = 0x0200


According to the wrong and original value of 0x70f is 0xff, I think
larger L1 latency 0x70f[5:3] may be helpful. Please help to try
below patch. If it works, quirk table won't be necessary.

PK


diff --git a/rtl8821ae/hw.c b/rtl8821ae/hw.c
index 7d43ba002..e53af06ed 100644
--- a/rtl8821ae/hw.c
+++ b/rtl8821ae/hw.c
@@ -1123,7 +1123,8 @@ static u8 _rtl8821ae_dbi_read(struct rtl_priv *rtlpriv, 
u16 addr)
}
if (0 == tmp) {
read_addr = REG_DBI_RDATA + addr % 4;
-   ret = rtl_read_word(rtlpriv, read_addr);
+
+   ret = rtl_read_byte(rtlpriv, read_addr);
}
return ret;
  }
@@ -1165,7 +1166,7 @@ static void _rtl8821ae_enable_aspm_back_door(struct 
ieee80211_hw *hw)
}
  
  	tmp = _rtl8821ae_dbi_read(rtlpriv, 0x70f);

-   _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7));
+   _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7) | 0x38);
  
  	tmp = _rtl8821ae_dbi_read(rtlpriv, 0x719);

_rtl8821ae_dbi_write(rtlpriv, 0x719, tmp | BIT(3) | BIT(4));

PK,

One more question: Will we need to make the same change to rtl8723be and 
rtl8723de?

Larry

Re: rtl8821ae keep alive not set, connection lost

2018-02-02 Thread Larry Finger


On 02/02/2018 01:50 AM, Pkshih wrote:

Hi James,

In my experiment, unaligned-word-access may get wrong values that
are different from the value by byte-access. Actually, it can simply
verified by using 'lspci' to check PCI configuration space.

DBI read 0x70f:
_rtl8821ae_dbi_read:1127 r8 0x34f = 0x0017
_rtl8821ae_dbi_read:1131 r8 0x350 = 0x000c
_rtl8821ae_dbi_read:1136 r16 0x350 = 0x

DBI read 0x719:
_rtl8821ae_dbi_read:1127 r8 0x34d = 0x
_rtl8821ae_dbi_read:1131 r8 0x34e = 0x0002
_rtl8821ae_dbi_read:1136 r16 0x34e = 0x0200


According to the wrong and original value of 0x70f is 0xff, I think
larger L1 latency 0x70f[5:3] may be helpful. Please help to try
below patch. If it works, quirk table won't be necessary.

PK


diff --git a/rtl8821ae/hw.c b/rtl8821ae/hw.c
index 7d43ba002..e53af06ed 100644
--- a/rtl8821ae/hw.c
+++ b/rtl8821ae/hw.c
@@ -1123,7 +1123,8 @@ static u8 _rtl8821ae_dbi_read(struct rtl_priv *rtlpriv, 
u16 addr)
}
if (0 == tmp) {
read_addr = REG_DBI_RDATA + addr % 4;
-   ret = rtl_read_word(rtlpriv, read_addr);
+
+   ret = rtl_read_byte(rtlpriv, read_addr);
}
return ret;
  }
@@ -1165,7 +1166,7 @@ static void _rtl8821ae_enable_aspm_back_door(struct 
ieee80211_hw *hw)
}
  
  	tmp = _rtl8821ae_dbi_read(rtlpriv, 0x70f);

-   _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7));
+   _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7) | 0x38);
  
  	tmp = _rtl8821ae_dbi_read(rtlpriv, 0x719);

_rtl8821ae_dbi_write(rtlpriv, 0x719, tmp | BIT(3) | BIT(4));




PK,

This patch works perfectly on my x86_64 system. With it, the interface handled a 
10 million count flood ping with <1000 packets dropped. It has now been running 
for at least 11 hours. Good work.


Can you explain that magic 0x38? I'm quite sure that Kalle will not accept the 
patch as is. He already thinks that rtlwifi and friends already have too many 
magic numbers.


Larry

Re: rtl8821ae keep alive not set, connection lost

2018-01-31 Thread Larry Finger


On 09/12/2017 05:09 PM, James Cameron wrote:

Summary: 40b368af4b75 ("rtlwifi: Fix alignment issues") breaks
rtl8821ae keep alive, causing "Connection to AP lost" and deauth, but
why?

Wireless connection is lost after a few seconds or minutes, on every
OLPC NL3 laptop with rtl8821ae, with any stable kernel after 4.10.1,
and any kernel with 40b368af4b75.

dmesg contains

   wlp2s0: Connection to AP 2c:b0:5d:a6:86:eb lost

iw event shows

   wlp2s0: del station 2c:b0:5d:a6:86:eb
   wlp2s0 (phy #0): deauth 74:c6:3b:09:b5:0d -> 2c:b0:5d:a6:86:eb reason 4: 
Disassociated due to inactivity
   wlp2s0 (phy #0): disconnected (local request)

Workaround is to bounce the link, then reconnect;

   ip link set wlp2s0 down
   ip link set wlp2s0 up
   iw dev wlp2s0 connect qz

A nearby monitor host captures a deauthentication packet sent by the
device.

Bisection showed cause is 40b368af4b75 ("rtlwifi: Fix alignment
issues") which changes the width of DBI register read.

On the face of it, 40b368af4b75 looks correct, especially compared
against same function in rtl8723be.

I've no idea why reverting fixes the problem.  I'm hoping someone here
might speculate and suggest ways to test.

As keep alive is set through this path, my guess is that keep alive is
not being set in the device.  Or perhaps reading 16-bits perturbs
another register.  Is there a way to test?

http://dev.laptop.org/~quozl/z/1drtGD.txt dmesg of 4.13

http://dev.laptop.org/~quozl/z/1drt7c.txt dmesg with 4.13 and revert
of 40b368af4b75


James,

I'm afraid we are needing to revisit this problem again. Changing that 8-bit 
read to a 16-bit version causes an unaligned memory reference in AARCH64, thus 
we will need to re-revert. To prevent problems on systems such as yours, PK 
plans to turn off ASPM capability and backdoor in certain platforms that will be 
listed in a quirks table. Please report the output of 'dmidecode -t system' for 
you affected system(s).


We hope you will be able to test any proposed patches.

Thanks,

Larry

Re: [PATCH 02/10] rtlwifi: Add Support VHT to spec_ver

2018-01-29 Thread Larry Finger


On 01/26/2018 01:46 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

We are going to add 8822be, which is a VHT 2x2 wifi chip, so add VHT flag
to replace enumeration of chips.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


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



---
  drivers/net/wireless/realtek/rtlwifi/base.c | 6 --
  drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c | 1 +
  drivers/net/wireless/realtek/rtlwifi/wifi.h | 1 +
  3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c 
b/drivers/net/wireless/realtek/rtlwifi/base.c
index e461eed32699..a2da057d3cdd 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -244,6 +244,9 @@ static void _rtl_init_hw_vht_capab(struct ieee80211_hw *hw,
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_hal *rtlhal = rtl_hal(rtlpriv);
  
+	if (!(rtlpriv->cfg->spec_ver & RTL_SPEC_SUPPORT_VHT))

+   return;
+
if (rtlhal->hw_type == HARDWARE_TYPE_RTL8812AE ||
rtlhal->hw_type == HARDWARE_TYPE_RTL8822BE) {
u16 mcs_map;
@@ -887,8 +890,7 @@ static void _rtl_query_bandwidth_mode(struct ieee80211_hw 
*hw,
  
  	tcb_desc->packet_bw = HT_CHANNEL_WIDTH_20_40;
  
-	if (rtlpriv->rtlhal.hw_type == HARDWARE_TYPE_RTL8812AE ||

-   rtlpriv->rtlhal.hw_type == HARDWARE_TYPE_RTL8821AE) {
+   if (rtlpriv->cfg->spec_ver & RTL_SPEC_SUPPORT_VHT) {
if (mac->opmode == NL80211_IFTYPE_AP ||
mac->opmode == NL80211_IFTYPE_ADHOC ||
mac->opmode == NL80211_IFTYPE_MESH_POINT) {
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c
index ab5d462b1a3a..9bb3d9dfce79 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c
@@ -328,6 +328,7 @@ static const struct rtl_hal_cfg rtl8821ae_hal_cfg = {
.alt_fw_name = "rtlwifi/rtl8821aefw.bin",
.ops = _hal_ops,
.mod_params = _mod_params,
+   .spec_ver = RTL_SPEC_SUPPORT_VHT,
.maps[SYS_ISO_CTRL] = REG_SYS_ISO_CTRL,
.maps[SYS_FUNC_EN] = REG_SYS_FUNC_EN,
.maps[SYS_CLK] = REG_SYS_CLKR,
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h 
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index a7aacbc3984e..2df0bc316532 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -951,6 +951,7 @@ enum package_type {
  
  enum rtl_spec_ver {

RTL_SPEC_NEW_RATEID = BIT(0),   /* use ratr_table_mode_new */
+   RTL_SPEC_SUPPORT_VHT = BIT(1),  /* support VHT */
  };
  
  struct octet_string {

Re: r8822be driver

2018-01-29 Thread Larry Finger


On 01/29/2018 12:07 AM, Glenn wrote:

Hello,
My new laptop apparently has a  Real Tek R8822BE as the wifi device. The
module loads but I can not bring up the interface or do anything with
it. I think the problem is that the firmware load fails, see below. I
can not find any source for the listed firmware file or any make rules
to build it.  Possibly connected, the machine also has an R8822B as the
Bluetooth device (possibly a secondary port on the same device?) which
shows the same error. The problem is not higher up in the networking
stack as eth0 works fine.

Any help will be appreciated.

Relevant (I think) info:

uname -a:
Linux IceFalcon 4.14.13-tuned #1 SMP Tue Jan 16 20:35:41 PST 2018 x86_64
Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz GenuineIntel GNU/Linux

ifconfig wlan0:
wlan0: flags=4098  mtu 1500
 ether d4:6a:6a:55:89:39  txqueuelen 1000  (Ethernet)
 RX packets 0  bytes 0 (0.0 B)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 0  bytes 0 (0.0 B)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ifconfig wlan0 up:
SIOCSIFFLAGS: Operation not permitted

lspci -v:
3c:00.0 Network controller: Realtek Semiconductor Co., Ltd. Device b822
 Subsystem: Hewlett-Packard Company Device 831b
 Flags: bus master, fast devsel, latency 0, IRQ 131
 I/O ports at c000 [size=256]
 Memory at dc20 (64-bit, non-prefetchable) [size=64K]
 Capabilities: [40] Power Management version 3
 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
 Capabilities: [70] Express Endpoint, MSI 00
 Capabilities: [100] Advanced Error Reporting
 Capabilities: [148] Device Serial Number 00-e0-4c-ff-fe-b8-22-01
 Capabilities: [158] Latency Tolerance Reporting
 Capabilities: [160] L1 PM Substates
 Kernel driver in use: r8822be
 Kernel modules: r8822be

dmesg:
[0.259212] pci :3c:00.0: reg 0x10: [io  0xc000-0xc0ff]
[0.259235] pci :3c:00.0: reg 0x18: [mem 0xdc20-0xdc20 64bit]
[0.259352] pci :3c:00.0: supports D1 D2
[0.259353] pci :3c:00.0: PME# supported from D0 D1 D2 D3hot D3cold

[0.337550] pci_bus :3c: resource 0 [io  0xc000-0xcfff]
[0.337551] pci_bus :3c: resource 1 [mem 0xdc20-0xdc2f]

[2.148955] r8822be: module is from the staging directory, the
quality is unknown, you have been warned.

[2.173850] r8822be :3c:00.0: enabling device ( -> 0003)
[2.191530] r8822be: Using firmware rtlwifi/rtl8822befw.bin
[2.193717] r8822be :3c:00.0: Direct firmware load for
rtlwifi/rtl8822befw.bin failed with error -2
[2.194503] r8822be: Selected firmware is not available


As the log clearly states, you have not installed the firmware. It seems that 
your distro is not up to date. You could obtain it from the linux-firmware 
repository, or get it from my GitHub repo named rtlwifi_new. I will send it to 
you privately in the next E-mail.


Larry

Re: [PATCH v2 06/10] rtlwifi: Fix VHT NSS in RC

2018-01-28 Thread Larry Finger


On 01/28/2018 09:26 PM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

NSS is a argument of highest rate in RC, and it occupies bit 4-7 so use
ieee80211_rate_set_vht() to fill the values. Since it got correct rate
index, we don't need to check chips to assign NSS in set function anymore.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>
---
  drivers/net/wireless/realtek/rtlwifi/rc.c | 55 ++-
  1 file changed, 46 insertions(+), 9 deletions(-)


The switch statement is cleaner.

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



diff --git a/drivers/net/wireless/realtek/rtlwifi/rc.c 
b/drivers/net/wireless/realtek/rtlwifi/rc.c
index d1cb7d405618..6c78c6dabbdf 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rc.c
@@ -42,6 +42,23 @@ static u8 _rtl_rc_get_highest_rix(struct rtl_priv *rtlpriv,
struct rtl_phy *rtlphy = &(rtlpriv->phy);
struct rtl_sta_info *sta_entry = NULL;
u16 wireless_mode = 0;
+   u8 nss;
+   struct ieee80211_tx_rate rate;
+
+   switch (get_rf_type(rtlphy)) {
+   case RF_4T4R:
+   nss = 4;
+   break;
+   case RF_3T3R:
+   nss = 3;
+   break;
+   case RF_2T2R:
+   nss = 2;
+   break;
+   default:
+   nss = 1;
+   break;
+   }
  
  	/*

 *this rate is no use for true rate, firmware
@@ -66,28 +83,51 @@ static u8 _rtl_rc_get_highest_rix(struct rtl_priv *rtlpriv,
} else if (wireless_mode == WIRELESS_MODE_G) {
return G_MODE_MAX_RIX;
} else if (wireless_mode == WIRELESS_MODE_N_24G) {
-   if (get_rf_type(rtlphy) != RF_2T2R)
+   if (nss == 1)
return N_MODE_MCS7_RIX;
else
return N_MODE_MCS15_RIX;
} else if (wireless_mode == WIRELESS_MODE_AC_24G) {
-   return AC_MODE_MCS9_RIX;
+   if (sta->bandwidth == IEEE80211_STA_RX_BW_20) {
+   ieee80211_rate_set_vht(,
+  AC_MODE_MCS8_RIX,
+  nss);
+   goto out;
+   } else {
+   ieee80211_rate_set_vht(,
+  AC_MODE_MCS9_RIX,
+  nss);
+   goto out;
+   }
}
return 0;
} else {
if (wireless_mode == WIRELESS_MODE_A) {
return A_MODE_MAX_RIX;
} else if (wireless_mode == WIRELESS_MODE_N_5G) {
-   if (get_rf_type(rtlphy) != RF_2T2R)
+   if (nss == 1)
return N_MODE_MCS7_RIX;
else
return N_MODE_MCS15_RIX;
} else if (wireless_mode == WIRELESS_MODE_AC_5G) {
-   return AC_MODE_MCS9_RIX;
+   if (sta->bandwidth == IEEE80211_STA_RX_BW_20) {
+   ieee80211_rate_set_vht(,
+  AC_MODE_MCS8_RIX,
+  nss);
+   goto out;
+   } else {
+   ieee80211_rate_set_vht(,
+  AC_MODE_MCS9_RIX,
+  nss);
+   goto out;
+   }
}
return 0;
}
}
+
+out:
+   return rate.idx;
  }
  
  static void _rtl_rc_rate_set_series(struct rtl_priv *rtlpriv,

@@ -111,9 +151,6 @@ static void _rtl_rc_rate_set_series(struct rtl_priv 
*rtlpriv,
}
rate->count = tries;
rate->idx = rix >= 0x00 ? rix : 0x00;
-   if (rtlpriv->rtlhal.hw_type == HARDWARE_TYPE_RTL8812AE &&
-   wireless_mode == WIRELESS_MODE_AC_5G)
-   rate->idx += 0x10;/*2NSS for 8812AE*/
  
  	if (!not_data) {

if (txrc->short_preamble)
@@ -126,10 +163,10 @@ static void _rtl_rc_rate_set_series(struct rtl_priv 
*rtlpriv,

Re: [PATCH 03/10] rtlwifi: Use 6 bits as sequence number of TX report

2018-01-27 Thread Larry Finger


On 01/26/2018 01:46 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

In new design, SW_DEFINE[1:0] of tx desc are used by firmware, and the TX
report only contains SW_DEFINE[7:0]. To satisfy with all cases, driver uses
SW_DEFINE[7:2] as sequence number.
Besides, the format of tx report have been changed, so a new flag
RTL_SPEC_EXT_C2H is used to access report.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


This change was tested on an old design (RTL8188CE). No problems were observed.

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

Re: [PATCH 04/10] rtlwifi: Extend tx_power_by_rate_offset size for newer IC

2018-01-27 Thread Larry Finger


On 01/26/2018 01:46 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

In older design, the TX power is grouped into rate section (smaller array
size), but new design groups them into rate (larger array size). Thus,
we extend the size for both cases, and add compile time assertion.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>
---


I hate to see any arrays getting larger, but I can see that changes in rates 
make this inevitable. The BUILD_BUG_ON() is a good addition.


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

Re: [PATCH 05/10] rtlwifi: Add rate section and its related definition and comment

2018-01-27 Thread Larry Finger


On 01/26/2018 01:46 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

Add comments to make it to be easier to understand, and add compile time
assertions.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


This is a good improvement.

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

Re: [PATCH 06/10] rtlwifi: Fix VHT NSS in RC

2018-01-27 Thread Larry Finger


On 01/26/2018 01:46 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

NSS is a argument of highest rate in RC, and it occupies bit 4-7 so use
ieee80211_rate_set_vht() to fill the values. Since it got correct rate
index, we don't need to check chips to assign NSS in set function anymore.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>
---
  drivers/net/wireless/realtek/rtlwifi/rc.c | 49 +--
  1 file changed, 40 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rc.c 
b/drivers/net/wireless/realtek/rtlwifi/rc.c
index d1cb7d405618..396bed8d3d51 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rc.c
@@ -42,6 +42,17 @@ static u8 _rtl_rc_get_highest_rix(struct rtl_priv *rtlpriv,
struct rtl_phy *rtlphy = &(rtlpriv->phy);
struct rtl_sta_info *sta_entry = NULL;
u16 wireless_mode = 0;
+   u8 nss;
+   struct ieee80211_tx_rate rate;
+
+   if (get_rf_type(rtlphy) >= RF_4T4R)
+   nss = 4;
+   else if (get_rf_type(rtlphy) >= RF_3T3R)
+   nss = 3;
+   else if (get_rf_type(rtlphy) >= RF_2T2R)
+   nss = 2;
+   else
+   nss = 1;


As a general rule, I think that if ... else if ... else if ... else ... 
constructions should be changed to switch statements. This one is simple enough 
that there will be no complications, but keep this in mind in the future.


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

Re: [PATCH 07/10] rtlwifi: add definition radio_mask for RF and maximum bandwidth

2018-01-27 Thread Larry Finger


On 01/26/2018 01:46 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

Add rf mask definition (BIT 0, BIT 1, BIT 2, ...) that is different from
rf path definition (0, 1, 2, ...), and then combinations of rf path are
possible.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


I agree that an rf path mask is useful.

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


---
  drivers/net/wireless/realtek/rtlwifi/wifi.h | 8 
  1 file changed, 8 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h 
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 4de2ab1d5416..2e9a20273a2d 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -286,6 +286,13 @@ enum radio_path {
RF90_PATH_D = 3,
  };
  
+enum radio_mask {

+   RF_MASK_A = BIT(0),
+   RF_MASK_B = BIT(1),
+   RF_MASK_C = BIT(2),
+   RF_MASK_D = BIT(3),
+};
+
  enum regulation_txpwr_lmt {
TXPWR_LMT_FCC = 0,
TXPWR_LMT_MKK = 1,
@@ -579,6 +586,7 @@ enum ht_channel_width {
HT_CHANNEL_WIDTH_20 = 0,
HT_CHANNEL_WIDTH_20_40 = 1,
HT_CHANNEL_WIDTH_80 = 2,
+   HT_CHANNEL_WIDTH_MAX,
  };
  
  /* Ref: 802.11i sepc D10.0 7.3.2.25.1

Re: [PATCH 08/10] rtlwifi: add efuse ops for other components

2018-01-27 Thread Larry Finger


On 01/26/2018 01:46 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

The new component phydm need to access efuse content, so we prepare ops
for reference.

Signed-off-by: Tsang-Shian Lin <th...@realtek.com>
Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


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

Re: [PATCH 10/10] rtlwifi: btcoex: Add 8822be btcoex supported files for wifi only

2018-01-27 Thread Larry Finger


On 01/26/2018 01:46 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

The wifi only btcoex is used to solo card (without BT), and it is also
useful to exclude the interference with BT to make debug easier.
There are only four ops for wifi only btcoex to initialze antenna and
switch the settings while band is changed.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


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

Re: [PATCH 09/10] rtlwifi: btcoex: add routine to set default port id

2018-01-27 Thread Larry Finger


On 01/26/2018 01:46 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih 

Tell wifi and BT firmware the default port ID to set multiports' state
properly, but only 8822be needs this function currently.

Signed-off-by: Ping-Ke Shih 
---


This patch results in the following compiler warnings:

  CC [M]  drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.o
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c:1052:13: warning: 
‘halbtc_set_default_port_id_cmd’ defined but not used [-Wunused-function]

 static void halbtc_set_default_port_id_cmd(void *bt_context)
 ^~
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c:1042:13: warning: 
‘halbtc_send_wifi_port_id_cmd’ defined but not used [-Wunused-function]

 static void halbtc_send_wifi_port_id_cmd(void *bt_context)
 ^~

Something seems to be wrong. As these routines will likely be needed later, you 
need to remove the static notation and put their prototypes in a header to quiet 
Sparse.


Larry



  .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c   | 22 ++
  drivers/net/wireless/realtek/rtlwifi/wifi.h|  5 +
  2 files changed, 27 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index 1404729441a2..5e41b204f7c0 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -1039,6 +1039,28 @@ static void halbtc_fill_h2c_cmd(void *bt_context, u8 
element_id,
cmd_len, cmd_buf);
  }
  
+static void halbtc_send_wifi_port_id_cmd(void *bt_context)

+{
+   struct btc_coexist *btcoexist = (struct btc_coexist *)bt_context;
+   struct rtl_priv *rtlpriv = btcoexist->adapter;
+   u8 cmd_buf[1] = {0};/* port id [2:0] = 0 */
+
+   rtlpriv->cfg->ops->fill_h2c_cmd(rtlpriv->mac80211.hw, H2C_BT_PORT_ID,
+   1, cmd_buf);
+}
+
+static void halbtc_set_default_port_id_cmd(void *bt_context)
+{
+   struct btc_coexist *btcoexist = (struct btc_coexist *)bt_context;
+   struct rtl_priv *rtlpriv = btcoexist->adapter;
+   struct ieee80211_hw *hw = rtlpriv->mac80211.hw;
+
+   if (!rtlpriv->cfg->ops->set_default_port_id_cmd)
+   return;
+
+   rtlpriv->cfg->ops->set_default_port_id_cmd(hw);
+}
+
  static
  void halbtc_set_bt_reg(void *btc_context, u8 reg_type, u32 offset, u32 
set_val)
  {
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h 
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 0e8aae0c05c1..1c9ed28b42da 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -153,6 +153,10 @@ enum rtl8192c_h2c_cmd {
MAX_H2CCMD
  };
  
+enum {

+   H2C_BT_PORT_ID = 0x71,
+};
+
  #define GET_TX_REPORT_SN_V1(c2h)  (c2h[6])
  #define GET_TX_REPORT_ST_V1(c2h)  (c2h[0] & 0xC0)
  #define GET_TX_REPORT_RETRY_V1(c2h)   (c2h[2] & 0x3F)
@@ -2256,6 +2260,7 @@ struct rtl_hal_ops {
void (*bt_coex_off_before_lps) (struct ieee80211_hw *hw);
void (*fill_h2c_cmd) (struct ieee80211_hw *hw, u8 element_id,
  u32 cmd_len, u8 *p_cmdbuffer);
+   void (*set_default_port_id_cmd)(struct ieee80211_hw *hw);
bool (*get_btc_status) (void);
bool (*is_fw_header)(struct rtlwifi_firmware_header *hdr);
u32 (*rx_command_packet)(struct ieee80211_hw *hw,

Re: [PATCH 01/10] rtlwifi: enable mac80211 fast-tx support

2018-01-27 Thread Larry Finger


On 01/26/2018 01:46 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

Enable the mac80211 fast-tx feature, since our driver already support
hw_flags required by fast-tx and is able to let mac80211 stack to transmit
packet through fast-xmit path.

Signed-off-by: Yan-Hsuan Chuang <yhchu...@realtek.com>
Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


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

Re: [PATCH v2] bcma: Replace mdelay with usleep_range in bcma_pmu_resources_init

2018-01-26 Thread Larry Finger


On 01/26/2018 10:38 AM, Jia-Ju Bai wrote:

After checking all possible call chains to bcma_pmu_resources_init() here,
my tool finds that this function is never called in atomic context,
namely never in an interrupt handler or holding a spinlock.
Thus mdelay can be replaced with usleep_range to avoid busy wait.

This is found by a static analysis tool named DCNS written by myself.

Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
v2:
* Use usleep_range(2000, 2500), instead of (1500, 2000) in v1.

---
  drivers/bcma/driver_chipcommon_pmu.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bcma/driver_chipcommon_pmu.c 
b/drivers/bcma/driver_chipcommon_pmu.c
index f1eb4d3..478948c 100644
--- a/drivers/bcma/driver_chipcommon_pmu.c
+++ b/drivers/bcma/driver_chipcommon_pmu.c
@@ -203,7 +203,7 @@ static void bcma_pmu_resources_init(struct bcma_drv_cc *cc)
 * Add some delay; allow resources to come up and settle.
 * Delay is required for SoC (early init).
 */
-   mdelay(2);
+   usleep_range(2000, 2500);


I have no means of testing this patch, but it should be OK.

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



  }
  
  /* Disable to allow reading SPROM. Don't know the adventages of enabling it. */

Re: [PATCH] bcma: Replace mdelay with usleep_range in bcma_pmu_resources_init

2018-01-26 Thread Larry Finger


On 01/26/2018 10:13 AM, Kalle Valo wrote:

Jia-Ju Bai  writes:


After checking all possible call chains to bcma_pmu_resources_init() here,
my tool finds that this function is never called in atomic context,
namely never in an interrupt handler or holding a spinlock.
Thus mdelay can be replaced with usleep_range to avoid busy wait.

This is found by a static analysis tool named DCNS written by myself.

Signed-off-by: Jia-Ju Bai 
---
  drivers/bcma/driver_chipcommon_pmu.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bcma/driver_chipcommon_pmu.c 
b/drivers/bcma/driver_chipcommon_pmu.c
index f1eb4d3..478948c 100644
--- a/drivers/bcma/driver_chipcommon_pmu.c
+++ b/drivers/bcma/driver_chipcommon_pmu.c
@@ -203,7 +203,7 @@ static void bcma_pmu_resources_init(struct bcma_drv_cc *cc)
 * Add some delay; allow resources to come up and settle.
 * Delay is required for SoC (early init).
 */
-   mdelay(2);
+   usleep_range(1500, 2000);


I would like to have an ack from someone familiar with bcma before I
apply this.


No ack for this one.

Larry

Re: [PATCH] bcma: Replace mdelay with usleep_range in bcma_pmu_resources_init

2018-01-26 Thread Larry Finger


On 01/26/2018 03:13 AM, Jia-Ju Bai wrote:

After checking all possible call chains to bcma_pmu_resources_init() here,
my tool finds that this function is never called in atomic context,
namely never in an interrupt handler or holding a spinlock.
Thus mdelay can be replaced with usleep_range to avoid busy wait.

This is found by a static analysis tool named DCNS written by myself.

Signed-off-by: Jia-Ju Bai 
---
  drivers/bcma/driver_chipcommon_pmu.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bcma/driver_chipcommon_pmu.c 
b/drivers/bcma/driver_chipcommon_pmu.c
index f1eb4d3..478948c 100644
--- a/drivers/bcma/driver_chipcommon_pmu.c
+++ b/drivers/bcma/driver_chipcommon_pmu.c
@@ -203,7 +203,7 @@ static void bcma_pmu_resources_init(struct bcma_drv_cc *cc)
 * Add some delay; allow resources to come up and settle.
 * Delay is required for SoC (early init).
 */
-   mdelay(2);
+   usleep_range(1500, 2000);


I have no idea how critical this delay might be, but it would be safer to never 
make the sleep be shorter than the original delay. Using (2000, 2500) would be a 
better choice of arguments for usleep_range().


NACK

Larry

Re: [PATCH v2] rtlwifi: btcoex: Fix some static warnings from Sparse

2018-01-25 Thread Larry Finger


On 01/24/2018 08:49 PM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

Add 'static' or declaration to resolve the warnings, and remove two unused
functions halbtc_set_macreg() and halbtc_get_macreg() exposed when they
were made static.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>
---
The original subject of this patch is '[PATCH 07/10]' in previous
patchset, and other patches are applied excepcting to this one that Larry
suggested to add comments why two functions are revmoed, but the content is
unchanged.
---


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


  .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c   | 36 +++---
  .../realtek/rtlwifi/btcoexist/halbtcoutsrc.h   |  4 +++
  2 files changed, 15 insertions(+), 25 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index 73ef5b271f3b..1404729441a2 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -29,7 +29,7 @@
   *Debug related function
   ***/
  
-const char *const gl_btc_wifi_bw_string[] = {

+static const char *const gl_btc_wifi_bw_string[] = {
"11bg",
"HT20",
"HT40",
@@ -37,7 +37,7 @@ const char *const gl_btc_wifi_bw_string[] = {
"HT160"
  };
  
-const char *const gl_btc_wifi_freq_string[] = {

+static const char *const gl_btc_wifi_freq_string[] = {
"2.4G",
"5G"
  };
@@ -156,7 +156,7 @@ static u8 halbtc_get_wifi_central_chnl(struct btc_coexist 
*btcoexist)
return chnl;
  }
  
-u8 rtl_get_hwpg_single_ant_path(struct rtl_priv *rtlpriv)

+static u8 rtl_get_hwpg_single_ant_path(struct rtl_priv *rtlpriv)
  {
struct rtl_mod_params *mod_params = rtlpriv->cfg->mod_params;
  
@@ -171,12 +171,12 @@ u8 rtl_get_hwpg_single_ant_path(struct rtl_priv *rtlpriv)

return rtlpriv->btcoexist.btc_info.single_ant_path;
  }
  
-u8 rtl_get_hwpg_bt_type(struct rtl_priv *rtlpriv)

+static u8 rtl_get_hwpg_bt_type(struct rtl_priv *rtlpriv)
  {
return rtlpriv->btcoexist.btc_info.bt_type;
  }
  
-u8 rtl_get_hwpg_ant_num(struct rtl_priv *rtlpriv)

+static u8 rtl_get_hwpg_ant_num(struct rtl_priv *rtlpriv)
  {
struct rtl_mod_params *mod_params = rtlpriv->cfg->mod_params;
u8 num;
@@ -193,7 +193,7 @@ u8 rtl_get_hwpg_ant_num(struct rtl_priv *rtlpriv)
return num;
  }
  
-u8 rtl_get_hwpg_package_type(struct rtl_priv *rtlpriv)

+static u8 rtl_get_hwpg_package_type(struct rtl_priv *rtlpriv)
  {
struct rtl_hal *rtlhal = rtl_hal(rtlpriv);
  
@@ -504,7 +504,7 @@ static u32 halbtc_get_bt_forbidden_slot_val(void *btc_context)

return btcoexist->bt_info.bt_forb_slot_val;
  }
  
-u32 halbtc_get_wifi_link_status(struct btc_coexist *btcoexist)

+static u32 halbtc_get_wifi_link_status(struct btc_coexist *btcoexist)
  {
/* return value:
 * [31:16] => connected port number
@@ -980,7 +980,8 @@ static void halbtc_write_4byte(void *bt_context, u32 
reg_addr, u32 data)
rtl_write_dword(rtlpriv, reg_addr, data);
  }
  
-void halbtc_write_local_reg_1byte(void *btc_context, u32 reg_addr, u8 data)

+static void halbtc_write_local_reg_1byte(void *btc_context, u32 reg_addr,
+u8 data)
  {
struct btc_coexist *btcoexist = (struct btc_coexist *)btc_context;
struct rtl_priv *rtlpriv = btcoexist->adapter;
@@ -993,22 +994,6 @@ void halbtc_write_local_reg_1byte(void *btc_context, u32 
reg_addr, u8 data)
rtl_write_byte(rtlpriv, reg_addr, data);
  }
  
-void halbtc_set_macreg(void *btc_context, u32 reg_addr, u32 bit_mask, u32 data)

-{
-   struct btc_coexist *btcoexist = (struct btc_coexist *)btc_context;
-   struct rtl_priv *rtlpriv = btcoexist->adapter;
-
-   rtl_set_bbreg(rtlpriv->mac80211.hw, reg_addr, bit_mask, data);
-}
-
-u32 halbtc_get_macreg(void *btc_context, u32 reg_addr, u32 bit_mask)
-{
-   struct btc_coexist *btcoexist = (struct btc_coexist *)btc_context;
-   struct rtl_priv *rtlpriv = btcoexist->adapter;
-
-   return rtl_get_bbreg(rtlpriv->mac80211.hw, reg_addr, bit_mask);
-}
-
  static void halbtc_set_bbreg(void *bt_context, u32 reg_addr, u32 bit_mask,
 u32 data)
  {
@@ -1054,6 +1039,7 @@ static void halbtc_fill_h2c_cmd(void *bt_context, u8 
element_id,
cmd_len, cmd_buf);
  }
  
+static

  void halbtc_set_bt_reg(void *btc_context, u8 reg_type, u32 offset, u32 
set_val)
  {
struct btc_coexist *btcoexist = (struct btc_coexist *)btc_context;
@@ -1093,7 +1079,7 @@ static void halbtc_display_dbg_msg(void *bt_context, u8 
disp_type,
}
  }
  
-bool halbtc_under_ips(str

Re: [PATCH 02/10] rtlwifi: btcoex: Add switch band notify for btc

2018-01-22 Thread Larry Finger


On 01/19/2018 12:45 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

BT shares 2.4G band but not 5G band, so inform current band to btcoex to
setup antenna properly.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


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


---
  .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c   | 13 +++
  .../realtek/rtlwifi/btcoexist/halbtcoutsrc.h   |  9 
  .../wireless/realtek/rtlwifi/btcoexist/rtl_btc.c   | 27 ++
  .../wireless/realtek/rtlwifi/btcoexist/rtl_btc.h   |  2 ++
  drivers/net/wireless/realtek/rtlwifi/wifi.h|  2 ++
  5 files changed, 53 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index c335f06eb13b..b51189ae1bfd 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -1910,3 +1910,16 @@ void exhalbtc_display_bt_coex_info(struct btc_coexist 
*btcoexist,
  
  	halbtc_normal_low_power(btcoexist);

  }
+
+void exhalbtc_switch_band_notify(struct btc_coexist *btcoexist, u8 type)
+{
+   if (!halbtc_is_bt_coexist_available(btcoexist))
+   return;
+
+   if (btcoexist->manual_control)
+   return;
+
+   halbtc_leave_low_power(btcoexist);
+
+   halbtc_normal_low_power(btcoexist);
+}
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
index bc854ff2ab8a..cd3925d34854 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
@@ -385,6 +385,14 @@ enum btc_notify_type_scan {
BTC_SCAN_MAX
  };
  
+enum btc_notify_type_switchband {

+   BTC_NOT_SWITCH = 0x0,
+   BTC_SWITCH_TO_24G = 0x1,
+   BTC_SWITCH_TO_5G = 0x2,
+   BTC_SWITCH_TO_24G_NOFORSCAN = 0x3,
+   BTC_SWITCH_MAX
+};
+
  enum btc_notify_type_associate {
BTC_ASSOCIATE_FINISH = 0x0,
BTC_ASSOCIATE_START = 0x1,
@@ -659,6 +667,7 @@ void exhalbtc_set_chip_type(struct btc_coexist *btcoexist, 
u8 chip_type);
  void exhalbtc_set_ant_num(struct rtl_priv *rtlpriv, u8 type, u8 ant_num);
  void exhalbtc_display_bt_coex_info(struct btc_coexist *btcoexist,
   struct seq_file *m);
+void exhalbtc_switch_band_notify(struct btc_coexist *btcoexist, u8 type);
  void exhalbtc_signal_compensation(struct btc_coexist *btcoexist,
  u8 *rssi_wifi, u8 *rssi_bt);
  void exhalbtc_lps_leave(struct btc_coexist *btcoexist);
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/rtl_btc.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/rtl_btc.c
index 714c0de099e5..bbc9517260b3 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/rtl_btc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/rtl_btc.c
@@ -48,6 +48,7 @@ static struct rtl_btc_ops rtl_btc_operation = {
.btc_is_disable_edca_turbo = rtl_btc_is_disable_edca_turbo,
.btc_is_bt_disabled = rtl_btc_is_bt_disabled,
.btc_special_packet_notify = rtl_btc_special_packet_notify,
+   .btc_switch_band_notify = rtl_btc_switch_band_notify,
.btc_record_pwr_mode = rtl_btc_record_pwr_mode,
.btc_get_lps_val = rtl_btc_get_lps_val,
.btc_get_rpwm_val = rtl_btc_get_rpwm_val,
@@ -423,6 +424,32 @@ void rtl_btc_special_packet_notify(struct rtl_priv 
*rtlpriv, u8 pkt_type)
return exhalbtc_special_packet_notify(btcoexist, pkt_type);
  }
  
+void rtl_btc_switch_band_notify(struct rtl_priv *rtlpriv, u8 band_type,

+   bool scanning)
+{
+   struct btc_coexist *btcoexist = rtl_btc_coexist(rtlpriv);
+   u8 type = BTC_NOT_SWITCH;
+
+   if (!btcoexist)
+   return;
+
+   switch (band_type) {
+   case BAND_ON_2_4G:
+   if (scanning)
+   type = BTC_SWITCH_TO_24G;
+   else
+   type = BTC_SWITCH_TO_24G_NOFORSCAN;
+   break;
+
+   case BAND_ON_5G:
+   type = BTC_SWITCH_TO_5G;
+   break;
+   }
+
+   if (type != BTC_NOT_SWITCH)
+   exhalbtc_switch_band_notify(btcoexist, type);
+}
+
  struct rtl_btc_ops *rtl_btc_get_ops_pointer(void)
  {
return _btc_operation;
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/rtl_btc.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/rtl_btc.h
index 8c5098266039..1d98741ae874 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/rtl_btc.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/rtl_btc.h
@@ -46,6 +46,8 @@ bool rtl_btc_is_limited_dig(struct rtl_priv *rtlpriv);
  bool rtl_btc_is_disable_edca_turbo(struct rtl_priv *rtlpriv);
  bool rtl_btc_is_bt_disabled(struct rtl_priv *rtlpriv);
  void rtl_btc_special_packet_n

Re: [PATCH 05/10] rtlwifi: btcoex: Add wifi_only series ops to control solo card

2018-01-22 Thread Larry Finger


On 01/19/2018 12:45 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

Originally, btcoex controls the antenna of combo card, but solo card
is also needed to setup properly. The new ops are named with suffix
'_wifi_only' opposited to original btc_ops, and new structures and
definitions are also introduced. The wifi_only oly contains four ops that
are initial variable, hw config, scan notify, and switch band notify.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>
---
  .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c   | 48 +++
  .../realtek/rtlwifi/btcoexist/halbtcoutsrc.h   | 47 +++
  .../wireless/realtek/rtlwifi/btcoexist/rtl_btc.c   | 54 +-
  .../wireless/realtek/rtlwifi/btcoexist/rtl_btc.h   |  5 ++
  drivers/net/wireless/realtek/rtlwifi/core.c|  6 +++
  drivers/net/wireless/realtek/rtlwifi/pci.c |  8 +++-
  drivers/net/wireless/realtek/rtlwifi/wifi.h|  7 +++
  7 files changed, 172 insertions(+), 3 deletions(-)


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

Re: [PATCH 10/10] rtlwifi: Add spec_ver to check whether use new rate-id or not

2018-01-22 Thread Larry Finger


On 01/19/2018 12:45 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

The field spec_ver is IC's specification mask for common code to do proper
process to specified IC. This commit add a field new rate ID for new
generation IC.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


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


---
  drivers/net/wireless/realtek/rtlwifi/base.c | 126 +---
  drivers/net/wireless/realtek/rtlwifi/base.h |   2 +
  drivers/net/wireless/realtek/rtlwifi/wifi.h |   5 ++
  3 files changed, 121 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c 
b/drivers/net/wireless/realtek/rtlwifi/base.c
index 7fa435e95c0e..d6c03bd5cc65 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -698,14 +698,94 @@ static void _rtl_query_protection_mode(struct 
ieee80211_hw *hw,
}
  }
  
+u8 rtl_mrate_idx_to_arfr_id(struct ieee80211_hw *hw, u8 rate_index,

+   enum wireless_mode wirelessmode)
+{
+   struct rtl_priv *rtlpriv = rtl_priv(hw);
+   struct rtl_phy *rtlphy = >phy;
+   u8 ret = 0;
+
+   switch (rate_index) {
+   case RATR_INX_WIRELESS_NGB:
+   if (rtlphy->rf_type == RF_1T1R)
+   ret = RATEID_IDX_BGN_40M_1SS;
+   else
+   ret = RATEID_IDX_BGN_40M_2SS;
+   ; break;
+   case RATR_INX_WIRELESS_N:
+   case RATR_INX_WIRELESS_NG:
+   if (rtlphy->rf_type == RF_1T1R)
+   ret = RATEID_IDX_GN_N1SS;
+   else
+   ret = RATEID_IDX_GN_N2SS;
+   ; break;
+   case RATR_INX_WIRELESS_NB:
+   if (rtlphy->rf_type == RF_1T1R)
+   ret = RATEID_IDX_BGN_20M_1SS_BN;
+   else
+   ret = RATEID_IDX_BGN_20M_2SS_BN;
+   ; break;
+   case RATR_INX_WIRELESS_GB:
+   ret = RATEID_IDX_BG;
+   break;
+   case RATR_INX_WIRELESS_G:
+   ret = RATEID_IDX_G;
+   break;
+   case RATR_INX_WIRELESS_B:
+   ret = RATEID_IDX_B;
+   break;
+   case RATR_INX_WIRELESS_MC:
+   if (wirelessmode == WIRELESS_MODE_B ||
+   wirelessmode == WIRELESS_MODE_G ||
+   wirelessmode == WIRELESS_MODE_N_24G ||
+   wirelessmode == WIRELESS_MODE_AC_24G)
+   ret = RATEID_IDX_BG;
+   else
+   ret = RATEID_IDX_G;
+   break;
+   case RATR_INX_WIRELESS_AC_5N:
+   if (rtlphy->rf_type == RF_1T1R)
+   ret = RATEID_IDX_VHT_1SS;
+   else
+   ret = RATEID_IDX_VHT_2SS;
+   break;
+   case RATR_INX_WIRELESS_AC_24N:
+   if (rtlphy->current_chan_bw == HT_CHANNEL_WIDTH_80) {
+   if (rtlphy->rf_type == RF_1T1R)
+   ret = RATEID_IDX_VHT_1SS;
+   else
+   ret = RATEID_IDX_VHT_2SS;
+   } else {
+   if (rtlphy->rf_type == RF_1T1R)
+   ret = RATEID_IDX_MIX1;
+   else
+   ret = RATEID_IDX_MIX2;
+   }
+   break;
+   default:
+   ret = RATEID_IDX_BGN_40M_2SS;
+   break;
+   }
+   return ret;
+}
+EXPORT_SYMBOL(rtl_mrate_idx_to_arfr_id);
+
  static void _rtl_txrate_selectmode(struct ieee80211_hw *hw,
   struct ieee80211_sta *sta,
   struct rtl_tcb_desc *tcb_desc)
  {
+#define SET_RATE_ID(rate_id)   \
+   ({typeof(rate_id) _id = rate_id;\
+ ((rtlpriv->cfg->spec_ver & RTL_SPEC_NEW_RATEID) ?   \
+   rtl_mrate_idx_to_arfr_id(hw, _id,   \
+   (sta_entry ? sta_entry->wireless_mode :  \
+WIRELESS_MODE_G)) :\
+   _id); })
+
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
struct rtl_sta_info *sta_entry = NULL;
-   u8 ratr_index = 7;
+   u8 ratr_index = SET_RATE_ID(RATR_INX_WIRELESS_MC);
  
  	if (sta) {

sta_entry = (struct rtl_sta_info *) sta->drv_priv;
@@ -720,7 +800,8 @@ static void _rtl_txrate_selectmode(struct ieee80211_hw *hw,
tcb_desc->hw_rate =
rtlpriv->cfg->maps[RTL_RC_CCK_RATE2M];
tcb_desc->use_driver_rate = 1;
-   tcb_desc->ratr_index = R

Re: [PATCH 09/10] rtlwifi: Add ratr_table for newer IC

2018-01-22 Thread Larry Finger


On 01/19/2018 12:45 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

New generation ICs will support 11ac, 5G, n-NSS, etc, so we define a set of
rate ID.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>
---
  drivers/net/wireless/realtek/rtlwifi/wifi.h | 18 ++
  1 file changed, 18 insertions(+)


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



diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h 
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 111f81b44c1b..2d8e96896f49 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -873,6 +873,24 @@ enum ratr_table_mode {
RATR_INX_WIRELESS_AC_24N = 9,
  };
  
+enum ratr_table_mode_new {

+   RATEID_IDX_BGN_40M_2SS = 0,
+   RATEID_IDX_BGN_40M_1SS = 1,
+   RATEID_IDX_BGN_20M_2SS_BN = 2,
+   RATEID_IDX_BGN_20M_1SS_BN = 3,
+   RATEID_IDX_GN_N2SS = 4,
+   RATEID_IDX_GN_N1SS = 5,
+   RATEID_IDX_BG = 6,
+   RATEID_IDX_G = 7,
+   RATEID_IDX_B = 8,
+   RATEID_IDX_VHT_2SS = 9,
+   RATEID_IDX_VHT_1SS = 10,
+   RATEID_IDX_MIX1 = 11,
+   RATEID_IDX_MIX2 = 12,
+   RATEID_IDX_VHT_3SS = 13,
+   RATEID_IDX_BGN_3SS = 14,
+};
+
  enum rtl_link_state {
MAC80211_NOLINK = 0,
MAC80211_LINKING = 1,

Re: [PATCH 04/10] rtlwifi: btcoex: add scan_notify within ips_notify if RFON

2018-01-22 Thread Larry Finger


On 01/19/2018 12:45 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

Three steps of connection procedure are scan, enter/leave IPS, auth.
There is no scan between leaving IPS and sending auth, but btcoex use scan
as an important clue that indicates user is going to connect. So add scan
notifications in ips_notify to correct btcoex's state.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>


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


---
  drivers/net/wireless/realtek/rtlwifi/btcoexist/rtl_btc.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/rtl_btc.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/rtl_btc.c
index bbc9517260b3..0111ab9e7b05 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/rtl_btc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/rtl_btc.c
@@ -212,6 +212,14 @@ void rtl_btc_ips_notify(struct rtl_priv *rtlpriv, u8 type)
return;
  
  	exhalbtc_ips_notify(btcoexist, type);

+
+   if (type == ERFON) {
+   /* In some situation, it doesn't scan after leaving IPS, and
+* this will cause btcoex in wrong state.
+*/
+   exhalbtc_scan_notify(btcoexist, 1);
+   exhalbtc_scan_notify(btcoexist, 0);
+   }
  }
  
  void rtl_btc_lps_notify(struct rtl_priv *rtlpriv, u8 type)

Re: [PATCH 03/10] rtlwifi: btcoex: Add variable ant_div_cfg to support antenna diversity

2018-01-22 Thread Larry Finger


On 01/19/2018 12:45 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

The variable will be used by btcoex of 8822be, so we prepare this variable
in advance.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>
---
  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 1 +
  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h | 1 +
  2 files changed, 2 insertions(+)


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



diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index b51189ae1bfd..8dc646190e35 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -1310,6 +1310,7 @@ bool exhalbtc_bind_bt_coex_withadapter(void *adapter)
 "[BTCoex], Package Type = Non-TFBGA\n");
  
  	btcoexist->board_info.rfe_type = rtl_get_hwpg_rfe_type(rtlpriv);

+   btcoexist->board_info.ant_div_cfg = 0;
  
  	return true;

  }
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
index cd3925d34854..e0818f6efb87 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
@@ -153,6 +153,7 @@ struct btc_board_info {
bool tfbga_package;
  
  	u8 rfe_type;

+   u8 ant_div_cfg;
  };
  
  enum btc_dbg_opcode {

Re: [PATCH 01/10] rtlwifi: btcoex: extend get_wifi_bw to support bandwidth 80M

2018-01-19 Thread Larry Finger


On 01/19/2018 12:45 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

The rtlwifi newer ICs support 80M bandwidth in 5G band, so extend
get_wifi_bw() to know bandwidth 80M that helps btcoex to make correct
decisions.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>
---
  .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c   | 37 +-
  .../realtek/rtlwifi/btcoexist/halbtcoutsrc.h   |  1 +
  2 files changed, 16 insertions(+), 22 deletions(-)


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



diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index af8f3778dc91..c335f06eb13b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -95,21 +95,6 @@ static bool is_any_client_connect_to_ap(struct btc_coexist 
*btcoexist)
return false;
  }
  
-static bool halbtc_is_bt40(struct rtl_priv *adapter)

-{
-   struct rtl_priv *rtlpriv = adapter;
-   struct rtl_phy *rtlphy = &(rtlpriv->phy);
-   bool is_ht40 = true;
-   enum ht_channel_width bw = rtlphy->current_chan_bw;
-
-   if (bw == HT_CHANNEL_WIDTH_20)
-   is_ht40 = false;
-   else if (bw == HT_CHANNEL_WIDTH_20_40)
-   is_ht40 = true;
-
-   return is_ht40;
-}
-
  static bool halbtc_legacy(struct rtl_priv *adapter)
  {
struct rtl_priv *rtlpriv = adapter;
@@ -135,18 +120,26 @@ bool halbtc_is_wifi_uplink(struct rtl_priv *adapter)
  
  static u32 halbtc_get_wifi_bw(struct btc_coexist *btcoexist)

  {
-   struct rtl_priv *rtlpriv =
-   (struct rtl_priv *)btcoexist->adapter;
+   struct rtl_priv *rtlpriv = btcoexist->adapter;
+   struct rtl_phy *rtlphy = >phy;
u32 wifi_bw = BTC_WIFI_BW_HT20;
  
-	if (halbtc_is_bt40(rtlpriv)) {

-   wifi_bw = BTC_WIFI_BW_HT40;
+   if (halbtc_legacy(rtlpriv)) {
+   wifi_bw = BTC_WIFI_BW_LEGACY;
} else {
-   if (halbtc_legacy(rtlpriv))
-   wifi_bw = BTC_WIFI_BW_LEGACY;
-   else
+   switch (rtlphy->current_chan_bw) {
+   case HT_CHANNEL_WIDTH_20:
wifi_bw = BTC_WIFI_BW_HT20;
+   break;
+   case HT_CHANNEL_WIDTH_20_40:
+   wifi_bw = BTC_WIFI_BW_HT40;
+   break;
+   case HT_CHANNEL_WIDTH_80:
+   wifi_bw = BTC_WIFI_BW_HT80;
+   break;
+   }
}
+
return wifi_bw;
  }
  
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h

index 57caaf130a46..bc854ff2ab8a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
@@ -190,6 +190,7 @@ enum btc_wifi_bw_mode {
BTC_WIFI_BW_LEGACY = 0x0,
BTC_WIFI_BW_HT20 = 0x1,
BTC_WIFI_BW_HT40 = 0x2,
+   BTC_WIFI_BW_HT80 = 0x3,
BTC_WIFI_BW_MAX
  };

Re: [PATCH 06/10] rtlwifi: btcoex: add boolean variables dbg_mode

2018-01-19 Thread Larry Finger


On 01/19/2018 12:45 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

In files halbtc8822b1ant.c and halbtc8822b2ant.c that I will submit later,
two undesired directives named BT_8822B_1ANT_COEX_DBG and
BT_8822B_2ANT_COEX_DBG will be replaced by boolean variables.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>
---
  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
index 6c145313c615..1c6019be793a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
@@ -583,6 +583,8 @@ struct btc_coexist {
 */
bool auto_report_1ant;
bool auto_report_2ant;
+   bool dbg_mode_1ant;
+   bool dbg_mode_2ant;
bool initilized;
bool stop_coex_dm;
bool manual_control;


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

Re: [PATCH 07/10] rtlwifi: btcoex: Fix some static warnings from Sparse

2018-01-19 Thread Larry Finger


On 01/19/2018 12:45 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih 

Add 'static' or declaration to resolve the warnings.

Signed-off-by: Ping-Ke Shih 
---
  .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c   | 36 +++---
  .../realtek/rtlwifi/btcoexist/halbtcoutsrc.h   |  4 +++
  2 files changed, 15 insertions(+), 25 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index 73ef5b271f3b..1404729441a2 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -29,7 +29,7 @@
   *Debug related function
   ***/
  
-const char *const gl_btc_wifi_bw_string[] = {

+static const char *const gl_btc_wifi_bw_string[] = {
"11bg",
"HT20",
"HT40",
@@ -37,7 +37,7 @@ const char *const gl_btc_wifi_bw_string[] = {
"HT160"
  };
  
-const char *const gl_btc_wifi_freq_string[] = {

+static const char *const gl_btc_wifi_freq_string[] = {
"2.4G",
"5G"
  };
@@ -156,7 +156,7 @@ static u8 halbtc_get_wifi_central_chnl(struct btc_coexist 
*btcoexist)
return chnl;
  }
  
-u8 rtl_get_hwpg_single_ant_path(struct rtl_priv *rtlpriv)

+static u8 rtl_get_hwpg_single_ant_path(struct rtl_priv *rtlpriv)
  {
struct rtl_mod_params *mod_params = rtlpriv->cfg->mod_params;
  
@@ -171,12 +171,12 @@ u8 rtl_get_hwpg_single_ant_path(struct rtl_priv *rtlpriv)

return rtlpriv->btcoexist.btc_info.single_ant_path;
  }
  
-u8 rtl_get_hwpg_bt_type(struct rtl_priv *rtlpriv)

+static u8 rtl_get_hwpg_bt_type(struct rtl_priv *rtlpriv)
  {
return rtlpriv->btcoexist.btc_info.bt_type;
  }
  
-u8 rtl_get_hwpg_ant_num(struct rtl_priv *rtlpriv)

+static u8 rtl_get_hwpg_ant_num(struct rtl_priv *rtlpriv)
  {
struct rtl_mod_params *mod_params = rtlpriv->cfg->mod_params;
u8 num;
@@ -193,7 +193,7 @@ u8 rtl_get_hwpg_ant_num(struct rtl_priv *rtlpriv)
return num;
  }
  
-u8 rtl_get_hwpg_package_type(struct rtl_priv *rtlpriv)

+static u8 rtl_get_hwpg_package_type(struct rtl_priv *rtlpriv)
  {
struct rtl_hal *rtlhal = rtl_hal(rtlpriv);
  
@@ -504,7 +504,7 @@ static u32 halbtc_get_bt_forbidden_slot_val(void *btc_context)

return btcoexist->bt_info.bt_forb_slot_val;
  }
  
-u32 halbtc_get_wifi_link_status(struct btc_coexist *btcoexist)

+static u32 halbtc_get_wifi_link_status(struct btc_coexist *btcoexist)
  {
/* return value:
 * [31:16] => connected port number
@@ -980,7 +980,8 @@ static void halbtc_write_4byte(void *bt_context, u32 
reg_addr, u32 data)
rtl_write_dword(rtlpriv, reg_addr, data);
  }
  
-void halbtc_write_local_reg_1byte(void *btc_context, u32 reg_addr, u8 data)

+static void halbtc_write_local_reg_1byte(void *btc_context, u32 reg_addr,
+u8 data)
  {
struct btc_coexist *btcoexist = (struct btc_coexist *)btc_context;
struct rtl_priv *rtlpriv = btcoexist->adapter;
@@ -993,22 +994,6 @@ void halbtc_write_local_reg_1byte(void *btc_context, u32 
reg_addr, u8 data)
rtl_write_byte(rtlpriv, reg_addr, data);
  }
  
-void halbtc_set_macreg(void *btc_context, u32 reg_addr, u32 bit_mask, u32 data)

-{
-   struct btc_coexist *btcoexist = (struct btc_coexist *)btc_context;
-   struct rtl_priv *rtlpriv = btcoexist->adapter;
-
-   rtl_set_bbreg(rtlpriv->mac80211.hw, reg_addr, bit_mask, data);
-}
-
-u32 halbtc_get_macreg(void *btc_context, u32 reg_addr, u32 bit_mask)
-{
-   struct btc_coexist *btcoexist = (struct btc_coexist *)btc_context;
-   struct rtl_priv *rtlpriv = btcoexist->adapter;
-
-   return rtl_get_bbreg(rtlpriv->mac80211.hw, reg_addr, bit_mask);
-}
-


Should we conclude that the two routines above are not used, and that fact was 
exposed when they were made static? If so, please note that they were deleted in 
the commit message.


Larry

Re: [PATCH 08/10] rtlwifi: 8822be has to report vht capability to mac80211

2018-01-19 Thread Larry Finger


On 01/19/2018 12:45 AM, pks...@realtek.com wrote:

From: Ping-Ke Shih <pks...@realtek.com>

8822be is 2x2 11ac wifi chip, so report VHT capability to mac80211.

Signed-off-by: Ping-Ke Shih <pks...@realtek.com>
---
  drivers/net/wireless/realtek/rtlwifi/base.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)


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




diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c 
b/drivers/net/wireless/realtek/rtlwifi/base.c
index c8ebf738cb2b..7fa435e95c0e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -244,7 +244,8 @@ static void _rtl_init_hw_vht_capab(struct ieee80211_hw *hw,
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_hal *rtlhal = rtl_hal(rtlpriv);
  
-	if (rtlhal->hw_type == HARDWARE_TYPE_RTL8812AE) {

+   if (rtlhal->hw_type == HARDWARE_TYPE_RTL8812AE ||
+   rtlhal->hw_type == HARDWARE_TYPE_RTL8822BE) {
u16 mcs_map;
  
  		vht_cap->vht_supported = true;

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 1305 matches

Mail list logo