Re: [PATCH 3/3] wcn36xx: don't delete invalid bss indices

[Ramon Fried]

On 4/3/2018 7:51 PM, Daniel Mack wrote:
> The firmware code cannot cope with requests to remove BSS indices that have
> not previously been added. This primarily happens when the device is
> suspended and then resumed. ieee80211_reconfig() then calls into
> wcn36xx_bss_info_changed() with an empty bssid and BSS_CHANGED_BSSID set,
> which subsequently leads to a firmware crash:
>
> [   43.647928] qcom-wcnss-pil a204000.wcnss: fatal error received: 
> halMsg.c:4964:halMsg_DelBss: Invalid BSSIndex 0
> [   43.647959] remoteproc remoteproc0: crash detected in a204000.wcnss: type 
> fatal error
>
> To fix this, set bss_index to WCN36XX_HAL_BSS_INVALID_IDX for all bss
> that have not been configured in the firmware, and don't call into the
> firmware with invalid indices.
>
> Signed-off-by: Daniel Mack 
> ---
>  drivers/net/wireless/ath/wcn36xx/main.c | 1 +
>  drivers/net/wireless/ath/wcn36xx/smd.c  | 6 ++
>  2 files changed, 7 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c 
> b/drivers/net/wireless/ath/wcn36xx/main.c
> index 69d6be59d97f..32bbd6e2fd09 100644
> --- a/drivers/net/wireless/ath/wcn36xx/main.c
> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
> @@ -953,6 +953,7 @@ static int wcn36xx_add_interface(struct ieee80211_hw *hw,
>  
>   mutex_lock(>conf_mutex);
>  
> + vif_priv->bss_index = WCN36XX_HAL_BSS_INVALID_IDX;
>   list_add(_priv->list, >vif_list);
>   wcn36xx_smd_add_sta_self(wcn, vif);
>  
> diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c 
> b/drivers/net/wireless/ath/wcn36xx/smd.c
> index 8932af5e4d8d..5be07e40a86d 100644
> --- a/drivers/net/wireless/ath/wcn36xx/smd.c
> +++ b/drivers/net/wireless/ath/wcn36xx/smd.c
> @@ -1446,6 +1446,10 @@ int wcn36xx_smd_delete_bss(struct wcn36xx *wcn, struct 
> ieee80211_vif *vif)
>   int ret = 0;
>  
>   mutex_lock(>hal_mutex);
> +
> + if (vif_priv->bss_index == WCN36XX_HAL_BSS_INVALID_IDX)
> + goto out;
> +
>   INIT_HAL_MSG(msg_body, WCN36XX_HAL_DELETE_BSS_REQ);
>  
>   msg_body.bss_index = vif_priv->bss_index;
> @@ -1464,6 +1468,8 @@ int wcn36xx_smd_delete_bss(struct wcn36xx *wcn, struct 
> ieee80211_vif *vif)
>   wcn36xx_err("hal_delete_bss response failed err=%d\n", ret);
>   goto out;
>   }
> +
> + vif_priv->bss_index = WCN36XX_HAL_BSS_INVALID_IDX;
>  out:
>   mutex_unlock(>hal_mutex);
>   return ret;
Interesting. I have never seen this bug before.
Do you have a way of recreating it so I can test it on my side ?

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 1/3] wcn36xx: check for DMA mapping errors in wcn36xx_dxe_tx_frame()

[Ramon Fried]

On 4/3/2018 7:51 PM, Daniel Mack wrote:
> Bail out if the mapping fails. Even though this hasn't occured during
> tests, this unlikely case should still be handled.
>
> Signed-off-by: Daniel Mack 
> ---
>  drivers/net/wireless/ath/wcn36xx/dxe.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/wcn36xx/dxe.c 
> b/drivers/net/wireless/ath/wcn36xx/dxe.c
> index 6e9a3583c447..e8ad8f989ccd 100644
> --- a/drivers/net/wireless/ath/wcn36xx/dxe.c
> +++ b/drivers/net/wireless/ath/wcn36xx/dxe.c
> @@ -707,6 +707,11 @@ int wcn36xx_dxe_tx_frame(struct wcn36xx *wcn,
> ctl->skb->data,
> ctl->skb->len,
> DMA_TO_DEVICE);
> + if (dma_mapping_error(wcn->dev, desc->src_addr_l)) {
> + dev_err(wcn->dev, "unable to DMA map src_addr_l\n");
> + ret = -ENOMEM;
> + goto unlock;
> + }
>  
>   desc->dst_addr_l = ch->dxe_wq;
>   desc->fr_len = ctl->skb->len;
I have the exact patch ready for submission, you got a head of me :)
Acked-by: Ramon Fried 

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 00/11] staging: wilc1000: fix for checkpatch and handled malloc memory properly

[Ajay Singh]

Hi Greg,

On Wed, 28 Mar 2018 13:31:01 +0200
Greg KH  wrote:

> On Tue, Mar 27, 2018 at 12:52:13PM +0530, Ajay Singh wrote:
> > 
> > Please let me know, in case I have to rework and resubmit this
> > patch series to make them into staging branch.  
> 
> You already sent a v2 series for this, right?  Why respond to the v1
> set?
> 

Sorry for late reply.

V2 series was not sent for this patchset. No code updates were 
submitted for this patch series. It's an independent patch series
with 11 patches and had changes different from other patch series.

Just for information, the v2 patch series was submitted for different
patch series which had 9 patches.

Please let me know if any other information/action is required from
my side to include this patch series to staging.


Regards,
Ajay

[PATCH 2/3] mwifiex: always configure firmware mac address during changing virtual interface

[Xinming Hu]

When interface type changed, firmware using a new connction pointer.
We need Re-configure the mac address.

Signed-off-by: Xinming Hu 
---
 drivers/net/wireless/marvell/mwifiex/main.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index cd3fc4e..cef4dea8 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -982,9 +982,6 @@ int mwifiex_set_mac_address(struct mwifiex_private *priv,
mac_addr ^= BIT_ULL(priv->bss_type + 8);
mac_addr += priv->bss_num;
}
-
-   if (mac_addr == old_mac_addr)
-   goto done;
}
 
u64_to_ether_addr(mac_addr, priv->curr_addr);
@@ -1000,7 +997,6 @@ int mwifiex_set_mac_address(struct mwifiex_private *priv,
return ret;
}
 
-done:
ether_addr_copy(dev->dev_addr, priv->curr_addr);
return 0;
 }
-- 
1.9.1

[PATCH 1/3] mwifiex: make firmware mac address consistent with host configuration

[Xinming Hu]

For user configurated mac address, directly set to firmware with no change.

Signed-off-by: Xinming Hu 
---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c |  4 +--
 drivers/net/wireless/marvell/mwifiex/main.c | 38 ++---
 drivers/net/wireless/marvell/mwifiex/main.h |  3 +-
 3 files changed, 26 insertions(+), 19 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 3fc6f29..8b2aab1 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -915,7 +915,7 @@ static int mwifiex_deinit_priv_params(struct 
mwifiex_private *priv)
adapter->rx_locked = false;
spin_unlock_irqrestore(>rx_proc_lock, flags);
 
-   mwifiex_set_mac_address(priv, dev);
+   mwifiex_set_mac_address(priv, dev, false, NULL);
 
return 0;
 }
@@ -2959,7 +2959,7 @@ struct wireless_dev *mwifiex_add_virtual_intf(struct 
wiphy *wiphy,
priv->netdev = dev;
 
if (!adapter->mfg_mode) {
-   mwifiex_set_mac_address(priv, dev);
+   mwifiex_set_mac_address(priv, dev, false, NULL);
 
ret = mwifiex_send_cmd(priv, HostCmd_CMD_SET_BSS_MODE,
   HostCmd_ACT_GEN_SET, 0, NULL, true);
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index 20737f5..cd3fc4e 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -957,28 +957,35 @@ struct sk_buff *
 }
 
 int mwifiex_set_mac_address(struct mwifiex_private *priv,
-   struct net_device *dev)
+   struct net_device *dev, bool external,
+   u8 *new_mac)
 {
int ret;
u64 mac_addr, old_mac_addr;
 
-   if (priv->bss_type == MWIFIEX_BSS_TYPE_ANY)
-   return -ENOTSUPP;
+   old_mac_addr = ether_addr_to_u64(priv->curr_addr);
 
-   mac_addr = ether_addr_to_u64(priv->curr_addr);
-   old_mac_addr = mac_addr;
+   if (external) {
+   mac_addr = ether_addr_to_u64(new_mac);
+   } else {
+   /* Internal mac address change */
+   if (priv->bss_type == MWIFIEX_BSS_TYPE_ANY)
+   return -ENOTSUPP;
 
-   if (priv->bss_type == MWIFIEX_BSS_TYPE_P2P)
-   mac_addr |= BIT_ULL(MWIFIEX_MAC_LOCAL_ADMIN_BIT);
+   mac_addr = old_mac_addr;
 
-   if (mwifiex_get_intf_num(priv->adapter, priv->bss_type) > 1) {
-   /* Set mac address based on bss_type/bss_num */
-   mac_addr ^= BIT_ULL(priv->bss_type + 8);
-   mac_addr += priv->bss_num;
-   }
+   if (priv->bss_type == MWIFIEX_BSS_TYPE_P2P)
+   mac_addr |= BIT_ULL(MWIFIEX_MAC_LOCAL_ADMIN_BIT);
 
-   if (mac_addr == old_mac_addr)
-   goto done;
+   if (mwifiex_get_intf_num(priv->adapter, priv->bss_type) > 1) {
+   /* Set mac address based on bss_type/bss_num */
+   mac_addr ^= BIT_ULL(priv->bss_type + 8);
+   mac_addr += priv->bss_num;
+   }
+
+   if (mac_addr == old_mac_addr)
+   goto done;
+   }
 
u64_to_ether_addr(mac_addr, priv->curr_addr);
 
@@ -1006,8 +1013,7 @@ int mwifiex_set_mac_address(struct mwifiex_private *priv,
struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev);
struct sockaddr *hw_addr = addr;
 
-   memcpy(priv->curr_addr, hw_addr->sa_data, ETH_ALEN);
-   return mwifiex_set_mac_address(priv, dev);
+   return mwifiex_set_mac_address(priv, dev, true, hw_addr->sa_data);
 }
 
 /*
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index f607d0b..598e58b 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -1692,7 +1692,8 @@ void mwifiex_process_multi_chan_event(struct 
mwifiex_private *priv,
  struct sk_buff *event_skb);
 void mwifiex_multi_chan_resync(struct mwifiex_adapter *adapter);
 int mwifiex_set_mac_address(struct mwifiex_private *priv,
-   struct net_device *dev);
+   struct net_device *dev,
+   bool external, u8 *new_mac);
 
 #ifdef CONFIG_DEBUG_FS
 void mwifiex_debugfs_init(void);
-- 
1.9.1

[PATCH 3/3] mwifiex: keep user configured mac address during changing virtual interface

[Xinming Hu]

During changing virtual interface, keep using previous net device
mac address.

Signed-off-by: Xinming Hu 
---
 drivers/net/wireless/marvell/mwifiex/main.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index cef4dea8..bd036bf 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1345,7 +1345,10 @@ void mwifiex_init_priv_params(struct mwifiex_private 
*priv,
priv->assocresp_idx = MWIFIEX_AUTO_IDX_MASK;
priv->gen_idx = MWIFIEX_AUTO_IDX_MASK;
priv->num_tx_timeout = 0;
-   ether_addr_copy(priv->curr_addr, priv->adapter->perm_addr);
+   if (is_valid_ether_addr(dev->dev_addr))
+   ether_addr_copy(priv->curr_addr, dev->dev_addr);
+   else
+   ether_addr_copy(priv->curr_addr, priv->adapter->perm_addr);
 
if (GET_BSS_ROLE(priv) == MWIFIEX_BSS_ROLE_STA ||
GET_BSS_ROLE(priv) == MWIFIEX_BSS_ROLE_UAP) {
-- 
1.9.1

Re: RTL8723BE performance regression

[Larry Finger]

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

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

(...)


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


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


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



What is the recommended way to monitor the signal strength?


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


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


sudo iw dev  scan | egrep "SSID|signal"

Larry

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

[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

[João Paulo Rechi Vita]

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

(...)

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

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

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

What is the recommended way to monitor the signal strength?

Thanks for such a quick reply,

--
João Paulo Rechi Vita
http://about.me/jprvita

Re: RTL8723BE performance regression

[Larry Finger]

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

Hello,

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

My first bisect attempt pointed me to the following commit:

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

Which I later found to be already fixed by

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

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

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

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

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

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

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

VersionCommitPingDownUp

v4.11a351e9b1225.445.99
v4.11a351e9b131  17.025.89

v4.13569dbb8174  14.080.00
v4.13569dbb8261  8.41  0.00

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



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


Larry

Re: Request for brcmfmac4366c-pcie.bin

[Hubert Wiedeke]

On Mon, 19 Feb 2018 12:51:07 +0100
Arend van Spriel  wrote:

> On 2/17/2018 9:19 AM, Hubert Wiedeke wrote:
> > Hi,
> >
> > I'd like to ask about the current status of 4366c firmware preparation for 
> > linux-firmware.git . Is it close to finish? What about DFS? Nothing 
> > critical, just a question.
> 
> I have prepared some firmware changes for 4366, but did not manage to 
> get any test-cycles for it.
> 
> Regards,
> Arend
> 

Could you please estimate any possible dates for the tested FW to be released?

-- 
Best regards,
Hubert Wiedeke

RE: [PATCH 01/13] ath10k: platform driver for WCN3990 SNOC WLAN module

[yamada.masahiro]

Hi.

> -Original Message-
> From: govi...@codeaurora.org [mailto:govi...@codeaurora.org]
> Sent: Friday, March 23, 2018 8:55 PM
> To: Kalle Valo 
> Cc: Yamada, Masahiro/山田 真弘 ;
> linux-wireless@vger.kernel.org; ath...@lists.infradead.org
> Subject: Re: [PATCH 01/13] ath10k: platform driver for WCN3990 SNOC WLAN
> module
> 
> On 2018-03-10 14:41, Kalle Valo wrote:
> >  writes:
> >
> >>> >> Kbuild bot found an odd problem with this patch:
> >>> >>
> >>> >>  include/linux/dynamic_debug.h:77:14: error: 'KBUILD_MODNAME'
> >>> >>  undeclared (first use in this function); did you mean
> >>> 'KBUILD_BASENAME'?
> >>> >>
> >>> >> Full report:
> >>> >>
> >>> >>
> >>>
> http://lists.infradead.org/pipermail/ath10k/2018-February/010907.html
> >>> >>
> >>> >> Any ideas? Is this is some unrelated issue or what? This patch is
> not
> >>> >> even touching hif.h or ce.c.
> >>> >
> >>> > I didn't encountered this issue as in my defconfig only
> >>> > CONFIG_ATH10K_SNOC was defined. This problem is coming when we define
> >>> > CONFIG_ATH10K_SNOC and CONFIG_ATH10K_PCI simultaneously in defconfig
> >>> > and this is known issue when multiple modules share objects(in this
> >>> > case ce.o). I saw similar reported problem and found
> >>> > https://patchwork.kernel.org/patch/10060825/.
> >>> >
> >>> > After picking the below change issue is not seen.
> >>>
> >>> Let's ask the kbuild maintainer. Masahiro, any chances of getting
> >>> this
> >>> patch applied anytime soon:
> >>>
> >>> kbuild: define KBUILD_MODNAME even if multiple modules share objects
> >>>
> >>> https://patchwork.kernel.org/patch/10060825/
> >>>
> >>> In ath10k we would need it as otherwise we are not able to link ce.o
> >>> both to ath10k_pci.ko and ath10k_snoc.ko. What do you think?
> >>>
> >>> Full discussion and the ath10k patch here:
> >>>
> >>> https://patchwork.kernel.org/patch/10220657/
> >>>
> >>
> >> I plan to submit v2, but even if the undefined KBUILD_MODNAME is
> >> fixed,
> >> I expect another problem from this patch.
> >>
> >> If both CONFIG_ATH10K_PCI and CONFIG_ATH10_SNOC are 'y'
> >> two instances of ce.o would be linked into vmliux,
> >> then causes multiple definition error.
> >
> > Oh, I didn't realise this. Thanks for pointing it out. Govind is
> > looking
> > at other ways to fix this.
> 
> https://patchwork.kernel.org/patch/10298659/ is raised to address this
> problem.
> 



> CE layer is shared between pci and snoc target and results
> in duplicate object inclusion if both modules are compiled
> together statically and undefined KBUILD_MODNAME if
> compiled as module.


If you rebase your development on v4.17-rc1,
this statement is no longer true.


> Fix this by building ce layer in ath10k core module by
> adding ce object inclusion with ATH10K_CE boolean CONFIG.




Today, the solution landed in Linus' tree.

[1] Solution for missing KBUILD_MODNAME definition

commit aeacb019b61c4ea7689085574bd03d2c0810f119
Author: Masahiro Yamada 
Date:   Mon Mar 19 18:01:24 2018 +0900

kbuild: define KBUILD_MODNAME even if multiple modules share objects



[2] Solution for multiple definition error when both are built-in

commit f98fe47ce51dee6d97dd91bbeccdde23f043c754
Author: Masahiro Yamada 
Date:   Mon Mar 19 20:26:08 2018 +0900

kbuild: link $(real-obj-y) instead of $(obj-y) into built-in.a




[3] Examples for Makefile cleanups


commit f605005a50fc1443a14b4e8c9c1727881f8f96ae
Author: Masahiro Yamada 
Date:   Mon Mar 19 20:26:10 2018 +0900

net: liquidio: clean up Makefile for simpler composite object handling



commit dc35da16a2e23db04822f0129cd5b28b7b0e72b4
Author: Masahiro Yamada 
Date:   Mon Mar 19 20:26:09 2018 +0900

lib: zstd: clean up Makefile for simpler composite object handling

RTL8723BE performance regression

[João Paulo Rechi Vita]

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

Best regards,

--
João Paulo Rechi Vita
http://about.me/jprvita

[PATCH] staging: rtl8192e: Fixed coding style around a plus sign

[Joao Dalben]

Added blank spaces between a plus sign in order to standardize the coding
style.

Signed-off-by: Joao Dalben 
---
 drivers/staging/rtl8192e/dot11d.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192e/dot11d.c 
b/drivers/staging/rtl8192e/dot11d.c
index 88f89d77b511..a1c096124683 100644
--- a/drivers/staging/rtl8192e/dot11d.c
+++ b/drivers/staging/rtl8192e/dot11d.c
@@ -50,7 +50,7 @@ void dot11d_init(struct rtllib_device *ieee)
 
pDot11dInfo->State = DOT11D_STATE_NONE;
pDot11dInfo->CountryIeLen = 0;
-   memset(pDot11dInfo->channel_map, 0, MAX_CHANNEL_NUMBER+1);
+   memset(pDot11dInfo->channel_map, 0, MAX_CHANNEL_NUMBER + 1);
memset(pDot11dInfo->MaxTxPwrDbmList, 0xFF, MAX_CHANNEL_NUMBER + 1);
RESET_CIE_WATCHDOG(ieee);
 }
-- 
2.11.0

Re: License info

[Greg KH]

On Tue, Apr 03, 2018 at 09:53:29PM +0200, Xose Vazquez Perez wrote:
> Larry Finger wrote:
> 
> > 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?
> 
> "GPL-2.0" tag is deprecated [0] .
> 
> 
> It should be used:
> for GNU General Public License v2.0 only: "GPL-2.0-only"
> for GNU General Public License v2.0 or later: "GPL-2.0-or-later"

Please read Documentation/process/license-rules.rst.  We are sticking
with the "old" SPDX identifiers for now as they changed after we already
started marking up the kernel source tree.

thanks,

greg k-h

Re: [PATCH] mt76x2: remove unnecessary MT_TX_ALC_CFG_4 configuration

[Lorenzo Bianconi]

> On 2018-04-03 16:52, Lorenzo Bianconi wrote:
>> Remove unnecessary MT_TX_ALC_CFG_4 configuration since register value
>> has already set to 0 on 5GHz band
>>
>> Signed-off-by: Lorenzo Bianconi 
> If I read the code correctly, I think it makes more sense to remove the
> previous initialization, in order to have the writes to that register
> grouped together.
>
> - Felix

Ack, will do in v2

Regards,
Lorenzo

Re: License info

[Xose Vazquez Perez]

Larry Finger wrote:

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

"GPL-2.0" tag is deprecated [0] .


It should be used:
for GNU General Public License v2.0 only: "GPL-2.0-only"
for GNU General Public License v2.0 or later: "GPL-2.0-or-later"



[0] https://spdx.org/licenses/
https://www.gnu.org/licenses/identify-licenses-clearly.html

[PATCH 2/7] mt76: add missing VHT maximum A-MPDU length capability

[Felix Fietkau]

Signficantly improves throughput with some clients

Signed-off-by: Felix Fietkau 
---
 drivers/net/wireless/mediatek/mt76/mac80211.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c 
b/drivers/net/wireless/mediatek/mt76/mac80211.c
index 962ed8234065..ec531ce50d01 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -213,7 +213,8 @@ mt76_init_sband(struct mt76_dev *dev, struct mt76_sband 
*msband,
vht_cap->vht_supported = true;
vht_cap->cap |= IEEE80211_VHT_CAP_RXLDPC |
IEEE80211_VHT_CAP_RXSTBC_1 |
-   IEEE80211_VHT_CAP_SHORT_GI_80;
+   IEEE80211_VHT_CAP_SHORT_GI_80 |
+   (3 << 
IEEE80211_VHT_CAP_MAX_A_MPDU_LENGTH_EXPONENT_SHIFT);
 
return 0;
 }
-- 
2.14.2

[PATCH 7/7] mt76: check qos ack policy before reordering packets

[Felix Fietkau]

Do not attempt to reorder packets not part of a BA session

Signed-off-by: Felix Fietkau 
---
 drivers/net/wireless/mediatek/mt76/agg-rx.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/agg-rx.c 
b/drivers/net/wireless/mediatek/mt76/agg-rx.c
index 6657ec8928de..dbf4057d2d3e 100644
--- a/drivers/net/wireless/mediatek/mt76/agg-rx.c
+++ b/drivers/net/wireless/mediatek/mt76/agg-rx.c
@@ -147,12 +147,13 @@ mt76_rx_aggr_check_ctl(struct sk_buff *skb, struct 
sk_buff_head *frames)
 void mt76_rx_aggr_reorder(struct sk_buff *skb, struct sk_buff_head *frames)
 {
struct mt76_rx_status *status = (struct mt76_rx_status *) skb->cb;
+   struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
struct mt76_wcid *wcid = status->wcid;
struct ieee80211_sta *sta;
struct mt76_rx_tid *tid;
bool sn_less;
u16 seqno, head, size;
-   u8 idx;
+   u8 ackp, idx;
 
__skb_queue_tail(frames, skb);
 
@@ -165,6 +166,12 @@ void mt76_rx_aggr_reorder(struct sk_buff *skb, struct 
sk_buff_head *frames)
return;
}
 
+   /* not part of a BA session */
+   ackp = *ieee80211_get_qos_ctl(hdr) & IEEE80211_QOS_CTL_ACK_POLICY_MASK;
+   if (ackp != IEEE80211_QOS_CTL_ACK_POLICY_BLOCKACK &&
+   ackp != IEEE80211_QOS_CTL_ACK_POLICY_NORMAL)
+   return;
+
tid = rcu_dereference(wcid->aggr[status->tid]);
if (!tid)
return;
-- 
2.14.2

[PATCH 5/7] mt76: fix potential sleep in atomic context

[Felix Fietkau]

Use cancel_delayed_work instead of cancel_delayed_work_sync

Signed-off-by: Felix Fietkau 
---
 drivers/net/wireless/mediatek/mt76/agg-rx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/agg-rx.c 
b/drivers/net/wireless/mediatek/mt76/agg-rx.c
index fcb208d1f276..cbac42cb536c 100644
--- a/drivers/net/wireless/mediatek/mt76/agg-rx.c
+++ b/drivers/net/wireless/mediatek/mt76/agg-rx.c
@@ -273,7 +273,7 @@ static void mt76_rx_aggr_shutdown(struct mt76_dev *dev, 
struct mt76_rx_tid *tid)
 
spin_unlock_bh(>lock);
 
-   cancel_delayed_work_sync(>reorder_work);
+   cancel_delayed_work(>reorder_work);
 }
 
 void mt76_rx_aggr_stop(struct mt76_dev *dev, struct mt76_wcid *wcid, u8 tidno)
-- 
2.14.2

[PATCH 3/7] mt76: toggle driver station powersave bit before notifying mac80211

[Felix Fietkau]

Avoids race conditions from mac80211 enqueueing tx packets before the
tx-drop bit is cleared

Signed-off-by: Felix Fietkau 
---
 drivers/net/wireless/mediatek/mt76/mac80211.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c 
b/drivers/net/wireless/mediatek/mt76/mac80211.c
index ec531ce50d01..eb49e0a6758c 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -547,8 +547,8 @@ mt76_check_ps(struct mt76_dev *dev, struct sk_buff *skb)
else
clear_bit(MT_WCID_FLAG_PS, >flags);
 
-   ieee80211_sta_ps_transition(sta, ps);
dev->drv->sta_ps(dev, sta, ps);
+   ieee80211_sta_ps_transition(sta, ps);
 }
 
 void mt76_rx_complete(struct mt76_dev *dev, struct sk_buff_head *frames,
-- 
2.14.2

[PATCH 6/7] mt76: set RX_FLAG_DUP_VALIDATED for A-MPDU reordered packets

[Felix Fietkau]

Required for fast-rx and allows mac80211 to skip an unnnecessary check.

Signed-off-by: Felix Fietkau 
---
 drivers/net/wireless/mediatek/mt76/agg-rx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/mediatek/mt76/agg-rx.c 
b/drivers/net/wireless/mediatek/mt76/agg-rx.c
index cbac42cb536c..6657ec8928de 100644
--- a/drivers/net/wireless/mediatek/mt76/agg-rx.c
+++ b/drivers/net/wireless/mediatek/mt76/agg-rx.c
@@ -169,6 +169,7 @@ void mt76_rx_aggr_reorder(struct sk_buff *skb, struct 
sk_buff_head *frames)
if (!tid)
return;
 
+   status->flag |= RX_FLAG_DUP_VALIDATED;
spin_lock_bh(>lock);
 
if (tid->stopped)
-- 
2.14.2

[PATCH 1/7] mt76: stop tx queues from the driver callback instead of common code

[Felix Fietkau]

Allows the driver to control whether to send a BlockAckReq after waking
up. MT76x2 needs this set to true, for MT7603 (to be submitted later)
it needs to be false.

Signed-off-by: Felix Fietkau 
---
 drivers/net/wireless/mediatek/mt76/mac80211.c| 6 ++
 drivers/net/wireless/mediatek/mt76/mt76x2_main.c | 1 +
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c 
b/drivers/net/wireless/mediatek/mt76/mac80211.c
index 4f30cdcd2b53..962ed8234065 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -541,12 +541,10 @@ mt76_check_ps(struct mt76_dev *dev, struct sk_buff *skb)
if (!!test_bit(MT_WCID_FLAG_PS, >flags) == ps)
return;
 
-   if (ps) {
+   if (ps)
set_bit(MT_WCID_FLAG_PS, >flags);
-   mt76_stop_tx_queues(dev, sta, true);
-   } else {
+   else
clear_bit(MT_WCID_FLAG_PS, >flags);
-   }
 
ieee80211_sta_ps_transition(sta, ps);
dev->drv->sta_ps(dev, sta, ps);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2_main.c 
b/drivers/net/wireless/mediatek/mt76/mt76x2_main.c
index 73c127f92613..81c58f865c64 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2_main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2_main.c
@@ -321,6 +321,7 @@ mt76x2_sta_ps(struct mt76_dev *mdev, struct ieee80211_sta 
*sta, bool ps)
struct mt76x2_dev *dev = container_of(mdev, struct mt76x2_dev, mt76);
int idx = msta->wcid.idx;
 
+   mt76_stop_tx_queues(>mt76, sta, true);
mt76x2_mac_wcid_set_drop(dev, idx, ps);
 }
 
-- 
2.14.2

[PATCH 4/7] mt76: rework tx power handling

[Felix Fietkau]

There were a number of issues in the existing tx power handling code:

1. The EEPROM target power for chain 0 refers to the actual output power
after the channel and bandwidth delta have been added to the initial
channel gain. This means the delta values should not be added/subtracted
for the rate power calculation

2. When power is reduced significantly, the initial channel gain
underflows very quickly, while the per-rate power offsets are high.
This miscalculation causes effective tx power to be increased when it
should actually be lowered.

Fix this by trying to adjust the channel gain to the lowest power from
the rate table. In case of under- or overflow, compensate by adding an
appropriate delta to the rate power values.

This makes power configuration more accurate on a wider range of
configurable values

Signed-off-by: Felix Fietkau 
---
 drivers/net/wireless/mediatek/mt76/mt76x2_phy.c | 67 -
 1 file changed, 42 insertions(+), 25 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2_phy.c 
b/drivers/net/wireless/mediatek/mt76/mt76x2_phy.c
index fcc37eb7ce0b..2edc6b8b4e29 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2_phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2_phy.c
@@ -73,16 +73,6 @@ int mt76x2_phy_get_rssi(struct mt76x2_dev *dev, s8 rssi, int 
chain)
return rssi;
 }
 
-static u8
-mt76x2_txpower_check(int value)
-{
-   if (value < 0)
-   return 0;
-   if (value > 0x2f)
-   return 0x2f;
-   return value;
-}
-
 static void
 mt76x2_add_rate_power_offset(struct mt76_rate_power *r, int offset)
 {
@@ -102,6 +92,26 @@ mt76x2_limit_rate_power(struct mt76_rate_power *r, int 
limit)
r->all[i] = limit;
 }
 
+static int
+mt76x2_get_min_rate_power(struct mt76_rate_power *r)
+{
+   int i;
+   s8 ret = 0;
+
+   for (i = 0; i < sizeof(r->all); i++) {
+   if (!r->all[i])
+   continue;
+
+   if (ret)
+   ret = min(ret, r->all[i]);
+   else
+   ret = r->all[i];
+   }
+
+   return ret;
+}
+
+
 void mt76x2_phy_set_txpower(struct mt76x2_dev *dev)
 {
enum nl80211_chan_width width = dev->mt76.chandef.width;
@@ -109,6 +119,7 @@ void mt76x2_phy_set_txpower(struct mt76x2_dev *dev)
struct mt76x2_tx_power_info txp;
int txp_0, txp_1, delta = 0;
struct mt76_rate_power t = {};
+   int base_power, gain;
 
mt76x2_get_power_info(dev, , chan);
 
@@ -117,26 +128,32 @@ void mt76x2_phy_set_txpower(struct mt76x2_dev *dev)
else if (width == NL80211_CHAN_WIDTH_80)
delta = txp.delta_bw80;
 
-   if (txp.target_power > dev->txpower_conf)
-   delta -= txp.target_power - dev->txpower_conf;
-
mt76x2_get_rate_power(dev, , chan);
-   mt76x2_add_rate_power_offset(, txp.chain[0].target_power +
-  txp.chain[0].delta);
+   mt76x2_add_rate_power_offset(, txp.chain[0].target_power);
mt76x2_limit_rate_power(, dev->txpower_conf);
dev->txpower_cur = mt76x2_get_max_rate_power();
-   mt76x2_add_rate_power_offset(, -(txp.chain[0].target_power +
-txp.chain[0].delta + delta));
-   dev->target_power = txp.chain[0].target_power;
-   dev->target_power_delta[0] = txp.chain[0].delta + delta;
-   dev->target_power_delta[1] = txp.chain[1].delta + delta;
-   dev->rate_power = t;
 
-   txp_0 = mt76x2_txpower_check(txp.chain[0].target_power +
-  txp.chain[0].delta + delta);
+   base_power = mt76x2_get_min_rate_power();
+   delta += base_power - txp.chain[0].target_power;
+   txp_0 = txp.chain[0].target_power + txp.chain[0].delta + delta;
+   txp_1 = txp.chain[1].target_power + txp.chain[1].delta + delta;
+
+   gain = min(txp_0, txp_1);
+   if (gain < 0) {
+   base_power -= gain;
+   txp_0 -= gain;
+   txp_1 -= gain;
+   } else if (gain > 0x2f) {
+   base_power -= gain - 0x2f;
+   txp_0 = 0x2f;
+   txp_1 = 0x2f;
+   }
 
-   txp_1 = mt76x2_txpower_check(txp.chain[1].target_power +
-  txp.chain[1].delta + delta);
+   mt76x2_add_rate_power_offset(, -base_power);
+   dev->target_power = txp.chain[0].target_power;
+   dev->target_power_delta[0] = txp_0 - txp.chain[0].target_power;
+   dev->target_power_delta[1] = txp_1 - txp.chain[0].target_power;
+   dev->rate_power = t;
 
mt76_rmw_field(dev, MT_TX_ALC_CFG_0, MT_TX_ALC_CFG_0_CH_INIT_0, txp_0);
mt76_rmw_field(dev, MT_TX_ALC_CFG_0, MT_TX_ALC_CFG_0_CH_INIT_1, txp_1);
-- 
2.14.2

Re: [PATCH] mt76x2: fix tssi initialization for 5GHz band

[Felix Fietkau]

On 2018-04-03 16:45, Lorenzo Bianconi wrote:
> Fix mcu initial configuration for tssi calibration on 5GHz band
> 
> Fixes: 7bc04215a66b ("mt76: add driver code for MT76x2e")
> Signed-off-by: Lorenzo Bianconi 
Acked-by: Felix Fietkau 

Re: [PATCH] mt76x2: make mt76x2_mac_reset routine static

[Felix Fietkau]

On 2018-04-03 17:01, Lorenzo Bianconi wrote:
> Add static qualifier to mt76x2_mac_reset routine and remove the
> prototype from mt76x2_mac.h since it is used just in mt76x2_init.c
> 
> Signed-off-by: Lorenzo Bianconi 
Acked-by: Felix Fietkau 

Re: [PATCH] mt76x2: remove unnecessary MT_TX_ALC_CFG_4 configuration

[Felix Fietkau]

On 2018-04-03 16:52, Lorenzo Bianconi wrote:
> Remove unnecessary MT_TX_ALC_CFG_4 configuration since register value
> has already set to 0 on 5GHz band
> 
> Signed-off-by: Lorenzo Bianconi 
If I read the code correctly, I think it makes more sense to remove the
previous initialization, in order to have the writes to that register
grouped together.

- Felix

Packet Injection in 5Ghz bands with iwlwifi devices?

[jkon23]

Hello all,

Does anyone know if it is possible to inject packets
at bands above 2.4 Ghz with either the 7265NGW or the 3168NGW? 

According to https://wikidevi.com/wiki/Iwlwifi 
, Intel cards using the iwlwifi
driver should support packet injection. When I try to use the Intel
7265NGW or the 3168NGW I am only able to inject packets at 2.4 Ghz. Initially,
I thought that this might be an issue with the regulatory domain not getting
set correctly, but once I edited /etc/modprobe.d/iwlwifi.conf to add 
`lar_disable=1` I was able to set the regulatory domain to something other than
the default 00 domain. However, I was still unable to inject packets in 5Ghz
bands. I have tried this using Ubuntu 16.04, Ubuntu 18.04 beta and a very recent
nightly build of Kali Linux. 

Apologies if this is the wrong mailing list for this question.

-John

Re: Wi-Fi Disconnection on Suspend for no wowlan triggers

[Steve deRosier]

Hi Sunil,

On Tue, Apr 3, 2018 at 5:39 AM, Sunil Dutt Undekari
 wrote:
> Hi All ,
>
> I would like to discuss on the commit 
> 8125696991194aacb1173b6e8196d19098b44e17 (cfg80211/mac80211: disconnect on 
> suspend) which triggers the STA disconnection on suspend if no wowlan 
> triggers are registered.

This commit went in over five years ago. Sometime around v3.9

> I guess the intention here is to disconnect from the AP if the device cannot 
> wake up on a packet / not configured with wowlan triggers .

It being a long time and not feeling like digging too deep into the
patch, what I can guess from a quick look is basically this:

* Before the patch, waking up from suspend would throw warnings into
the log. This patch fixes this.
* As you can't wake the processor, and you're a thin-mac chip who
depends on mac80211, you _can't_ do anything without wowlan.
* If your chip is not configured for wowlan, on a suspend, it might as
well go to sleep, as there's no sense in wasting power as you can't do
anything anyway.
* If you're going to sleep and can't respond to the AP, it's polite to
disconnect. And the AP is going to forcibly do so to you anyway after
some time of not hearing from you.

Hence the above in general concept seems perfectly correct and I don't
see any point in doing anything else with a mac80211 device.

> Can this behavior get enhanced to only do so on driver's preference -  do a 
> disconnect for only the host drivers that would want to do so (through an 
> additional feature capability) ?
>

Can? Perhaps. Send a patch. And maybe you could explain in detail what
the actual problem is you're trying to solve. Patches that are "maybe,
someday, someone might want to..." don't have a terribly high chance
of getting merged.  But solutions to real-life actual problems do. And
it's really difficult for us to speak on vague hypothetical musings.

- Steve

--
Steve deRosier
Cal-Sierra Consulting LLC
https://www.cal-sierra.com/

[PATCH 1/3] wcn36xx: check for DMA mapping errors in wcn36xx_dxe_tx_frame()

[Daniel Mack]

Bail out if the mapping fails. Even though this hasn't occured during
tests, this unlikely case should still be handled.

Signed-off-by: Daniel Mack 
---
 drivers/net/wireless/ath/wcn36xx/dxe.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/wireless/ath/wcn36xx/dxe.c 
b/drivers/net/wireless/ath/wcn36xx/dxe.c
index 6e9a3583c447..e8ad8f989ccd 100644
--- a/drivers/net/wireless/ath/wcn36xx/dxe.c
+++ b/drivers/net/wireless/ath/wcn36xx/dxe.c
@@ -707,6 +707,11 @@ int wcn36xx_dxe_tx_frame(struct wcn36xx *wcn,
  ctl->skb->data,
  ctl->skb->len,
  DMA_TO_DEVICE);
+   if (dma_mapping_error(wcn->dev, desc->src_addr_l)) {
+   dev_err(wcn->dev, "unable to DMA map src_addr_l\n");
+   ret = -ENOMEM;
+   goto unlock;
+   }
 
desc->dst_addr_l = ch->dxe_wq;
desc->fr_len = ctl->skb->len;
-- 
2.14.3

[PATCH 2/3] wcn36xx: don't keep reference to skb if transmission failed

[Daniel Mack]

When wcn36xx_dxe_tx_frame() fails to transmit the TX frame, the driver
will call into ieee80211_free_txskb() for the skb in flight, so it'll no
longer be valid. Hence, we shouldn't keep a reference to it in ctl->skb.
Also, if the skb has IEEE80211_TX_CTL_REQ_TX_STATUS set, a pointer to
it will currently remain in wcn->tx_ack_skb, which will potentially lead
to a crash if accessed later.

Fix this by checking the return value of wcn36xx_dxe_tx_frame(), and
nullify wcn->tx_ack_skb again in case of errors. Move the assignment
of ctl->skb in wcn36xx_dxe_tx_frame() so it only happens when the
transmission is successful.

Signed-off-by: Daniel Mack 
---
 drivers/net/wireless/ath/wcn36xx/dxe.c  |  6 +++---
 drivers/net/wireless/ath/wcn36xx/txrx.c | 15 ++-
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/wcn36xx/dxe.c 
b/drivers/net/wireless/ath/wcn36xx/dxe.c
index e8ad8f989ccd..abf7b051e1ff 100644
--- a/drivers/net/wireless/ath/wcn36xx/dxe.c
+++ b/drivers/net/wireless/ath/wcn36xx/dxe.c
@@ -695,7 +695,6 @@ int wcn36xx_dxe_tx_frame(struct wcn36xx *wcn,
 
/* Set source address of the SKB we send */
ctl = ctl->next;
-   ctl->skb = skb;
desc = ctl->desc;
if (ctl->bd_cpu_addr) {
wcn36xx_err("bd_cpu_addr cannot be NULL for skb DXE\n");
@@ -704,8 +703,8 @@ int wcn36xx_dxe_tx_frame(struct wcn36xx *wcn,
}
 
desc->src_addr_l = dma_map_single(wcn->dev,
- ctl->skb->data,
- ctl->skb->len,
+ skb->data,
+ skb->len,
  DMA_TO_DEVICE);
if (dma_mapping_error(wcn->dev, desc->src_addr_l)) {
dev_err(wcn->dev, "unable to DMA map src_addr_l\n");
@@ -713,6 +712,7 @@ int wcn36xx_dxe_tx_frame(struct wcn36xx *wcn,
goto unlock;
}
 
+   ctl->skb = skb;
desc->dst_addr_l = ch->dxe_wq;
desc->fr_len = ctl->skb->len;
 
diff --git a/drivers/net/wireless/ath/wcn36xx/txrx.c 
b/drivers/net/wireless/ath/wcn36xx/txrx.c
index b1768ed6b0be..a6902371e89c 100644
--- a/drivers/net/wireless/ath/wcn36xx/txrx.c
+++ b/drivers/net/wireless/ath/wcn36xx/txrx.c
@@ -273,6 +273,7 @@ int wcn36xx_start_tx(struct wcn36xx *wcn,
bool bcast = is_broadcast_ether_addr(hdr->addr1) ||
is_multicast_ether_addr(hdr->addr1);
struct wcn36xx_tx_bd bd;
+   int ret;
 
memset(, 0, sizeof(bd));
 
@@ -317,5 +318,17 @@ int wcn36xx_start_tx(struct wcn36xx *wcn,
buff_to_be((u32 *), sizeof(bd)/sizeof(u32));
bd.tx_bd_sign = 0xbdbdbdbd;
 
-   return wcn36xx_dxe_tx_frame(wcn, vif_priv, , skb, is_low);
+   ret = wcn36xx_dxe_tx_frame(wcn, vif_priv, , skb, is_low);
+   if (ret && bd.tx_comp) {
+   /* If the skb has not been transmitted,
+* don't keep a reference to it.
+*/
+   spin_lock_irqsave(>dxe_lock, flags);
+   wcn->tx_ack_skb = NULL;
+   spin_unlock_irqrestore(>dxe_lock, flags);
+
+   ieee80211_wake_queues(wcn->hw);
+   }
+
+   return ret;
 }
-- 
2.14.3

[PATCH 3/3] wcn36xx: don't delete invalid bss indices

[Daniel Mack]

The firmware code cannot cope with requests to remove BSS indices that have
not previously been added. This primarily happens when the device is
suspended and then resumed. ieee80211_reconfig() then calls into
wcn36xx_bss_info_changed() with an empty bssid and BSS_CHANGED_BSSID set,
which subsequently leads to a firmware crash:

[   43.647928] qcom-wcnss-pil a204000.wcnss: fatal error received: 
halMsg.c:4964:halMsg_DelBss: Invalid BSSIndex 0
[   43.647959] remoteproc remoteproc0: crash detected in a204000.wcnss: type 
fatal error

To fix this, set bss_index to WCN36XX_HAL_BSS_INVALID_IDX for all bss
that have not been configured in the firmware, and don't call into the
firmware with invalid indices.

Signed-off-by: Daniel Mack 
---
 drivers/net/wireless/ath/wcn36xx/main.c | 1 +
 drivers/net/wireless/ath/wcn36xx/smd.c  | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/drivers/net/wireless/ath/wcn36xx/main.c 
b/drivers/net/wireless/ath/wcn36xx/main.c
index 69d6be59d97f..32bbd6e2fd09 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -953,6 +953,7 @@ static int wcn36xx_add_interface(struct ieee80211_hw *hw,
 
mutex_lock(>conf_mutex);
 
+   vif_priv->bss_index = WCN36XX_HAL_BSS_INVALID_IDX;
list_add(_priv->list, >vif_list);
wcn36xx_smd_add_sta_self(wcn, vif);
 
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c 
b/drivers/net/wireless/ath/wcn36xx/smd.c
index 8932af5e4d8d..5be07e40a86d 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -1446,6 +1446,10 @@ int wcn36xx_smd_delete_bss(struct wcn36xx *wcn, struct 
ieee80211_vif *vif)
int ret = 0;
 
mutex_lock(>hal_mutex);
+
+   if (vif_priv->bss_index == WCN36XX_HAL_BSS_INVALID_IDX)
+   goto out;
+
INIT_HAL_MSG(msg_body, WCN36XX_HAL_DELETE_BSS_REQ);
 
msg_body.bss_index = vif_priv->bss_index;
@@ -1464,6 +1468,8 @@ int wcn36xx_smd_delete_bss(struct wcn36xx *wcn, struct 
ieee80211_vif *vif)
wcn36xx_err("hal_delete_bss response failed err=%d\n", ret);
goto out;
}
+
+   vif_priv->bss_index = WCN36XX_HAL_BSS_INVALID_IDX;
 out:
mutex_unlock(>hal_mutex);
return ret;
-- 
2.14.3

[PATCH] mt76x2: make mt76x2_mac_reset routine static

[Lorenzo Bianconi]

Add static qualifier to mt76x2_mac_reset routine and remove the
prototype from mt76x2_mac.h since it is used just in mt76x2_init.c

Signed-off-by: Lorenzo Bianconi 
---
 drivers/net/wireless/mediatek/mt76/mt76x2_init.c | 2 +-
 drivers/net/wireless/mediatek/mt76/mt76x2_mac.h  | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2_init.c 
b/drivers/net/wireless/mediatek/mt76/mt76x2_init.c
index 934c331d995e..359b105235b3 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2_init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2_init.c
@@ -228,7 +228,7 @@ mt76x2_init_beacon_offsets(struct mt76x2_dev *dev)
mt76_wr(dev, MT_BCN_OFFSET(i), regs[i]);
 }
 
-int mt76x2_mac_reset(struct mt76x2_dev *dev, bool hard)
+static int mt76x2_mac_reset(struct mt76x2_dev *dev, bool hard)
 {
static const u8 null_addr[ETH_ALEN] = {};
const u8 *macaddr = dev->mt76.macaddr;
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2_mac.h 
b/drivers/net/wireless/mediatek/mt76/mt76x2_mac.h
index 8a8a25e32d5f..c048cd06df6b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2_mac.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2_mac.h
@@ -157,7 +157,6 @@ mt76x2_skb_tx_info(struct sk_buff *skb)
return (void *) info->status.status_driver_data;
 }
 
-int mt76x2_mac_reset(struct mt76x2_dev *dev, bool hard);
 int mt76x2_mac_start(struct mt76x2_dev *dev);
 void mt76x2_mac_stop(struct mt76x2_dev *dev, bool force);
 void mt76x2_mac_resume(struct mt76x2_dev *dev);
-- 
2.14.3

[PATCH] mt76x2: remove unnecessary MT_TX_ALC_CFG_4 configuration

[Lorenzo Bianconi]

Remove unnecessary MT_TX_ALC_CFG_4 configuration since register value
has already set to 0 on 5GHz band

Signed-off-by: Lorenzo Bianconi 
---
 drivers/net/wireless/mediatek/mt76/mt76x2_phy.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2_phy.c 
b/drivers/net/wireless/mediatek/mt76/mt76x2_phy.c
index f28c55746cea..cbf185e9f707 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2_phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2_phy.c
@@ -294,7 +294,6 @@ mt76x2_phy_set_txpower_regs(struct mt76x2_dev *dev, enum 
nl80211_band band)
} else {
mt76_wr(dev, MT_TX0_RF_GAIN_CORR, 0x383c023c);
mt76_wr(dev, MT_TX1_RF_GAIN_CORR, 0x24282e28);
-   mt76_wr(dev, MT_TX_ALC_CFG_4, 0);
}
}
 }
-- 
2.14.3

[PATCH] mt76x2: fix tssi initialization for 5GHz band

[Lorenzo Bianconi]

Fix mcu initial configuration for tssi calibration on 5GHz band

Fixes: 7bc04215a66b ("mt76: add driver code for MT76x2e")
Signed-off-by: Lorenzo Bianconi 
---
 drivers/net/wireless/mediatek/mt76/mt76x2_phy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2_phy.c 
b/drivers/net/wireless/mediatek/mt76/mt76x2_phy.c
index fcc37eb7ce0b..f28c55746cea 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2_phy.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2_phy.c
@@ -180,7 +180,7 @@ mt76x2_phy_tssi_init_cal(struct mt76x2_dev *dev)
if (mt76x2_channel_silent(dev))
return false;
 
-   if (chan->band == NL80211_BAND_2GHZ)
+   if (chan->band == NL80211_BAND_5GHZ)
flag |= BIT(0);
 
if (mt76x2_ext_pa_enabled(dev, chan->band))
-- 
2.14.3

Wi-Fi Disconnection on Suspend for no wowlan triggers

[Sunil Dutt Undekari]

Hi All ,

I would like to discuss on the commit 8125696991194aacb1173b6e8196d19098b44e17 
(cfg80211/mac80211: disconnect on suspend) which triggers the STA disconnection 
on suspend if no wowlan triggers are registered.
I guess the intention here is to disconnect from the AP if the device cannot 
wake up on a packet / not configured with wowlan triggers . 
Can this behavior get enhanced to only do so on driver's preference -  do a 
disconnect for only the host drivers that would want to do so (through an 
additional feature capability) ?

Regards,
Sunil
 

Re: WARNING in add_uevent_var

[Johannes Berg]

On Sun, 2018-04-01 at 23:01 -0700, syzbot wrote:

> So far this crash happened 5 times on net-next, upstream.
> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6614377067184128
> 

Huh, fun. Looks like you're basically creating a new HWSIM radio with an
insanely long name (4k!) and nothing stops you, until we try to generate
an rfkill instance which sends a uevent and only has a 2k buffer for the
environment variables, where we put the name ...

But yeah, we should probably limit the phy name to something sane, I'll
pick 128 and send a patch.

johannes

[PATCH] cfg80211: limit wiphy names to 128 bytes

[Johannes Berg]

From: Johannes Berg 

There's currently no limit on wiphy names, other than netlink
message size and memory limitations, but that causes issues when,
for example, the wiphy name is used in a uevent, e.g. in rfkill
where we use the same name for the rfkill instance, and then the
buffer there is "only" 2k for the environment variables.

This was reported by syzkaller, which used a 4k name.

Limit the name to something reasonable, I randomly picked 128.

Reported-by: syzbot+230d9e642a85d3fec...@syzkaller.appspotmail.com
Signed-off-by: Johannes Berg 
---
 include/uapi/linux/nl80211.h | 2 ++
 net/wireless/core.c  | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index c587a61c32bf..2e08c6f3ac3e 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2618,6 +2618,8 @@ enum nl80211_attrs {
 #define NL80211_ATTR_KEYS NL80211_ATTR_KEYS
 #define NL80211_ATTR_FEATURE_FLAGS NL80211_ATTR_FEATURE_FLAGS
 
+#define NL80211_WIPHY_NAME_MAXLEN  128
+
 #define NL80211_MAX_SUPP_RATES 32
 #define NL80211_MAX_SUPP_HT_RATES  77
 #define NL80211_MAX_SUPP_REG_RULES 64
diff --git a/net/wireless/core.c b/net/wireless/core.c
index a6f3cac8c640..c0fd8a85e7f7 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -95,6 +95,9 @@ static int cfg80211_dev_check_name(struct 
cfg80211_registered_device *rdev,
 
ASSERT_RTNL();
 
+   if (strlen(newname) > NL80211_WIPHY_NAME_MAXLEN)
+   return -EINVAL;
+
/* prohibit calling the thing phy%d when %d is not its number */
sscanf(newname, PHY_NAME "%d%n", _idx, );
if (taken == strlen(newname) && wiphy_idx != rdev->wiphy_idx) {
-- 
2.14.3

Re: [PATCH] brcmfmac: add support for BCM4366E chipset

[Rafał Miłecki]

On 3 April 2018 at 13:24, Arend van Spriel  wrote:
> On 4/3/2018 12:17 PM, Rafał Miłecki wrote:
>>
>> On 3 April 2018 at 10:22, Arend van Spriel 
>> wrote:
>
>
> [...]
>
>>>
>>>
>>> My first reaction to this email needed to some cooldown time, but managed
>>> to
>>> swallow it.
>>
>>
>> I'm sorry you keep reacting to my e-mails/patches that way. I can't
>> see how my e-mail was offensive in any way. I assure I didn't mean it
>> to be.
>
>
> I can not really say what it is. Anyway it is my fault and have to work on
> it.
>
> [...]
>
>>> I actually had a couple of issues with the patch and did not
>>> want to waste Dan's time when there was a patch ready. I did not want to
>>> add
>>> another device because we are still in the process of releasing the
>>> firmware
>>> for it. Fiddling with radar detection causing the delay of that.
>>
>>
>> It's something that I think was never a problem in the past. There is
>> e.g. support for 4366c0 support in the brcmfmac without
>> brcmfmac4366c-pcie.bin officially released.
>
>
> My rule of thumb is to get the firmware released before/when the driver
> patch hits mainline. However, sometimes it blows up in my face. Like with
> the 4366c0. We had to add a new feature to the firmware to get an ok, which
> caused the delay. Hopefully, I can get it out soon.

Sounds great, thanks, I keep by fingers crossed :)

-- 
Rafał

Re: [PATCH] brcmfmac: add support for BCM4366E chipset

[Arend van Spriel]

On 4/3/2018 12:17 PM, Rafał Miłecki wrote:

On 3 April 2018 at 10:22, Arend van Spriel  wrote:


[...]




My first reaction to this email needed to some cooldown time, but managed to
swallow it.


I'm sorry you keep reacting to my e-mails/patches that way. I can't
see how my e-mail was offensive in any way. I assure I didn't mean it
to be.


I can not really say what it is. Anyway it is my fault and have to work 
on it.


[...]


I actually had a couple of issues with the patch and did not
want to waste Dan's time when there was a patch ready. I did not want to add
another device because we are still in the process of releasing the firmware
for it. Fiddling with radar detection causing the delay of that.


It's something that I think was never a problem in the past. There is
e.g. support for 4366c0 support in the brcmfmac without
brcmfmac4366c-pcie.bin officially released.


My rule of thumb is to get the firmware released before/when the driver 
patch hits mainline. However, sometimes it blows up in my face. Like 
with the 4366c0. We had to add a new feature to the firmware to get an 
ok, which caused the delay. Hopefully, I can get it out soon.


Regards,
Arend

Re: [PATCH] brcmfmac: fix firmware request processing if nvram load fails

[Arend van Spriel]

On 4/3/2018 12:04 PM, Kalle Valo wrote:

Arend van Spriel  writes:


When nvram loading fails a double free occurred. Fix this and reorg the
code a little.

Fixes: commit d09ae51a4b67 ("brcmfmac: pass struct in brcmf_fw_get_firmwares()")


This should be:

Fixes: d09ae51a4b67 ("brcmfmac: pass struct in brcmf_fw_get_firmwares()")

I can fix that during commit.


Reported-by: Dan Carpenter 
Signed-off-by: Arend van Spriel 
---
Hi Kalle,

This fix is for code currently(?) in linux-next in error path caused
a double free.


Ok, I'll queue this to wireless-drivers (after I have fast forwarded it)
for 4.17.


Thanks

Arend

Re: [PATCH] brcmfmac: add support for BCM4366E chipset

[Rafał Miłecki]

On 3 April 2018 at 10:22, Arend van Spriel  wrote:
> On 3/30/2018 9:26 AM, Rafał Miłecki wrote:
>>
>> On 23 March 2018 at 10:31, Arend van Spriel
>>  wrote:
>>>
>>> On 3/22/2018 4:58 PM, Dan Haab wrote:


 From: Dan Haab 

 BCM4366E is a wireless chipset with a BCM43664 ChipCommon. It's
 supported by the same firmware as 4366c0.
>>>
>>>
>>>
>>> Thanks, Dan
>>>
>>> I have a patch for that queued up already. So let me push that instead.
>>
>>
>> Arend: is there some actual problem with this patch? Other than you
>> have a similar one queued?
>>
>> I'd prefer to just accept it as it's already there, it was sent first
>> and it looks alright. It hopefully won't be too hard to rebase your
>> queued work on top of this trivial patch.
>
>
> My first reaction to this email needed to some cooldown time, but managed to
> swallow it.

I'm sorry you keep reacting to my e-mails/patches that way. I can't
see how my e-mail was offensive in any way. I assure I didn't mean it
to be.

I really assumed there could be some extra changes needed to support
4366E properly, that's why I asked. I can remember adding a full
support for 4366b1 wasn't that obvious and you and Hante spent some
time helping me with some specific device. They required changes from
commit 6ac27689b01e2 ("brcmfmac: use device memsize config from fw if
defined").


> I actually had a couple of issues with the patch and did not
> want to waste Dan's time when there was a patch ready. I did not want to add
> another device because we are still in the process of releasing the firmware
> for it. Fiddling with radar detection causing the delay of that.

It's something that I think was never a problem in the past. There is
e.g. support for 4366c0 support in the brcmfmac without
brcmfmac4366c-pcie.bin officially released.


> Another
> thing is that there is no separate BRCMF_FW_NVRAM_DEF() needed for this. And
> finally, the firmware download code has been reworked so this patch needs
> rebasing.

Thanks for rebasing that! I appreciate your help. I'll work on
backporting that into OpenWrt/LEDE.

-- 
Rafał

Re: [PATCH] brcmfmac: fix firmware request processing if nvram load fails

[Kalle Valo]

Arend van Spriel  writes:

> When nvram loading fails a double free occurred. Fix this and reorg the
> code a little.
>
> Fixes: commit d09ae51a4b67 ("brcmfmac: pass struct in 
> brcmf_fw_get_firmwares()")

This should be:

Fixes: d09ae51a4b67 ("brcmfmac: pass struct in brcmf_fw_get_firmwares()")

I can fix that during commit.

> Reported-by: Dan Carpenter 
> Signed-off-by: Arend van Spriel 
> ---
> Hi Kalle,
>
> This fix is for code currently(?) in linux-next in error path caused
> a double free.

Ok, I'll queue this to wireless-drivers (after I have fast forwarded it)
for 4.17.

-- 
Kalle Valo

Re: [PATCH] wcn36xx: allocate skbs with GFP_KERNEL during init

[Kalle Valo]

Daniel Mack  writes:

> On Monday, March 19, 2018 07:30 AM, Daniel Mack wrote:
>> GFP_ATOMIC should only be used when the allocation is done from atomic
>> context. Introduce a new flag to wcn36xx_dxe_fill_skb() and use GFP_KERNEL
>> when pre-allocating buffers during init.
>> 
>> This doesn't fix an issue that was observed in the wild, but it reduces
>> the chance of failed allocations under memory pressure.
>> 
>> Signed-off-by: Daniel Mack 
>
> Any opinion about this one?

It's better that you check the state from patchwork, less mail to the
maintainers:

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

-- 
Kalle Valo

Re: License info

[Kalle Valo]

Larry Finger  writes:

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

I don't think replacing licenses with SPDX identifiers is very
important, but I can apply patches if someone wants to convert drivers.
And at the moment I'm not planning to require SPDX identifiers in new
files.

-- 
Kalle Valo

[PATCH] mac80211: Fix condition validating WMM IE

[Luca Coelho]

From: Ilan Peer 

Commit c470bdc1aaf3 ("mac80211: don't WARN on bad WMM parameters from
buggy APs") handled cases where an AP reports a zeroed WMM
IE. However, the condition that checks the validity accessed the wrong
index in the ieee80211_tx_queue_params array, thus wrongly deducing
that the parameters are invalid. Fix it.

Fixes: c470bdc1aaf3 ("mac80211: don't WARN on bad WMM parameters from buggy 
APs")
Signed-off-by: Ilan Peer 
Signed-off-by: Luca Coelho 
---
 net/mac80211/mlme.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 07b58d20e89c..e521f19b02c0 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1786,7 +1786,7 @@ static bool ieee80211_sta_wmm_params(struct 
ieee80211_local *local,
params[ac].acm = acm;
params[ac].uapsd = uapsd;
 
-   if (params->cw_min == 0 ||
+   if (params[ac].cw_min == 0 ||
params[ac].cw_min > params[ac].cw_max) {
sdata_info(sdata,
   "AP has invalid WMM params (CWmin/max=%d/%d 
for ACI %d), using defaults\n",
-- 
2.16.2

[PATCH] brcmfmac: add support for BCM4366E chipset

[Arend van Spriel]

From: Dan Haab 

BCM4366E is a wireless chipset with a BCM43664 ChipCommon. It's
supported by the same firmware as 4366c0.

Signed-off-by: Dan Haab 
[arend: rebase patch and remove unnecessary definition]
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c   | 1 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c   | 1 +
 drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 1 +
 3 files changed, 3 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 3b829fe..927d62b 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -689,6 +689,7 @@ static u32 brcmf_chip_tcm_rambase(struct brcmf_chip_priv 
*ci)
case BRCM_CC_43525_CHIP_ID:
case BRCM_CC_4365_CHIP_ID:
case BRCM_CC_4366_CHIP_ID:
+   case BRCM_CC_43664_CHIP_ID:
return 0x20;
case CY_CC_4373_CHIP_ID:
return 0x16;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 091c191..6e25ff9 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -75,6 +75,7 @@ enum brcmf_pcie_state {
BRCMF_FW_ENTRY(BRCM_CC_4365_CHIP_ID, 0xFFF0, 4365C),
BRCMF_FW_ENTRY(BRCM_CC_4366_CHIP_ID, 0x000F, 4366B),
BRCMF_FW_ENTRY(BRCM_CC_4366_CHIP_ID, 0xFFF0, 4366C),
+   BRCMF_FW_ENTRY(BRCM_CC_43664_CHIP_ID, 0xFFF0, 4366C),
BRCMF_FW_ENTRY(BRCM_CC_4371_CHIP_ID, 0x, 4371),
 };
 
diff --git a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h 
b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
index 57544a3..686f7a8 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
@@ -57,6 +57,7 @@
 #define BRCM_CC_43602_CHIP_ID  43602
 #define BRCM_CC_4365_CHIP_ID   0x4365
 #define BRCM_CC_4366_CHIP_ID   0x4366
+#define BRCM_CC_43664_CHIP_ID  43664
 #define BRCM_CC_4371_CHIP_ID   0x4371
 #define CY_CC_4373_CHIP_ID 0x4373
 
-- 
1.9.1

Re: [PATCH] brcmfmac: add support for BCM4366E chipset

[Arend van Spriel]

On 3/30/2018 9:26 AM, Rafał Miłecki wrote:

On 23 March 2018 at 10:31, Arend van Spriel
 wrote:

On 3/22/2018 4:58 PM, Dan Haab wrote:


From: Dan Haab 

BCM4366E is a wireless chipset with a BCM43664 ChipCommon. It's
supported by the same firmware as 4366c0.



Thanks, Dan

I have a patch for that queued up already. So let me push that instead.


Arend: is there some actual problem with this patch? Other than you
have a similar one queued?

I'd prefer to just accept it as it's already there, it was sent first
and it looks alright. It hopefully won't be too hard to rebase your
queued work on top of this trivial patch.


My first reaction to this email needed to some cooldown time, but 
managed to swallow it. I actually had a couple of issues with the patch 
and did not want to waste Dan's time when there was a patch ready. I did 
not want to add another device because we are still in the process of 
releasing the firmware for it. Fiddling with radar detection causing the 
delay of that. Another thing is that there is no separate 
BRCMF_FW_NVRAM_DEF() needed for this. And finally, the firmware download 
code has been reworked so this patch needs rebasing.


Regards,
Arend

[PATCH] brcmfmac: fix firmware request processing if nvram load fails

[Arend van Spriel]

When nvram loading fails a double free occurred. Fix this and reorg the
code a little.

Fixes: commit d09ae51a4b67 ("brcmfmac: pass struct in brcmf_fw_get_firmwares()")
Reported-by: Dan Carpenter 
Signed-off-by: Arend van Spriel 
---
Hi Kalle,

This fix is for code currently(?) in linux-next in error path caused
a double free.

Regards,
Arend
---
 .../broadcom/brcm80211/brcmfmac/firmware.c | 36 --
 1 file changed, 20 insertions(+), 16 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index 9277f4c..94e177d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -459,7 +459,7 @@ static void brcmf_fw_free_request(struct brcmf_fw_request 
*req)
kfree(req);
 }
 
-static void brcmf_fw_request_nvram_done(const struct firmware *fw, void *ctx)
+static int brcmf_fw_request_nvram_done(const struct firmware *fw, void *ctx)
 {
struct brcmf_fw *fwctx = ctx;
struct brcmf_fw_item *cur;
@@ -498,13 +498,10 @@ static void brcmf_fw_request_nvram_done(const struct 
firmware *fw, void *ctx)
brcmf_dbg(TRACE, "nvram %p len %d\n", nvram, nvram_length);
cur->nv_data.data = nvram;
cur->nv_data.len = nvram_length;
-   return;
+   return 0;
 
 fail:
-   brcmf_dbg(TRACE, "failed: dev=%s\n", dev_name(fwctx->dev));
-   fwctx->done(fwctx->dev, -ENOENT, NULL);
-   brcmf_fw_free_request(fwctx->req);
-   kfree(fwctx);
+   return -ENOENT;
 }
 
 static int brcmf_fw_request_next_item(struct brcmf_fw *fwctx, bool async)
@@ -553,20 +550,27 @@ static void brcmf_fw_request_done(const struct firmware 
*fw, void *ctx)
brcmf_dbg(TRACE, "enter: firmware %s %sfound\n", cur->path,
  fw ? "" : "not ");
 
-   if (fw) {
-   if (cur->type == BRCMF_FW_TYPE_BINARY)
-   cur->binary = fw;
-   else if (cur->type == BRCMF_FW_TYPE_NVRAM)
-   brcmf_fw_request_nvram_done(fw, fwctx);
-   else
-   release_firmware(fw);
-   } else if (cur->type == BRCMF_FW_TYPE_NVRAM) {
-   brcmf_fw_request_nvram_done(NULL, fwctx);
-   } else if (!(cur->flags & BRCMF_FW_REQF_OPTIONAL)) {
+   if (!fw)
ret = -ENOENT;
+
+   switch (cur->type) {
+   case BRCMF_FW_TYPE_NVRAM:
+   ret = brcmf_fw_request_nvram_done(fw, fwctx);
+   break;
+   case BRCMF_FW_TYPE_BINARY:
+   cur->binary = fw;
+   break;
+   default:
+   /* something fishy here so bail out early */
+   brcmf_err("unknown fw type: %d\n", cur->type);
+   release_firmware(fw);
+   ret = -EINVAL;
goto fail;
}
 
+   if (ret < 0 && !(cur->flags & BRCMF_FW_REQF_OPTIONAL))
+   goto fail;
+
do {
if (++fwctx->curpos == fwctx->req->n_items) {
ret = 0;
-- 
1.9.1

[PATCH v2 00/17] rtlwifi: halmac: Add new module halmac

[pkshih]

From: Ping-Ke Shih 

v2: remove indirection to get halmac ops
Only patches 1/17 and 11/17 are changed.

Patches 1/17-3/17 are added structure to support this module.
Patches 4/17-16/17 add new files.
Patch 17/17 add this module to Makefile and Kconfig.

Ping-Ke Shih (17):
  rtlwifi: add halmac structure to wifi.h
  rtlwifi: add debug ID COMP_HALMAC
  rtlwifi: add dmdef.h to share with driver and other modules
  rtlwifi: halmac: add main definition used by halmac
  rtlwifi: halmac: describe number and size of chip functions
  rtlwifi: halmac: add definitions of registers and bit fields
  rtlwifi: halmac: add definition of TX/RX descriptor
  rtlwifi: halmac: add GPIO pin/pinmux definitions
  rtlwifi: halmac: add power sequence to turn on/off wifi card
  rtlwifi: halmac: access efuse through halmac helper functions
  rtlwifi: halmac: add files to implement halmac ops
  rtlwifi: halmac: add halmac init/deinit functions
  rtlwifi: halmac: add firmware related functions and definitions
  rtlwifi: halmac: add bus interface commands
  rtlwifi: halmac: add to control WiFi mac functions and registers
  rtlwifi: halmac: add to support BB and RF functions
  rtlwifi: add halmac to Makefile and Kconfig

 drivers/net/wireless/realtek/rtlwifi/Kconfig   | 5 +
 drivers/net/wireless/realtek/rtlwifi/Makefile  | 1 +
 drivers/net/wireless/realtek/rtlwifi/debug.h   | 1 +
 drivers/net/wireless/realtek/rtlwifi/dmdef.h   |40 +
 .../net/wireless/realtek/rtlwifi/halmac/Makefile   |29 +
 .../halmac_88xx/halmac_8822b/halmac_8822b_cfg.h|68 +
 .../halmac_8822b/halmac_cfg_wmac_8822b.c   |   144 +
 .../halmac_8822b/halmac_cfg_wmac_8822b.h   |36 +
 .../halmac_88xx/halmac_8822b/halmac_common_8822b.c |   173 +
 .../halmac_88xx/halmac_8822b/halmac_common_8822b.h |32 +
 .../halmac_88xx/halmac_8822b/halmac_gpio_8822b.c   |   847 +
 .../halmac_88xx/halmac_8822b/halmac_gpio_8822b.h   |34 +
 .../halmac_88xx/halmac_8822b/halmac_init_8822b.c   |   688 +
 .../halmac_88xx/halmac_8822b/halmac_init_8822b.h   |33 +
 .../halmac_88xx/halmac_8822b/halmac_pcie_8822b.c   |   218 +
 .../halmac_88xx/halmac_8822b/halmac_pcie_8822b.h   |38 +
 .../halmac_88xx/halmac_8822b/halmac_phy_8822b.c|   148 +
 .../halmac_8822b/halmac_pwr_seq_8822b.c|   396 +
 .../halmac_8822b/halmac_pwr_seq_8822b.h|26 +
 .../halmac_88xx/halmac_8822b/halmac_sdio_8822b.c   |   880 +
 .../halmac_88xx/halmac_8822b/halmac_sdio_8822b.h   |62 +
 .../halmac_88xx/halmac_8822b/halmac_usb_8822b.c|   161 +
 .../halmac_88xx/halmac_8822b/halmac_usb_8822b.h|38 +
 .../rtlwifi/halmac/halmac_88xx/halmac_88xx_cfg.h   |40 +
 .../rtlwifi/halmac/halmac_88xx/halmac_bb_rf_88xx.c |   397 +
 .../rtlwifi/halmac/halmac_88xx/halmac_bb_rf_88xx.h |53 +
 .../halmac/halmac_88xx/halmac_cfg_wmac_88xx.c  |  1158 ++
 .../halmac/halmac_88xx/halmac_cfg_wmac_88xx.h  |   122 +
 .../halmac/halmac_88xx/halmac_common_88xx.c|  2931 +++
 .../halmac/halmac_88xx/halmac_common_88xx.h|   151 +
 .../rtlwifi/halmac/halmac_88xx/halmac_efuse_88xx.c |  1918 ++
 .../rtlwifi/halmac/halmac_88xx/halmac_efuse_88xx.h |   101 +
 .../rtlwifi/halmac/halmac_88xx/halmac_flash_88xx.c |   316 +
 .../rtlwifi/halmac/halmac_88xx/halmac_flash_88xx.h |35 +
 .../rtlwifi/halmac/halmac_88xx/halmac_fw_88xx.c|  1149 ++
 .../rtlwifi/halmac/halmac_88xx/halmac_fw_88xx.h|57 +
 .../rtlwifi/halmac/halmac_88xx/halmac_gpio_88xx.c  |   415 +
 .../rtlwifi/halmac/halmac_88xx/halmac_gpio_88xx.h  |55 +
 .../rtlwifi/halmac/halmac_88xx/halmac_init_88xx.c  |  1071 ++
 .../rtlwifi/halmac/halmac_88xx/halmac_init_88xx.h  |70 +
 .../rtlwifi/halmac/halmac_88xx/halmac_mimo_88xx.c  |   869 +
 .../rtlwifi/halmac/halmac_88xx/halmac_mimo_88xx.h  |79 +
 .../rtlwifi/halmac/halmac_88xx/halmac_pcie_88xx.c  |   538 +
 .../rtlwifi/halmac/halmac_88xx/halmac_pcie_88xx.h  |98 +
 .../rtlwifi/halmac/halmac_88xx/halmac_sdio_88xx.c  |   895 +
 .../rtlwifi/halmac/halmac_88xx/halmac_sdio_88xx.h  |75 +
 .../rtlwifi/halmac/halmac_88xx/halmac_usb_88xx.c   |   522 +
 .../rtlwifi/halmac/halmac_88xx/halmac_usb_88xx.h   |83 +
 .../wireless/realtek/rtlwifi/halmac/halmac_api.c   |   438 +
 .../wireless/realtek/rtlwifi/halmac/halmac_api.h   |65 +
 .../wireless/realtek/rtlwifi/halmac/halmac_bit2.h  | 18234 +++
 .../realtek/rtlwifi/halmac/halmac_bit_8822b.h  | 17870 ++
 .../realtek/rtlwifi/halmac/halmac_fw_info.h|   119 +
 .../rtlwifi/halmac/halmac_fw_offload_c2h_nic.h |   371 +
 .../rtlwifi/halmac/halmac_fw_offload_h2c_nic.h |   694 +
 .../realtek/rtlwifi/halmac/halmac_gpio_cmd.h   |84 +
 .../rtlwifi/halmac/halmac_h2c_extra_info_nic.h |   171 +
 .../realtek/rtlwifi/halmac/halmac_intf_phy_cmd.h   |45 +
 .../rtlwifi/halmac/halmac_original_c2h_nic.h   |   408 +
 .../rtlwifi/halmac/halmac_original_h2c_nic.h   |  1143 ++
 

[PATCH v2 09/17] rtlwifi: halmac: add power sequence to turn on/off wifi card

[pkshih]

From: Ping-Ke Shih 

Define power sequence command, and fill the sequences of 8822b.

Signed-off-by: Ping-Ke Shih 
---
 .../halmac_8822b/halmac_pwr_seq_8822b.c| 396 +
 .../halmac_8822b/halmac_pwr_seq_8822b.h|  26 ++
 .../realtek/rtlwifi/halmac/halmac_pwr_seq_cmd.h|  98 +
 3 files changed, 520 insertions(+)
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_pwr_seq_8822b.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_pwr_seq_8822b.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_pwr_seq_cmd.h

diff --git 
a/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_pwr_seq_8822b.c
 
b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_pwr_seq_8822b.c
new file mode 100644
index ..5aab588eb094
--- /dev/null
+++ 
b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_pwr_seq_8822b.c
@@ -0,0 +1,396 @@
+/**
+ *
+ * Copyright(c) 2016 - 2018 Realtek Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ 
**/
+
+#include "halmac_pwr_seq_8822b.h"
+
+static struct halmac_wlan_pwr_cfg TRANS_CARDDIS_TO_CARDEMU_8822B[] = {
+   /* { offset, cut_msk, interface_msk, base|cmd, msk, value } */
+   {0x0086,
+HALMAC_PWR_CUT_ALL_MSK,
+HALMAC_PWR_INTF_SDIO_MSK,
+HALMAC_PWR_ADDR_SDIO,
+HALMAC_PWR_CMD_WRITE, BIT(0), 0},
+   {0x0086,
+HALMAC_PWR_CUT_ALL_MSK,
+HALMAC_PWR_INTF_SDIO_MSK,
+HALMAC_PWR_ADDR_SDIO,
+HALMAC_PWR_CMD_POLLING, BIT(1), BIT(1)},
+   {0x004A,
+HALMAC_PWR_CUT_ALL_MSK,
+HALMAC_PWR_INTF_USB_MSK,
+HALMAC_PWR_ADDR_MAC,
+HALMAC_PWR_CMD_WRITE, BIT(0), 0},
+   {0x0005,
+HALMAC_PWR_CUT_ALL_MSK,
+HALMAC_PWR_INTF_ALL_MSK,
+HALMAC_PWR_ADDR_MAC,
+HALMAC_PWR_CMD_WRITE, BIT(3) | BIT(4) | BIT(7), 0},
+   {0x0300,
+HALMAC_PWR_CUT_ALL_MSK,
+HALMAC_PWR_INTF_PCI_MSK,
+HALMAC_PWR_ADDR_MAC,
+HALMAC_PWR_CMD_WRITE, 0xFF, 0},
+   {0x0301,
+HALMAC_PWR_CUT_ALL_MSK,
+HALMAC_PWR_INTF_PCI_MSK,
+HALMAC_PWR_ADDR_MAC,
+HALMAC_PWR_CMD_WRITE, 0xFF, 0},
+   {0x,
+HALMAC_PWR_CUT_ALL_MSK,
+HALMAC_PWR_INTF_ALL_MSK,
+0,
+HALMAC_PWR_CMD_END, 0, 0},
+};
+
+static struct halmac_wlan_pwr_cfg TRANS_CARDEMU_TO_ACT_8822B[] = {
+   /* { offset, cut_msk, interface_msk, base|cmd, msk, value } */
+   {0x0012,
+HALMAC_PWR_CUT_ALL_MSK,
+HALMAC_PWR_INTF_ALL_MSK,
+HALMAC_PWR_ADDR_MAC,
+HALMAC_PWR_CMD_WRITE, BIT(1), 0},
+   {0x0012,
+HALMAC_PWR_CUT_ALL_MSK,
+HALMAC_PWR_INTF_ALL_MSK,
+HALMAC_PWR_ADDR_MAC,
+HALMAC_PWR_CMD_WRITE, BIT(0), BIT(0)},
+   {0x0020,
+HALMAC_PWR_CUT_ALL_MSK,
+HALMAC_PWR_INTF_USB_MSK | HALMAC_PWR_INTF_SDIO_MSK,
+HALMAC_PWR_ADDR_MAC,
+HALMAC_PWR_CMD_WRITE, BIT(0), BIT(0)},
+   {0x0001,
+HALMAC_PWR_CUT_ALL_MSK,
+HALMAC_PWR_INTF_USB_MSK | HALMAC_PWR_INTF_SDIO_MSK,
+HALMAC_PWR_ADDR_MAC,
+HALMAC_PWR_CMD_DELAY, 1, HALMAC_PWR_DELAY_MS},
+   {0x,
+HALMAC_PWR_CUT_ALL_MSK,
+HALMAC_PWR_INTF_USB_MSK | HALMAC_PWR_INTF_SDIO_MSK,
+HALMAC_PWR_ADDR_MAC,
+HALMAC_PWR_CMD_WRITE, BIT(5), 0},
+   {0x0005,
+HALMAC_PWR_CUT_ALL_MSK,
+HALMAC_PWR_INTF_ALL_MSK,
+HALMAC_PWR_ADDR_MAC,
+HALMAC_PWR_CMD_WRITE, (BIT(4) | BIT(3) | BIT(2)), 0},
+   {0x0075,
+HALMAC_PWR_CUT_ALL_MSK,
+HALMAC_PWR_INTF_PCI_MSK,
+HALMAC_PWR_ADDR_MAC,
+HALMAC_PWR_CMD_WRITE, BIT(0), BIT(0)},
+   {0x0006,
+HALMAC_PWR_CUT_ALL_MSK,
+HALMAC_PWR_INTF_ALL_MSK,
+HALMAC_PWR_ADDR_MAC,
+HALMAC_PWR_CMD_POLLING, BIT(1), BIT(1)},
+   {0x0075,
+HALMAC_PWR_CUT_ALL_MSK,
+HALMAC_PWR_INTF_PCI_MSK,
+HALMAC_PWR_ADDR_MAC,
+HALMAC_PWR_CMD_WRITE, BIT(0), 0},
+   {0xFF1A,
+HALMAC_PWR_CUT_ALL_MSK,
+HALMAC_PWR_INTF_USB_MSK,
+HALMAC_PWR_ADDR_MAC,
+HALMAC_PWR_CMD_WRITE, 0xFF, 0},
+   {0x0006,
+HALMAC_PWR_CUT_ALL_MSK,
+

[PATCH v2 04/17] rtlwifi: halmac: add main definition used by halmac

[pkshih]

From: Ping-Ke Shih 

The files contain main definition of struct, enum, prototypes,
state machine, etc.

Signed-off-by: Ping-Ke Shih 
---
 .../realtek/rtlwifi/halmac/halmac_state_machine.h  |  157 ++
 .../wireless/realtek/rtlwifi/halmac/halmac_type.h  | 2134 
 2 files changed, 2291 insertions(+)
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_state_machine.h
 create mode 100644 drivers/net/wireless/realtek/rtlwifi/halmac/halmac_type.h

diff --git a/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_state_machine.h 
b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_state_machine.h
new file mode 100644
index ..d6cce79a460d
--- /dev/null
+++ b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_state_machine.h
@@ -0,0 +1,157 @@
+/**
+ *
+ * Copyright(c) 2017 - 2018 Realtek Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ 
**/
+
+#ifndef _HALMAC_STATE_MACHINE_H_
+#define _HALMAC_STATE_MACHINE_H_
+
+enum halmac_dlfw_state {
+   HALMAC_DLFW_NONE = 0,
+   HALMAC_DLFW_DONE = 1,
+   HALMAC_GEN_INFO_SENT = 2,
+
+   /* Data CPU firmware download framework */
+   HALMAC_DLFW_INIT = 0x11,
+   HALMAC_DLFW_START = 0x12,
+   HALMAC_DLFW_CONF_READY = 0x13,
+   HALMAC_DLFW_CPU_READY = 0x14,
+   HALMAC_DLFW_MEM_READY = 0x15,
+   HALMAC_DLFW_SW_READY = 0x16,
+   HALMAC_DLFW_OFLD_READY = 0x17,
+
+   HALMAC_DLFW_UNDEFINED = 0x7F,
+};
+
+enum halmac_gpio_cfg_state {
+   HALMAC_GPIO_CFG_STATE_IDLE = 0,
+   HALMAC_GPIO_CFG_STATE_BUSY = 1,
+   HALMAC_GPIO_CFG_STATE_UNDEFINED = 0x7F,
+};
+
+enum halmac_rsvd_pg_state {
+   HALMAC_RSVD_PG_STATE_IDLE = 0,
+   HALMAC_RSVD_PG_STATE_BUSY = 1,
+   HALMAC_RSVD_PG_STATE_UNDEFINED = 0x7F,
+};
+
+enum halmac_api_state {
+   HALMAC_API_STATE_INIT = 0,
+   HALMAC_API_STATE_HALT = 1,
+   HALMAC_API_STATE_UNDEFINED = 0x7F,
+};
+
+enum halmac_cmd_construct_state {
+   HALMAC_CMD_CNSTR_IDLE = 0,
+   HALMAC_CMD_CNSTR_BUSY = 1,
+   HALMAC_CMD_CNSTR_H2C_SENT = 2,
+   HALMAC_CMD_CNSTR_CNSTR = 3,
+   HALMAC_CMD_CNSTR_BUF_CLR = 4,
+   HALMAC_CMD_CNSTR_UNDEFINED = 0x7F,
+};
+
+enum halmac_cmd_process_status {
+   HALMAC_CMD_PROCESS_IDLE = 0x01, /* Init status */
+   HALMAC_CMD_PROCESS_SENDING = 0x02, /* Wait ack */
+   HALMAC_CMD_PROCESS_RCVD = 0x03, /* Rcvd ack */
+   HALMAC_CMD_PROCESS_DONE = 0x04, /* Event done */
+   HALMAC_CMD_PROCESS_ERROR = 0x05, /* Return code error */
+   HALMAC_CMD_PROCESS_UNDEFINE = 0x7F,
+};
+
+enum halmac_mac_power {
+   HALMAC_MAC_POWER_OFF = 0x0,
+   HALMAC_MAC_POWER_ON = 0x1,
+   HALMAC_MAC_POWER_UNDEFINE = 0x7F,
+};
+
+enum halmac_wlcpu_mode {
+   HALMAC_WLCPU_ACTIVE = 0x0,
+   HALMAC_WLCPU_ENTER_SLEEP = 0x1,
+   HALMAC_WLCPU_SLEEP = 0x2,
+   HALMAC_WLCPU_UNDEFINE = 0x7F,
+};
+
+struct halmac_efuse_state {
+   enum halmac_cmd_construct_state cmd_cnstr_state;
+   enum halmac_cmd_process_status proc_status;
+   u8 fw_rc;
+   u16 seq_num;
+};
+
+struct halmac_cfg_param_state {
+   enum halmac_cmd_construct_state cmd_cnstr_state;
+   enum halmac_cmd_process_status proc_status;
+   u8 fw_rc;
+   u16 seq_num;
+};
+
+struct halmac_scan_state {
+   enum halmac_cmd_construct_state cmd_cnstr_state;
+   enum halmac_cmd_process_status proc_status;
+   u8 fw_rc;
+   u16 seq_num;
+};
+
+struct halmac_update_pkt_state {
+   enum halmac_cmd_process_status proc_status;
+   u8 fw_rc;
+   u16 seq_num;
+};
+
+struct halmac_iqk_state {
+   enum halmac_cmd_process_status proc_status;
+   u8 fw_rc;
+   u16 seq_num;
+};
+
+struct halmac_pwr_tracking_state {
+   enum halmac_cmd_process_status  proc_status;
+   u8 fw_rc;
+   u16 seq_num;
+};
+
+struct halmac_psd_state {
+   enum halmac_cmd_process_status proc_status;
+   u16 data_size;
+   u16 seg_size;
+   u8 *data;
+   u8 fw_rc;
+   u16 seq_num;
+};
+
+struct halmac_fw_snding_state {
+   enum halmac_cmd_construct_state cmd_cnstr_state;
+   enum halmac_cmd_process_status proc_status;
+   u8 fw_rc;
+   u16 seq_num;
+};
+
+struct halmac_state {
+   struct halmac_efuse_state efuse_state;
+   struct halmac_cfg_param_state cfg_param_state;
+   struct halmac_scan_state scan_state;
+   

[PATCH v2 07/17] rtlwifi: halmac: add definition of TX/RX descriptor

[pkshih]

From: Ping-Ke Shih 

TX/RX descriptor are the headers to describe the packet content.

Signed-off-by: Ping-Ke Shih 
---
 .../realtek/rtlwifi/halmac/halmac_rx_bd_nic.h  |  36 ++
 .../realtek/rtlwifi/halmac/halmac_rx_desc_chip.h   | 100 +
 .../realtek/rtlwifi/halmac/halmac_rx_desc_nic.h| 123 ++
 .../realtek/rtlwifi/halmac/halmac_tx_bd_nic.h  | 106 +
 .../realtek/rtlwifi/halmac/halmac_tx_desc_chip.h   | 398 +++
 .../realtek/rtlwifi/halmac/halmac_tx_desc_nic.h| 439 +
 6 files changed, 1202 insertions(+)
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_rx_bd_nic.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_rx_desc_chip.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_rx_desc_nic.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_tx_bd_nic.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_tx_desc_chip.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_tx_desc_nic.h

diff --git a/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_rx_bd_nic.h 
b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_rx_bd_nic.h
new file mode 100644
index ..c03d4d0e4e8a
--- /dev/null
+++ b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_rx_bd_nic.h
@@ -0,0 +1,36 @@
+/**
+ *
+ * Copyright(c) 2016 - 2018 Realtek Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ 
**/
+
+#ifndef _HALMAC_RX_BD_NIC_H_
+#define _HALMAC_RX_BD_NIC_H_
+
+/*TXBD_DW0*/
+
+#define GET_RX_BD_RXFAIL(rxbd) LE_BITS_TO_4BYTE(rxbd + 0x00, 31, 1)
+#define GET_RX_BD_TOTALRXPKTSIZE(rxbd) LE_BITS_TO_4BYTE(rxbd + 0x00, 16, 13)
+#define GET_RX_BD_RXTAG(rxbd) LE_BITS_TO_4BYTE(rxbd + 0x00, 16, 13)
+#define GET_RX_BD_FS(rxbd) LE_BITS_TO_4BYTE(rxbd + 0x00, 15, 1)
+#define GET_RX_BD_LS(rxbd) LE_BITS_TO_4BYTE(rxbd + 0x00, 14, 1)
+#define GET_RX_BD_RXBUFFSIZE(rxbd) LE_BITS_TO_4BYTE(rxbd + 0x00, 0, 14)
+
+/*TXBD_DW1*/
+
+#define GET_RX_BD_PHYSICAL_ADDR_LOW(rxbd) LE_BITS_TO_4BYTE(rxbd + 0x04, 0, 32)
+
+/*TXBD_DW2*/
+
+#define GET_RX_BD_PHYSICAL_ADDR_HIGH(rxbd) LE_BITS_TO_4BYTE(rxbd + 0x08, 0, 32)
+
+#endif
diff --git a/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_rx_desc_chip.h 
b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_rx_desc_chip.h
new file mode 100644
index ..3134d3631281
--- /dev/null
+++ b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_rx_desc_chip.h
@@ -0,0 +1,100 @@
+/**
+ *
+ * Copyright(c) 2016 - 2018 Realtek Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ 
**/
+
+#ifndef _HALMAC_RX_DESC_CHIP_H_
+#define _HALMAC_RX_DESC_CHIP_H_
+
+/*RXDESC_WORD0*/
+
+#define GET_RX_DESC_EOR_8822B(rxdesc) GET_RX_DESC_EOR(rxdesc)
+#define GET_RX_DESC_PHYPKTIDC_8822B(rxdesc) GET_RX_DESC_PHYPKTIDC(rxdesc)
+#define GET_RX_DESC_SWDEC_8822B(rxdesc) GET_RX_DESC_SWDEC(rxdesc)
+#define GET_RX_DESC_PHYST_8822B(rxdesc) GET_RX_DESC_PHYST(rxdesc)
+#define GET_RX_DESC_SHIFT_8822B(rxdesc) GET_RX_DESC_SHIFT(rxdesc)
+#define GET_RX_DESC_QOS_8822B(rxdesc) GET_RX_DESC_QOS(rxdesc)
+#define GET_RX_DESC_SECURITY_8822B(rxdesc) GET_RX_DESC_SECURITY(rxdesc)
+#define GET_RX_DESC_DRV_INFO_SIZE_8822B(rxdesc)
\
+   GET_RX_DESC_DRV_INFO_SIZE(rxdesc)
+#define GET_RX_DESC_ICV_ERR_8822B(rxdesc) GET_RX_DESC_ICV_ERR(rxdesc)
+#define GET_RX_DESC_CRC32_8822B(rxdesc) GET_RX_DESC_CRC32(rxdesc)
+#define GET_RX_DESC_PKT_LEN_8822B(rxdesc) GET_RX_DESC_PKT_LEN(rxdesc)
+
+/*RXDESC_WORD1*/
+
+#define GET_RX_DESC_BC_8822B(rxdesc) GET_RX_DESC_BC(rxdesc)
+#define GET_RX_DESC_MC_8822B(rxdesc) GET_RX_DESC_MC(rxdesc)
+#define GET_RX_DESC_TY_PE_8822B(rxdesc) GET_RX_DESC_TY_PE(rxdesc)
+#define GET_RX_DESC_MF_8822B(rxdesc) GET_RX_DESC_MF(rxdesc)
+#define 

[PATCH v2 02/17] rtlwifi: add debug ID COMP_HALMAC

[pkshih]

From: Ping-Ke Shih 

Add a debug ID for the module halmac

Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/debug.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/debug.h 
b/drivers/net/wireless/realtek/rtlwifi/debug.h
index ad6834af618b..90c41c17d678 100644
--- a/drivers/net/wireless/realtek/rtlwifi/debug.h
+++ b/drivers/net/wireless/realtek/rtlwifi/debug.h
@@ -106,6 +106,7 @@
 #define COMP_BT_COEXISTBIT(30)
 #define COMP_IQK   BIT(31)
 #define COMP_TX_REPORT BIT_ULL(32)
+#define COMP_HALMACBIT_ULL(33)
 
 /*--
Define the rt_print components
-- 
2.15.1

[PATCH v2 05/17] rtlwifi: halmac: describe number and size of chip functions

[pkshih]

From: Ping-Ke Shih 

The number and size of chip fucntions are different, such as TX/RX FIFO
size, efuse size, etc. So they are defined in an individual file.

Signed-off-by: Ping-Ke Shih 
---
 .../halmac_88xx/halmac_8822b/halmac_8822b_cfg.h| 68 ++
 .../rtlwifi/halmac/halmac_88xx/halmac_88xx_cfg.h   | 40 +
 2 files changed, 108 insertions(+)
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_8822b_cfg.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_88xx_cfg.h

diff --git 
a/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_8822b_cfg.h
 
b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_8822b_cfg.h
new file mode 100644
index ..f6ed7b44549c
--- /dev/null
+++ 
b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_8822b_cfg.h
@@ -0,0 +1,68 @@
+/**
+ *
+ * Copyright(c) 2016 - 2018 Realtek Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ 
**/
+
+#ifndef _HALMAC_8822B_CFG_H_
+#define _HALMAC_8822B_CFG_H_
+
+#include "../halmac_88xx_cfg.h"
+
+#define TX_FIFO_SIZE_8822B 262144
+#define RX_FIFO_SIZE_8822B 24576
+#define TRX_SHARE_SIZE_8822B   65536
+
+#define RX_DESC_DUMMY_SIZE_8822B   72 /* 8 * 9 Bytes */
+#define RX_FIFO_EXPANDING_MODE_PKT_SIZE_MAX_8822B  80 /* 8 Byte alignment*/
+
+/* should be 8 Byte alignment*/
+#if (HALMAC_RX_FIFO_EXPANDING_MODE_PKT_SIZE <= \
+   RX_FIFO_EXPANDING_MODE_PKT_SIZE_MAX_8822B)
+#define RX_FIFO_EXPANDING_UNIT_8822B   (RX_DESC_SIZE_88XX + \
+   RX_DESC_DUMMY_SIZE_8822B + HALMAC_RX_FIFO_EXPANDING_MODE_PKT_SIZE)
+#else
+#define RX_FIFO_EXPANDING_UNIT_8822B (RX_DESC_SIZE_88XX + \
+   RX_DESC_DUMMY_SIZE_8822B + RX_FIFO_EXPANDING_MODE_PKT_SIZE_MAX_8822B)
+#endif
+
+#define TX_FIFO_SIZE_LA_8822B  (TX_FIFO_SIZE_8822B >>  1)
+#define TX_FIFO_SIZE_RX_EXPAND_1BLK_8822B  \
+   (TX_FIFO_SIZE_8822B - TRX_SHARE_SIZE_8822B)
+#define RX_FIFO_SIZE_RX_EXPAND_1BLK_8822B  \
+   RX_FIFO_EXPANDING_UNIT_8822B << 8) - 1) >> 10) << 10)
+#define TX_FIFO_SIZE_RX_EXPAND_2BLK_8822B  \
+   (TX_FIFO_SIZE_8822B - (2 * TRX_SHARE_SIZE_8822B))
+#define RX_FIFO_SIZE_RX_EXPAND_2BLK_8822B  \
+   (RX_FIFO_SIZE_8822B +  (2 * TRX_SHARE_SIZE_8822B))
+#define TX_FIFO_SIZE_RX_EXPAND_3BLK_8822B  \
+   (TX_FIFO_SIZE_8822B - (3 * TRX_SHARE_SIZE_8822B))
+#define RX_FIFO_SIZE_RX_EXPAND_3BLK_8822B  \
+   (RX_FIFO_SIZE_8822B +  (3 * TRX_SHARE_SIZE_8822B))
+
+#define EFUSE_SIZE_8822B   1024
+#define EEPROM_SIZE_8822B  768
+#define BT_EFUSE_SIZE_8822B128
+
+#define SEC_CAM_NUM_8822B  64
+
+#define OQT_ENTRY_AC_8822B 32
+#define OQT_ENTRY_NOAC_8822B   32
+#define MACID_MAX_8822B128
+
+#define WLAN_FW_IRAM_MAX_SIZE_8822B196608
+#define WLAN_FW_DRAM_MAX_SIZE_8822B49152
+#define WLAN_FW_ERAM_MAX_SIZE_8822B0
+#define WLAN_FW_MAX_SIZE_8822B (WLAN_FW_IRAM_MAX_SIZE_8822B + \
+   WLAN_FW_DRAM_MAX_SIZE_8822B + WLAN_FW_ERAM_MAX_SIZE_8822B)
+
+#endif
diff --git 
a/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_88xx_cfg.h 
b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_88xx_cfg.h
new file mode 100644
index ..22514ef4680d
--- /dev/null
+++ b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_88xx_cfg.h
@@ -0,0 +1,40 @@
+/**
+ *
+ * Copyright(c) 2016 - 2018 Realtek Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ 
**/
+
+#ifndef _HALMAC_88XX_CFG_H_
+#define _HALMAC_88XX_CFG_H_
+
+#include "../halmac_api.h"
+
+#define TX_PAGE_SIZE_88XX

[PATCH v2 10/17] rtlwifi: halmac: access efuse through halmac helper functions

[pkshih]

From: Ping-Ke Shih 

This file provides interfaces to read and write efuse contents.

Signed-off-by: Ping-Ke Shih 
---
 .../rtlwifi/halmac/halmac_88xx/halmac_efuse_88xx.c | 1918 
 .../rtlwifi/halmac/halmac_88xx/halmac_efuse_88xx.h |  101 ++
 2 files changed, 2019 insertions(+)
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_efuse_88xx.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_efuse_88xx.h

diff --git 
a/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_efuse_88xx.c 
b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_efuse_88xx.c
new file mode 100644
index ..3d51acb5857e
--- /dev/null
+++ 
b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_efuse_88xx.c
@@ -0,0 +1,1918 @@
+/**
+ *
+ * Copyright(c) 2016 - 2018 Realtek Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ 
**/
+
+#include "halmac_efuse_88xx.h"
+#include "halmac_88xx_cfg.h"
+#include "halmac_common_88xx.h"
+#include "halmac_init_88xx.h"
+
+#define RSVD_EFUSE_SIZE16
+#define RSVD_CS_EFUSE_SIZE 24
+#define PROTECT_EFUSE_SIZE 96
+#define FEATURE_DUMP_PHY_EFUSE HALMAC_FEATURE_DUMP_PHYSICAL_EFUSE
+#define FEATURE_DUMP_LOG_EFUSE HALMAC_FEATURE_DUMP_LOGICAL_EFUSE
+
+static enum halmac_cmd_construct_state
+efuse_cmd_cnstr_state_88xx(struct halmac_adapter *adapter);
+
+static enum halmac_ret_status
+proc_dump_efuse_88xx(struct halmac_adapter *adapter,
+enum halmac_efuse_read_cfg cfg);
+
+static enum halmac_ret_status
+read_hw_efuse_88xx(struct halmac_adapter *adapter, u32 offset, u32 size,
+  u8 *map);
+
+static enum halmac_ret_status
+eeprom_parser_88xx(struct halmac_adapter *adapter, u8 *phy_map, u8 *log_map);
+
+static enum halmac_ret_status
+read_log_efuse_map_88xx(struct halmac_adapter *adapter, u8 *map);
+
+static enum halmac_ret_status
+proc_pg_efuse_by_map_88xx(struct halmac_adapter *adapter,
+ struct halmac_pg_efuse_info *info,
+ enum halmac_efuse_read_cfg cfg);
+
+static enum halmac_ret_status
+dump_efuse_fw_88xx(struct halmac_adapter *adapter);
+
+static enum halmac_ret_status
+dump_efuse_drv_88xx(struct halmac_adapter *adapter);
+
+static enum halmac_ret_status
+proc_write_log_efuse_88xx(struct halmac_adapter *adapter, u32 offset, u8 
value);
+
+static enum halmac_ret_status
+update_eeprom_mask_88xx(struct halmac_adapter *adapter,
+   struct halmac_pg_efuse_info *info, u8 *updated_mask);
+
+static enum halmac_ret_status
+check_efuse_enough_88xx(struct halmac_adapter *adapter,
+   struct halmac_pg_efuse_info *info, u8 *updated_mask);
+
+static enum halmac_ret_status
+pg_extend_efuse_88xx(struct halmac_adapter *adapter,
+struct halmac_pg_efuse_info *info, u8 word_en,
+u8 pre_word_en, u32 eeprom_offset);
+
+static enum halmac_ret_status
+proc_pg_efuse_88xx(struct halmac_adapter *adapter,
+  struct halmac_pg_efuse_info *info, u8 word_en,
+  u8 pre_word_en, u32 eeprom_offset);
+
+static enum halmac_ret_status
+program_efuse_88xx(struct halmac_adapter *adapter,
+  struct halmac_pg_efuse_info *info, u8 *updated_mask);
+
+static void
+mask_eeprom_88xx(struct halmac_adapter *adapter,
+struct halmac_pg_efuse_info *info);
+
+/**
+ * dump_efuse_map_88xx() - dump "physical" efuse map
+ * @adapter : the adapter of halmac
+ * @cfg : dump efuse method
+ * Author : Ivan Lin/KaiYuan Chang
+ * Return : enum halmac_ret_status
+ * More details of status code can be found in prototype document
+ */
+enum halmac_ret_status
+dump_efuse_map_88xx(struct halmac_adapter *adapter,
+   enum halmac_efuse_read_cfg cfg)
+{
+   u8 *map = NULL;
+   u8 *efuse_map;
+   u32 efuse_size = adapter->hw_cfg_info.efuse_size;
+   enum halmac_ret_status status = HALMAC_RET_SUCCESS;
+   enum halmac_cmd_process_status *proc_status;
+
+   proc_status = >halmac_state.efuse_state.proc_status;
+
+   if (cfg == HALMAC_EFUSE_R_FW &&
+   halmac_fw_validate(adapter) != HALMAC_RET_SUCCESS)
+   return HALMAC_RET_NO_DLFW;
+
+   RT_TRACE(adapter->drv_adapter, COMP_HALMAC, DBG_DMESG, "%s ===>\n",
+

[PATCH v2 01/17] rtlwifi: add halmac structure to wifi.h

[pkshih]

From: Ping-Ke Shih 

Add structure and ops to interact with halmac and other modules.

Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/wifi.h | 58 +
 1 file changed, 58 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h 
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index d27e33960e77..c8542b87cc2b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -2305,6 +2305,13 @@ struct rtl_hal_ops {
u16 (*get_available_desc)(struct ieee80211_hw *hw, u8 q_idx);
void (*c2h_content_parsing)(struct ieee80211_hw *hw, u8 tag, u8 len,
u8 *val);
+   /* ops for halmac cb */
+   bool (*halmac_cb_init_mac_register)(struct rtl_priv *rtlpriv);
+   bool (*halmac_cb_init_bb_rf_register)(struct rtl_priv *rtlpriv);
+   bool (*halmac_cb_write_data_rsvd_page)(struct rtl_priv *rtlpriv,
+  u8 *buf, u32 size);
+   bool (*halmac_cb_write_data_h2c)(struct rtl_priv *rtlpriv, u8 *buf,
+u32 size);
 };
 
 struct rtl_intf_ops {
@@ -2687,6 +2694,54 @@ struct rtl_btc_ops {
bool (*btc_is_bt_lps_on)(struct rtl_priv *rtlpriv);
 };
 
+struct rtl_halmac_ops {
+   int (*halmac_init_adapter)(struct rtl_priv *rtlpriv);
+   int (*halmac_deinit_adapter)(struct rtl_priv *rtlpriv);
+   int (*halmac_init_hal)(struct rtl_priv *rtlpriv);
+   int (*halmac_deinit_hal)(struct rtl_priv *rtlpriv);
+   int (*halmac_poweron)(struct rtl_priv *rtlpriv);
+   int (*halmac_poweroff)(struct rtl_priv *rtlpriv);
+
+   int (*halmac_phy_power_switch)(struct rtl_priv *rtlpriv, u8 enable);
+   int (*halmac_set_mac_address)(struct rtl_priv *rtlpriv, u8 hwport,
+ u8 *addr);
+   int (*halmac_set_bssid)(struct rtl_priv *rtlpriv, u8 hwport, u8 *addr);
+
+   int (*halmac_get_physical_efuse_size)(struct rtl_priv *rtlpriv,
+ u32 *size);
+   int (*halmac_read_physical_efuse_map)(struct rtl_priv *rtlpriv,
+ u8 *map, u32 size);
+   int (*halmac_get_logical_efuse_size)(struct rtl_priv *rtlpriv,
+u32 *size);
+   int (*halmac_read_logical_efuse_map)(struct rtl_priv *rtlpriv, u8 *map,
+u32 size);
+
+   int (*halmac_set_bandwidth)(struct rtl_priv *rtlpriv, u8 channel,
+   u8 pri_ch_idx, u8 bw);
+
+   int (*halmac_c2h_handle)(struct rtl_priv *rtlpriv, u8 *c2h, u32 size);
+
+   int (*halmac_chk_txdesc)(struct rtl_priv *rtlpriv, u8 *txdesc,
+u32 size);
+   int (*halmac_iqk)(struct rtl_priv *rtlpriv, u8 clear, u8 segment);
+};
+
+struct rtl_halmac_indicator {
+   struct completion *comp;
+   u32 wait_ms;
+
+   u8 *buffer;
+   u32 buf_size;
+   u32 ret_size;
+   u32 status;
+};
+
+struct rtl_halmac {
+   const struct rtl_halmac_ops *ops;
+   void *internal; /* internal context of halmac, i.e. PHALMAC_ADAPTER */
+   struct rtl_halmac_indicator *indicator; /* size=10 */
+};
+
 struct proxim {
bool proxim_on;
 
@@ -2792,6 +2847,9 @@ struct rtl_priv {
/*for bt coexist use*/
struct bt_coexist_info btcoexist;
 
+   /* halmac for newer ICs */
+   struct rtl_halmac halmac;
+
/* separate 92ee from other ICs,
 * 92ee use new trx flow.
 */
-- 
2.15.1

[PATCH v2 11/17] rtlwifi: halmac: add files to implement halmac ops

[pkshih]

From: Ping-Ke Shih 

The structure halmac_ops defined in wifi.h, and this commit implements and
hooks ops to the structure, so a symbol rtl_halmac_get_ops_pointer is
expoerted to access this module. Meanwhile, we implement ops defined and
needed by this module.

Signed-off-by: Ping-Ke Shih 
---
 .../wireless/realtek/rtlwifi/halmac/rtl_halmac.c   | 1403 
 .../wireless/realtek/rtlwifi/halmac/rtl_halmac.h   |   77 ++
 2 files changed, 1480 insertions(+)
 create mode 100644 drivers/net/wireless/realtek/rtlwifi/halmac/rtl_halmac.c
 create mode 100644 drivers/net/wireless/realtek/rtlwifi/halmac/rtl_halmac.h

diff --git a/drivers/net/wireless/realtek/rtlwifi/halmac/rtl_halmac.c 
b/drivers/net/wireless/realtek/rtlwifi/halmac/rtl_halmac.c
new file mode 100644
index ..d9b81824728d
--- /dev/null
+++ b/drivers/net/wireless/realtek/rtlwifi/halmac/rtl_halmac.c
@@ -0,0 +1,1403 @@
+/**
+ *
+ * Copyright(c) 2016 - 2018 Realtek Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ 
**/
+
+#include "halmac_api.h"
+#include "rtl_halmac.h"
+#include 
+#include 
+
+#define rtlpriv_to_halmac(priv)
\
+   ((struct halmac_adapter *)((priv)->halmac.internal))
+
+#define DEFAULT_INDICATOR_TIMELMT msecs_to_jiffies(1000) /* ms */
+
+const struct rtl_halmac_ops rtl_halmac_operation = {
+   .halmac_init_adapter = rtl_halmac_init_adapter,
+   .halmac_deinit_adapter = rtl_halmac_deinit_adapter,
+   .halmac_init_hal = rtl_halmac_init_hal,
+   .halmac_deinit_hal = rtl_halmac_deinit_hal,
+   .halmac_poweron = rtl_halmac_poweron,
+   .halmac_poweroff = rtl_halmac_poweroff,
+
+   .halmac_phy_power_switch = rtl_halmac_phy_power_switch,
+   .halmac_set_mac_address = rtl_halmac_set_mac_address,
+   .halmac_set_bssid = rtl_halmac_set_bssid,
+
+   .halmac_get_physical_efuse_size = rtl_halmac_get_physical_efuse_size,
+   .halmac_read_physical_efuse_map = rtl_halmac_read_physical_efuse_map,
+   .halmac_get_logical_efuse_size = rtl_halmac_get_logical_efuse_size,
+   .halmac_read_logical_efuse_map = rtl_halmac_read_logical_efuse_map,
+
+   .halmac_set_bandwidth = rtl_halmac_set_bandwidth,
+
+   .halmac_c2h_handle = rtl_halmac_c2h_handle,
+
+   .halmac_chk_txdesc = rtl_halmac_chk_txdesc,
+   .halmac_iqk = rtl_halmac_iqk,
+};
+EXPORT_SYMBOL(rtl_halmac_operation);
+
+enum pltfm_ret_status {
+   FLTFM_RET_FAIL = 0,
+   FLTFM_RET_SUCCESS = 1,
+};
+
+static u8 _halmac_reg_read_8(void *p, u32 offset)
+{
+   struct rtl_priv *rtlpriv = (struct rtl_priv *)p;
+
+   return rtl_read_byte(rtlpriv, offset);
+}
+
+static u16 _halmac_reg_read_16(void *p, u32 offset)
+{
+   struct rtl_priv *rtlpriv = (struct rtl_priv *)p;
+
+   return rtl_read_word(rtlpriv, offset);
+}
+
+static u32 _halmac_reg_read_32(void *p, u32 offset)
+{
+   struct rtl_priv *rtlpriv = (struct rtl_priv *)p;
+
+   return rtl_read_dword(rtlpriv, offset);
+}
+
+static void _halmac_reg_write_8(void *p, u32 offset, u8 val)
+{
+   struct rtl_priv *rtlpriv = (struct rtl_priv *)p;
+
+   rtl_write_byte(rtlpriv, offset, val);
+}
+
+static void _halmac_reg_write_16(void *p, u32 offset, u16 val)
+{
+   struct rtl_priv *rtlpriv = (struct rtl_priv *)p;
+
+   rtl_write_word(rtlpriv, offset, val);
+}
+
+static void _halmac_reg_write_32(void *p, u32 offset, u32 val)
+{
+   struct rtl_priv *rtlpriv = (struct rtl_priv *)p;
+
+   rtl_write_dword(rtlpriv, offset, val);
+}
+
+static u8 _halmac_write_data_rsvd_page(void *p, u8 *buf, u32 size)
+{
+   struct rtl_priv *rtlpriv = (struct rtl_priv *)p;
+
+   if (rtlpriv->cfg->ops->halmac_cb_write_data_rsvd_page &&
+   rtlpriv->cfg->ops->halmac_cb_write_data_rsvd_page(rtlpriv, buf,
+ size))
+   return FLTFM_RET_SUCCESS;
+
+   return FLTFM_RET_FAIL;
+}
+
+static u8 _halmac_write_data_h2c(void *p, u8 *buf, u32 size)
+{
+   struct rtl_priv *rtlpriv = (struct rtl_priv *)p;
+
+   if (rtlpriv->cfg->ops->halmac_cb_write_data_h2c &&
+   rtlpriv->cfg->ops->halmac_cb_write_data_h2c(rtlpriv, buf, size))
+   return FLTFM_RET_SUCCESS;
+
+   return FLTFM_RET_FAIL;
+}
+
+static const char *const RTL_HALMAC_FEATURE_NAME[] = {
+   

[PATCH v2 08/17] rtlwifi: halmac: add GPIO pin/pinmux definitions

[pkshih]

From: Ping-Ke Shih 

GPIO with pinmux can switch to many functions such as LED, UART, JTAG,
WoWLAN, etc.

Signed-off-by: Ping-Ke Shih 
---
 .../halmac_88xx/halmac_8822b/halmac_gpio_8822b.c   | 847 +
 .../halmac_88xx/halmac_8822b/halmac_gpio_8822b.h   |  34 +
 .../rtlwifi/halmac/halmac_88xx/halmac_gpio_88xx.c  | 415 ++
 .../rtlwifi/halmac/halmac_88xx/halmac_gpio_88xx.h  |  55 ++
 .../realtek/rtlwifi/halmac/halmac_gpio_cmd.h   |  84 ++
 5 files changed, 1435 insertions(+)
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_gpio_8822b.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_gpio_8822b.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_gpio_88xx.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_gpio_88xx.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_gpio_cmd.h

diff --git 
a/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_gpio_8822b.c
 
b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_gpio_8822b.c
new file mode 100644
index ..3d43de98bb46
--- /dev/null
+++ 
b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_gpio_8822b.c
@@ -0,0 +1,847 @@
+/**
+ *
+ * Copyright(c) 2016 - 2018 Realtek Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ 
**/
+
+#include "halmac_gpio_8822b.h"
+#include "../halmac_gpio_88xx.h"
+
+/* GPIO0 definition */
+#define GPIO0_BT_GPIO0_8822B   \
+   {HALMAC_BT_GPIO, HALMAC_GPIO0, HALMAC_GPIO_IN_OUT, \
+0x66, BIT(2), BIT(2)}
+#define GPIO0_BT_ACT_8822B \
+   {HALMAC_BT_PTA, HALMAC_GPIO0, HALMAC_GPIO_IN_OUT, \
+0x41, BIT(1), 0}
+#define GPIO0_WL_ACT_8822B \
+   {HALMAC_WL_PTA, HALMAC_GPIO0, HALMAC_GPIO_IN_OUT, \
+0x41, BIT(2), BIT(2)}
+#define GPIO0_WLMAC_DBG_GPIO0_8822B\
+   {HALMAC_WLMAC_DBG, HALMAC_GPIO0, HALMAC_GPIO_OUT, \
+0x40, BIT(1) | BIT(0), BIT(0)}
+#define GPIO0_WLPHY_DBG_GPIO0_8822B\
+   {HALMAC_WLPHY_DBG, HALMAC_GPIO0, HALMAC_GPIO_IN_OUT, \
+0x40, BIT(1) | BIT(0), BIT(1)}
+#define GPIO0_BT_DBG_GPIO0_8822B   \
+   {HALMAC_BT_DBG, HALMAC_GPIO0, HALMAC_GPIO_OUT, \
+   0x40, BIT(1) | BIT(0), BIT(0) | BIT(1)}
+#define GPIO0_SW_IO_8822B  \
+   {HALMAC_SW_IO, HALMAC_GPIO0, HALMAC_GPIO_IN_OUT, \
+0x40, BIT(1) | BIT(0), 0}
+
+/* GPIO1 definition */
+#define GPIO1_BT_GPIO1_8822B   \
+   {HALMAC_BT_GPIO, HALMAC_GPIO1, HALMAC_GPIO_IN_OUT, \
+0x66, BIT(2), BIT(2)}
+#define GPIO1_BT_3DD_SYNC_A_8822B  \
+   {HALMAC_BT_3DDLS_A, HALMAC_GPIO1, HALMAC_GPIO_IN, \
+0x66, BIT(2), BIT(2)}
+#define GPIO1_WL_CK_8822B  \
+   {HALMAC_BT_PTA, HALMAC_GPIO1, HALMAC_GPIO_OUT, \
+0x41, BIT(1), 0}
+#define GPIO1_BT_CK_8822B  \
+   {HALMAC_WL_PTA, HALMAC_GPIO1, HALMAC_GPIO_OUT, \
+0x41, BIT(2), BIT(2)}
+#define GPIO1_WLMAC_DBG_GPIO1_8822B\
+   {HALMAC_WLMAC_DBG, HALMAC_GPIO1, HALMAC_GPIO_OUT, \
+0x40, BIT(1) | BIT(0), BIT(0)}
+#define GPIO1_WLPHY_DBG_GPIO1_8822B\
+   {HALMAC_WLPHY_DBG, HALMAC_GPIO1, HALMAC_GPIO_IN_OUT, \
+0x40, BIT(1) | BIT(0), BIT(1)}
+#define GPIO1_BT_DBG_GPIO1_8822B   \
+   {HALMAC_BT_DBG, HALMAC_GPIO1, HALMAC_GPIO_OUT, \
+0x40, BIT(1) | BIT(0), BIT(0) | BIT(1)}
+#define GPIO1_SW_IO_8822B  \
+   {HALMAC_SW_IO, HALMAC_GPIO1, HALMAC_GPIO_IN_OUT, \
+0x40, BIT(1) | BIT(0), 0}
+
+/* GPIO2 definition */
+#define GPIO2_BT_GPIO2_8822B   \
+   {HALMAC_BT_GPIO, HALMAC_GPIO2, HALMAC_GPIO_IN_OUT, \
+0x66, BIT(2), BIT(2)}
+#define GPIO2_WL_STATE_8822B   \
+   {HALMAC_BT_PTA, HALMAC_GPIO2, HALMAC_GPIO_OUT, \
+0x41, BIT(1), 0}
+#define GPIO2_BT_STATE_8822B   \
+   {HALMAC_WL_PTA, HALMAC_GPIO2, HALMAC_GPIO_OUT, \
+0x41, BIT(2), BIT(2)}
+#define GPIO2_WLMAC_DBG_GPIO2_8822B\
+   {HALMAC_WLMAC_DBG, HALMAC_GPIO2, HALMAC_GPIO_OUT, \
+0x40, BIT(1) | BIT(0), BIT(0)}
+#define GPIO2_WLPHY_DBG_GPIO2_8822B\
+   {HALMAC_WLPHY_DBG, HALMAC_GPIO2, HALMAC_GPIO_IN_OUT, \
+0x40, BIT(1) | BIT(0), BIT(1)}
+#define GPIO2_BT_DBG_GPIO2_8822B   \
+   {HALMAC_BT_DBG, HALMAC_GPIO2, 

[PATCH v2 03/17] rtlwifi: add dmdef.h to share with driver and other modules

[pkshih]

From: Ping-Ke Shih 

This header file is maintained by new module phydm, and share with
driver and other modules, such as halmac. This patch adds only one
enumeration, and more information will be added later.

Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/dmdef.h | 40 
 drivers/net/wireless/realtek/rtlwifi/wifi.h  |  1 +
 2 files changed, 41 insertions(+)
 create mode 100644 drivers/net/wireless/realtek/rtlwifi/dmdef.h

diff --git a/drivers/net/wireless/realtek/rtlwifi/dmdef.h 
b/drivers/net/wireless/realtek/rtlwifi/dmdef.h
new file mode 100644
index ..5560cd1f98ed
--- /dev/null
+++ b/drivers/net/wireless/realtek/rtlwifi/dmdef.h
@@ -0,0 +1,40 @@
+/**
+ *
+ * Copyright(c) 2007 - 2018 Realtek Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ 
**/
+
+#ifndef __RTL_DMINFO_H__
+#define __RTL_DMINFO_H__
+
+enum bb_path {
+   BB_PATH_A = 0x0001,
+   BB_PATH_B = 0x0002,
+   BB_PATH_C = 0x0004,
+   BB_PATH_D = 0x0008,
+
+   BB_PATH_AB = (BB_PATH_A | BB_PATH_B),
+   BB_PATH_AC = (BB_PATH_A | BB_PATH_C),
+   BB_PATH_AD = (BB_PATH_A | BB_PATH_D),
+   BB_PATH_BC = (BB_PATH_B | BB_PATH_C),
+   BB_PATH_BD = (BB_PATH_B | BB_PATH_D),
+   BB_PATH_CD = (BB_PATH_C | BB_PATH_D),
+
+   BB_PATH_ABC = (BB_PATH_A | BB_PATH_B | BB_PATH_C),
+   BB_PATH_ABD = (BB_PATH_A | BB_PATH_B | BB_PATH_D),
+   BB_PATH_ACD = (BB_PATH_A | BB_PATH_C | BB_PATH_D),
+   BB_PATH_BCD = (BB_PATH_B | BB_PATH_C | BB_PATH_D),
+
+   BB_PATH_ABCD = (BB_PATH_A | BB_PATH_B | BB_PATH_C | BB_PATH_D),
+};
+
+#endif
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h 
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index c8542b87cc2b..c32985cfe48d 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include "dmdef.h"
 #include "debug.h"
 
 #defineMASKBYTE0   0xff
-- 
2.15.1

[PATCH v2 15/17] rtlwifi: halmac: add to control WiFi mac functions and registers

[pkshih]

From: Ping-Ke Shih 

This commit provides WiFi mac functions to control wifi easier, and also
provides generic access entries for driver and other modules.

Signed-off-by: Ping-Ke Shih 
---
 .../halmac_8822b/halmac_cfg_wmac_8822b.c   |  144 +
 .../halmac_8822b/halmac_cfg_wmac_8822b.h   |   36 +
 .../halmac_88xx/halmac_8822b/halmac_common_8822b.c |  173 ++
 .../halmac_88xx/halmac_8822b/halmac_common_8822b.h |   32 +
 .../halmac/halmac_88xx/halmac_cfg_wmac_88xx.c  | 1158 
 .../halmac/halmac_88xx/halmac_cfg_wmac_88xx.h  |  122 +
 .../halmac/halmac_88xx/halmac_common_88xx.c| 2931 
 .../halmac/halmac_88xx/halmac_common_88xx.h|  151 +
 8 files changed, 4747 insertions(+)
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_cfg_wmac_8822b.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_cfg_wmac_8822b.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_common_8822b.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_common_8822b.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_cfg_wmac_88xx.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_cfg_wmac_88xx.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_common_88xx.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_common_88xx.h

diff --git 
a/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_cfg_wmac_8822b.c
 
b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_cfg_wmac_8822b.c
new file mode 100644
index ..7de83d7bf922
--- /dev/null
+++ 
b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_cfg_wmac_8822b.c
@@ -0,0 +1,144 @@
+/**
+ *
+ * Copyright(c) 2017 - 2018 Realtek Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ 
**/
+
+#include "halmac_cfg_wmac_8822b.h"
+#include "halmac_8822b_cfg.h"
+
+/**
+ * cfg_drv_info_8822b() - config driver info
+ * @adapter : the adapter of halmac
+ * @drv_info : driver information selection
+ * Author : KaiYuan Chang/Ivan Lin
+ * Return : enum halmac_ret_status
+ * More details of status code can be found in prototype document
+ */
+enum halmac_ret_status
+cfg_drv_info_8822b(struct halmac_adapter *adapter,
+  enum halmac_drv_info drv_info)
+{
+   u8 drv_info_size = 0;
+   u8 phy_status_en = 0;
+   u8 sniffer_en = 0;
+   u8 plcp_hdr_en = 0;
+   u8 value8;
+   u32 value32;
+   struct halmac_api *api = (struct halmac_api *)adapter->halmac_api;
+
+   RT_TRACE(adapter->drv_adapter, COMP_HALMAC, DBG_DMESG, "%s ===>\n",
+__func__);
+   RT_TRACE(adapter->drv_adapter, COMP_HALMAC, DBG_DMESG,
+"drv info = %d\n", drv_info);
+
+   switch (drv_info) {
+   case HALMAC_DRV_INFO_NONE:
+   drv_info_size = 0;
+   phy_status_en = 0;
+   sniffer_en = 0;
+   plcp_hdr_en = 0;
+   break;
+   case HALMAC_DRV_INFO_PHY_STATUS:
+   drv_info_size = 4;
+   phy_status_en = 1;
+   sniffer_en = 0;
+   plcp_hdr_en = 0;
+   break;
+   case HALMAC_DRV_INFO_PHY_SNIFFER:
+   drv_info_size = 5; /* phy status 4byte, sniffer info 1byte */
+   phy_status_en = 1;
+   sniffer_en = 1;
+   plcp_hdr_en = 0;
+   break;
+   case HALMAC_DRV_INFO_PHY_PLCP:
+   drv_info_size = 6; /* phy status 4byte, plcp header 2byte */
+   phy_status_en = 1;
+   sniffer_en = 0;
+   plcp_hdr_en = 1;
+   break;
+   default:
+   return HALMAC_RET_SW_CASE_NOT_SUPPORT;
+   }
+
+   if (adapter->txff_alloc.rx_fifo_exp_mode !=
+   HALMAC_RX_FIFO_EXPANDING_MODE_DISABLE)
+   drv_info_size = RX_DESC_DUMMY_SIZE_8822B >> 3;
+
+   HALMAC_REG_W8(REG_RX_DRVINFO_SZ, drv_info_size);
+
+   value8 = HALMAC_REG_R8(REG_TRXFF_BNDY + 1);
+   value8 &= 0xF0;
+   /* For rxdesc len = 0 issue */
+   value8 |= 0xF;
+   

[PATCH v2 12/17] rtlwifi: halmac: add halmac init/deinit functions

[pkshih]

From: Ping-Ke Shih 

Add files to initialize and free halmac context. Since halmac is an three
levels hierarchy file structure, so the added files provide interfaces of
halmac, 88xx and 8822b.

Signed-off-by: Ping-Ke Shih 
---
 .../halmac_88xx/halmac_8822b/halmac_init_8822b.c   |  688 +
 .../halmac_88xx/halmac_8822b/halmac_init_8822b.h   |   33 +
 .../rtlwifi/halmac/halmac_88xx/halmac_init_88xx.c  | 1071 
 .../rtlwifi/halmac/halmac_88xx/halmac_init_88xx.h  |   70 ++
 .../wireless/realtek/rtlwifi/halmac/halmac_api.c   |  438 
 .../wireless/realtek/rtlwifi/halmac/halmac_api.h   |   65 ++
 6 files changed, 2365 insertions(+)
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_init_8822b.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_init_8822b.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_init_88xx.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_init_88xx.h
 create mode 100644 drivers/net/wireless/realtek/rtlwifi/halmac/halmac_api.c
 create mode 100644 drivers/net/wireless/realtek/rtlwifi/halmac/halmac_api.h

diff --git 
a/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_init_8822b.c
 
b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_init_8822b.c
new file mode 100644
index ..57509fd5942a
--- /dev/null
+++ 
b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_init_8822b.c
@@ -0,0 +1,688 @@
+/**
+ *
+ * Copyright(c) 2016 - 2018 Realtek Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ 
**/
+
+#include "halmac_init_8822b.h"
+#include "halmac_8822b_cfg.h"
+#include "halmac_pcie_8822b.h"
+#include "halmac_sdio_8822b.h"
+#include "halmac_usb_8822b.h"
+#include "halmac_gpio_8822b.h"
+#include "halmac_common_8822b.h"
+#include "halmac_cfg_wmac_8822b.h"
+#include "../halmac_common_88xx.h"
+#include "../halmac_init_88xx.h"
+
+#define RSVD_PG_DRV_NUM16
+#define RSVD_PG_H2C_EXTRAINFO_NUM  24
+#define RSVD_PG_H2C_STATICINFO_NUM 8
+#define RSVD_PG_H2CQ_NUM   8
+#define RSVD_PG_CPU_INSTRUCTION_NUM0
+#define RSVD_PG_FW_TXBUF_NUM   4
+#define RSVD_PG_CSIBUF_NUM 0
+#define RSVD_PG_DLLB_NUM   (TX_FIFO_SIZE_8822B / 3 >> \
+   TX_PAGE_SIZE_SHIFT_88XX)
+
+#define MAC_TRX_ENABLE (BIT_HCI_TXDMA_EN | BIT_HCI_RXDMA_EN | BIT_TXDMA_EN | \
+   BIT_RXDMA_EN | BIT_PROTOCOL_EN | BIT_SCHEDULE_EN | \
+   BIT_MACTXEN | BIT_MACRXEN)
+
+#define BLK_DESC_NUM   0x3
+
+#define WLAN_AMPDU_MAX_TIME0x70
+#define WLAN_RTS_LEN_TH0xFF
+#define WLAN_RTS_TX_TIME_TH0x08
+#define WLAN_MAX_AGG_PKT_LIMIT 0x20
+#define WLAN_RTS_MAX_AGG_PKT_LIMIT 0x20
+#define WALN_FAST_EDCA_VO_TH   0x06
+#define WLAN_FAST_EDCA_VI_TH   0x06
+#define WLAN_FAST_EDCA_BE_TH   0x06
+#define WLAN_FAST_EDCA_BK_TH   0x06
+#define WLAN_BAR_RETRY_LIMIT   0x01
+#define WLAN_RA_TRY_RATE_AGG_LIMIT 0x08
+
+/*SDIO RQPN Mapping*/
+static struct halmac_rqpn HALMAC_RQPN_SDIO_8822B[] = {
+   /* { mode, vo_map, vi_map, be_map, bk_map, mg_map, hi_map } */
+   {HALMAC_TRX_MODE_NORMAL,
+HALMAC_MAP2_NQ, HALMAC_MAP2_NQ, HALMAC_MAP2_LQ, HALMAC_MAP2_LQ,
+HALMAC_MAP2_EXQ, HALMAC_MAP2_HQ},
+   {HALMAC_TRX_MODE_TRXSHARE,
+HALMAC_MAP2_NQ, HALMAC_MAP2_NQ, HALMAC_MAP2_LQ, HALMAC_MAP2_LQ,
+HALMAC_MAP2_EXQ, HALMAC_MAP2_HQ},
+   {HALMAC_TRX_MODE_WMM,
+HALMAC_MAP2_HQ, HALMAC_MAP2_NQ, HALMAC_MAP2_LQ, HALMAC_MAP2_NQ,
+HALMAC_MAP2_EXQ, HALMAC_MAP2_HQ},
+   {HALMAC_TRX_MODE_P2P,
+HALMAC_MAP2_NQ, HALMAC_MAP2_NQ, HALMAC_MAP2_LQ, HALMAC_MAP2_LQ,
+HALMAC_MAP2_EXQ, HALMAC_MAP2_HQ},
+   {HALMAC_TRX_MODE_LOOPBACK,
+HALMAC_MAP2_NQ, HALMAC_MAP2_NQ, HALMAC_MAP2_LQ, HALMAC_MAP2_LQ,
+HALMAC_MAP2_EXQ, HALMAC_MAP2_HQ},
+   {HALMAC_TRX_MODE_DELAY_LOOPBACK,
+HALMAC_MAP2_NQ, HALMAC_MAP2_NQ, HALMAC_MAP2_LQ, HALMAC_MAP2_LQ,
+HALMAC_MAP2_EXQ, HALMAC_MAP2_HQ},
+};
+
+/*PCIE RQPN Mapping*/
+static struct halmac_rqpn HALMAC_RQPN_PCIE_8822B[] 

[PATCH v2 16/17] rtlwifi: halmac: add to support BB and RF functions

[pkshih]

From: Ping-Ke Shih 

Some BB and RF functions collaborate with firmware or MAC. For instances,
the IQK and PSD functions are implemented in firmware, so use a H2C command
to trigger. For MIMO function, use the helper functions to control related
MAC registers.

Signed-off-by: Ping-Ke Shih 
---
 .../rtlwifi/halmac/halmac_88xx/halmac_bb_rf_88xx.c | 397 ++
 .../rtlwifi/halmac/halmac_88xx/halmac_bb_rf_88xx.h |  53 ++
 .../rtlwifi/halmac/halmac_88xx/halmac_mimo_88xx.c  | 869 +
 .../rtlwifi/halmac/halmac_88xx/halmac_mimo_88xx.h  |  79 ++
 4 files changed, 1398 insertions(+)
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_bb_rf_88xx.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_bb_rf_88xx.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_mimo_88xx.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_mimo_88xx.h

diff --git 
a/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_bb_rf_88xx.c 
b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_bb_rf_88xx.c
new file mode 100644
index ..06990ee78ebd
--- /dev/null
+++ 
b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_bb_rf_88xx.c
@@ -0,0 +1,397 @@
+/**
+ *
+ * Copyright(c) 2016 - 2018 Realtek Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ 
**/
+
+#include "halmac_bb_rf_88xx.h"
+#include "halmac_88xx_cfg.h"
+#include "halmac_common_88xx.h"
+#include "halmac_init_88xx.h"
+
+/**
+ * start_iqk_88xx() -trigger FW IQK
+ * @adapter : the adapter of halmac
+ * @param : IQK parameter
+ * Author : KaiYuan Chang/Ivan Lin
+ * Return : enum halmac_ret_status
+ * More details of status code can be found in prototype document
+ */
+enum halmac_ret_status
+start_iqk_88xx(struct halmac_adapter *adapter, struct halmac_iqk_para *param)
+{
+   u8 h2c_buf[H2C_PKT_SIZE_88XX] = { 0 };
+   u16 seq_num = 0;
+   enum halmac_ret_status status = HALMAC_RET_SUCCESS;
+   struct halmac_h2c_header_info hdr_info;
+   enum halmac_cmd_process_status *proc_status;
+
+   proc_status = >halmac_state.iqk_state.proc_status;
+
+   if (halmac_fw_validate(adapter) != HALMAC_RET_SUCCESS)
+   return HALMAC_RET_NO_DLFW;
+
+   RT_TRACE(adapter->drv_adapter, COMP_HALMAC, DBG_DMESG, "%s ===>\n",
+__func__);
+
+   if (*proc_status == HALMAC_CMD_PROCESS_SENDING) {
+   RT_TRACE(adapter->drv_adapter, COMP_HALMAC, DBG_DMESG,
+"Wait event(iqk)\n");
+   return HALMAC_RET_BUSY_STATE;
+   }
+
+   *proc_status = HALMAC_CMD_PROCESS_SENDING;
+
+   IQK_SET_CLEAR(h2c_buf, param->clear);
+   IQK_SET_SEGMENT_IQK(h2c_buf, param->segment_iqk);
+
+   hdr_info.sub_cmd_id = SUB_CMD_ID_IQK;
+   hdr_info.content_size = 1;
+   hdr_info.ack = 1;
+   set_h2c_pkt_hdr_88xx(adapter, h2c_buf, _info, _num);
+
+   adapter->halmac_state.iqk_state.seq_num = seq_num;
+
+   status = send_h2c_pkt_88xx(adapter, h2c_buf);
+
+   if (status != HALMAC_RET_SUCCESS) {
+   pr_err("send h2c pkt fail!!\n");
+   reset_ofld_feature_88xx(adapter, HALMAC_FEATURE_IQK);
+   return status;
+   }
+
+   RT_TRACE(adapter->drv_adapter, COMP_HALMAC, DBG_DMESG, "%s <===\n",
+__func__);
+
+   return HALMAC_RET_SUCCESS;
+}
+
+/**
+ * ctrl_pwr_tracking_88xx() -trigger FW power tracking
+ * @adapter : the adapter of halmac
+ * @opt : power tracking option
+ * Author : KaiYuan Chang/Ivan Lin
+ * Return : enum halmac_ret_status
+ * More details of status code can be found in prototype document
+ */
+enum halmac_ret_status
+ctrl_pwr_tracking_88xx(struct halmac_adapter *adapter,
+  struct halmac_pwr_tracking_option *opt)
+{
+   u8 h2c_buf[H2C_PKT_SIZE_88XX] = { 0 };
+   u16 seq_num = 0;
+   enum halmac_ret_status status = HALMAC_RET_SUCCESS;
+   struct halmac_h2c_header_info hdr_info;
+   struct halmac_pwr_tracking_para *param;
+   enum halmac_cmd_process_status *proc_status;
+
+   proc_status = >halmac_state.pwr_trk_state.proc_status;
+
+   if (halmac_fw_validate(adapter) != HALMAC_RET_SUCCESS)
+   return HALMAC_RET_NO_DLFW;
+
+   

[PATCH v2 17/17] rtlwifi: add halmac to Makefile and Kconfig

[pkshih]

From: Ping-Ke Shih 

Add halmac to Makefile and Kconfig, so we can build this module if 8822BE
is selected.

Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/Kconfig   |  5 
 drivers/net/wireless/realtek/rtlwifi/Makefile  |  1 +
 .../net/wireless/realtek/rtlwifi/halmac/Makefile   | 29 ++
 3 files changed, 35 insertions(+)
 create mode 100644 drivers/net/wireless/realtek/rtlwifi/halmac/Makefile

diff --git a/drivers/net/wireless/realtek/rtlwifi/Kconfig 
b/drivers/net/wireless/realtek/rtlwifi/Kconfig
index 73067cac289c..d9aba8fed151 100644
--- a/drivers/net/wireless/realtek/rtlwifi/Kconfig
+++ b/drivers/net/wireless/realtek/rtlwifi/Kconfig
@@ -151,4 +151,9 @@ config RTLBTCOEXIST
depends on RTL8723AE || RTL8723BE || RTL8821AE || RTL8192EE
default y
 
+config RTLHALMAC
+   tristate
+   depends on RTL8822BE
+   default y
+
 endif
diff --git a/drivers/net/wireless/realtek/rtlwifi/Makefile 
b/drivers/net/wireless/realtek/rtlwifi/Makefile
index 09c30e428375..a30a73c351d8 100644
--- a/drivers/net/wireless/realtek/rtlwifi/Makefile
+++ b/drivers/net/wireless/realtek/rtlwifi/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_RTL8723AE)   += rtl8723ae/
 obj-$(CONFIG_RTL8723BE)+= rtl8723be/
 obj-$(CONFIG_RTL8188EE)+= rtl8188ee/
 obj-$(CONFIG_RTLBTCOEXIST) += btcoexist/
+obj-$(CONFIG_RTLHALMAC)+= halmac/
 obj-$(CONFIG_RTL8723_COMMON)   += rtl8723com/
 obj-$(CONFIG_RTL8821AE)+= rtl8821ae/
 obj-$(CONFIG_RTL8192EE)+= rtl8192ee/
diff --git a/drivers/net/wireless/realtek/rtlwifi/halmac/Makefile 
b/drivers/net/wireless/realtek/rtlwifi/halmac/Makefile
new file mode 100644
index ..41c1ae7e5e53
--- /dev/null
+++ b/drivers/net/wireless/realtek/rtlwifi/halmac/Makefile
@@ -0,0 +1,29 @@
+
+
+halmac-objs := \
+   halmac_api.o\
+   halmac_88xx/halmac_bb_rf_88xx.o \
+   halmac_88xx/halmac_efuse_88xx.o \
+   halmac_88xx/halmac_gpio_88xx.o  \
+   halmac_88xx/halmac_pcie_88xx.o  \
+   halmac_88xx/halmac_sdio_88xx.o  \
+   halmac_88xx/halmac_usb_88xx.o   \
+   halmac_88xx/halmac_cfg_wmac_88xx.o  \
+   halmac_88xx/halmac_flash_88xx.o \
+   halmac_88xx/halmac_init_88xx.o  \
+   halmac_88xx/halmac_common_88xx.o\
+   halmac_88xx/halmac_fw_88xx.o\
+   halmac_88xx/halmac_mimo_88xx.o  \
+   halmac_88xx/halmac_8822b/halmac_gpio_8822b.o\
+   halmac_88xx/halmac_8822b/halmac_pcie_8822b.o\
+   halmac_88xx/halmac_8822b/halmac_sdio_8822b.o\
+   halmac_88xx/halmac_8822b/halmac_usb_8822b.o \
+   halmac_88xx/halmac_8822b/halmac_pwr_seq_8822b.o \
+   halmac_88xx/halmac_8822b/halmac_common_8822b.o  \
+   halmac_88xx/halmac_8822b/halmac_cfg_wmac_8822b.o\
+   halmac_88xx/halmac_8822b/halmac_phy_8822b.o \
+   halmac_88xx/halmac_8822b/halmac_init_8822b.o\
+   rtl_halmac.o
+
+
+obj-m = halmac.o
-- 
2.15.1

[PATCH v2 14/17] rtlwifi: halmac: add bus interface commands

[pkshih]

From: Ping-Ke Shih 

The halmac supports three buses interfaces, PCI, USB and SDIO, and this
commit makes it possible to change their phy parameters.

Signed-off-by: Ping-Ke Shih 
---
 .../halmac_88xx/halmac_8822b/halmac_pcie_8822b.c   | 218 +
 .../halmac_88xx/halmac_8822b/halmac_pcie_8822b.h   |  38 +
 .../halmac_88xx/halmac_8822b/halmac_phy_8822b.c| 148 
 .../halmac_88xx/halmac_8822b/halmac_sdio_8822b.c   | 880 
 .../halmac_88xx/halmac_8822b/halmac_sdio_8822b.h   |  62 ++
 .../halmac_88xx/halmac_8822b/halmac_usb_8822b.c| 161 
 .../halmac_88xx/halmac_8822b/halmac_usb_8822b.h|  38 +
 .../rtlwifi/halmac/halmac_88xx/halmac_pcie_88xx.c  | 538 +
 .../rtlwifi/halmac/halmac_88xx/halmac_pcie_88xx.h  |  98 +++
 .../rtlwifi/halmac/halmac_88xx/halmac_sdio_88xx.c  | 895 +
 .../rtlwifi/halmac/halmac_88xx/halmac_sdio_88xx.h  |  75 ++
 .../rtlwifi/halmac/halmac_88xx/halmac_usb_88xx.c   | 522 
 .../rtlwifi/halmac/halmac_88xx/halmac_usb_88xx.h   |  83 ++
 .../realtek/rtlwifi/halmac/halmac_intf_phy_cmd.h   |  45 ++
 .../realtek/rtlwifi/halmac/halmac_pcie_reg.h   |  36 +
 .../realtek/rtlwifi/halmac/halmac_sdio_reg.h   |  53 ++
 .../realtek/rtlwifi/halmac/halmac_usb_reg.h|  19 +
 17 files changed, 3909 insertions(+)
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_pcie_8822b.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_pcie_8822b.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_phy_8822b.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_sdio_8822b.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_sdio_8822b.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_usb_8822b.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_usb_8822b.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_pcie_88xx.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_pcie_88xx.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_sdio_88xx.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_sdio_88xx.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_usb_88xx.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_usb_88xx.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_intf_phy_cmd.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_pcie_reg.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/halmac/halmac_sdio_reg.h
 create mode 100644 drivers/net/wireless/realtek/rtlwifi/halmac/halmac_usb_reg.h

diff --git 
a/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_pcie_8822b.c
 
b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_pcie_8822b.c
new file mode 100644
index ..88a148e528a5
--- /dev/null
+++ 
b/drivers/net/wireless/realtek/rtlwifi/halmac/halmac_88xx/halmac_8822b/halmac_pcie_8822b.c
@@ -0,0 +1,218 @@
+/**
+ *
+ * Copyright(c) 2016 - 2018 Realtek Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ 
**/
+
+#include "halmac_pcie_8822b.h"
+#include "halmac_pwr_seq_8822b.h"
+#include "../halmac_init_88xx.h"
+#include "../halmac_common_88xx.h"
+#include "../halmac_pcie_88xx.h"
+#include "../halmac_88xx_cfg.h"
+
+/**
+ * mac_pwr_switch_pcie_8822b() - switch mac power
+ * @adapter : the adapter of halmac
+ * @pwr : power state
+ * Author : KaiYuan Chang
+ * Return : enum halmac_ret_status
+ * More details of status code can be found in prototype document
+ */
+enum halmac_ret_status
+mac_pwr_switch_pcie_8822b(struct halmac_adapter *adapter,
+ enum halmac_mac_power pwr)
+{
+   u8 value8;
+   u8 rpwm;
+   struct halmac_api *api = (struct halmac_api *)adapter->halmac_api;
+   enum halmac_ret_status status;
+
+   RT_TRACE(adapter->drv_adapter, COMP_HALMAC, DBG_DMESG, "%s ===>\n",
+__func__);
+   

Re: brcmfmac signal/interference issues

[Arend van Spriel]

On 3/28/2018 8:43 PM, Daniel Drake wrote:

On Thu, Mar 8, 2018 at 4:47 AM, Arend van Spriel
 wrote:

43455c0-roml/sdio-ag-ndis-vista-pktfilter-d0c-pno-aoe-p2p-dhdoid-ndoe-gtkoe-mfp-proptxstatus-dmatxrc-keepalive-ap-ampduretry-pclose-txbf

Yes, ndis. So no easy way to run the same firmware on the 2 OSes.


Indeed. I could try building nearly same firmware target. Can you provide
the firmware version as well.


Full string is:
43455c0-roml/sdio-ag-ndis-vista-pktfilter-d0c-pno-aoe-p2p-dhdoid-ndoe-gtkoe-mfp-proptxstatus-dmatxrc-keepalive-ap-ampduretry-pclose-txbf
Version: 7.45.87.0 CRC: 7cb2470e Date: Thu 2016-04-21 22:31:44 PDT
Ucode Ver: 1043.2070 FWID: 01-f68ec182

If you could build that config but for Linux instead of ndis I would
love to try it.

Also, here is the string for the current one in linux-firmware:
43455c0-roml/sdio-ag-p2p-pno-aoe-pktfilter-keepalive-mchan-pktctx-proptxstatus-ampduhostreorder-lpc-pwropt-txbf-wnm-okc-ccx-ltecx-wfds-wl11u-mfp-tdls-ve
Version: 7.45.18.0 CRC: d7226371 Date: Sun 2015-03-01 07:31:57 PST
Ucode Ver: 1026.2 FWID: 01-6a2c8ad4

I note that the Version and UcodeVer in the linux-firmware version are
lower than the windows one. If it's possible to also rebuild the
linux-firmware config but with those newer versions (or even the
latest, if there is something newer), I will test that too.


Thanks for the version info. I will look if we could use similar version 
as window version, but typically they spin from different branches.



So it picks up something in the PC. Some sources of interference that I have
seen before are USB3 and HDMI. Maybe try to shield those if present and see
if that helps. The nvram contains sensitivity parameters, but as you stated
you are using the same nvram for windows and linux for now we can rule it
out for debugging the issue.


Yeah, there are some options here which we can try to explore. What's
still unknown though is why windows appears immune to this exact same
interference. A software fix would be much more convenient... :)


Obviously ;-) And the immunity seems to justify that path.

Regards,
Arend