[PATCH v2] ath10k: Convert wow pattern from 802.3 to 802.11

[Wen Gong]

When trying to set wow wakeup patterns it fails with this command:

iw phyxx wowlan enable patterns offset xx+ IP address xx.xx.xx.xx

The reason is that the wow pattern from upper layer is in 802.3 format
for this case, it need to convert it to 802.11 format. The input
offset parameter is used for 802.3, but the actual offset firmware
need depends on rx_decap_mode, so that it needs to be recalculated.
Pattern of 802.3 packet is not same with 802.11 packet. If the
rx_decap_mode is ATH10K_HW_TXRX_NATIVE_WIFI, then firmware will
receive data packet with 802.11 format from hardware.

Tested with QCA6174 hw3.0 with firmware
WLAN.RM.4.4.1-00099-QCARMSWPZ-1, but this will also affect QCA9377.
This has always failed, so it's not a regression with new firmware
releases.

Signed-off-by: Wen Gong 
---

V2: 
-Move the convert graph from commit message to code.

 drivers/net/wireless/ath/ath10k/wmi.h |   4 +
 drivers/net/wireless/ath/ath10k/wow.c | 139 --
 2 files changed, 137 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index c7b30ed..389f9c7 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -6724,6 +6724,10 @@ struct wmi_wow_ev_arg {
 #define WOW_MIN_PATTERN_SIZE   1
 #define WOW_MAX_PATTERN_SIZE   148
 #define WOW_MAX_PKT_OFFSET 128
+#define WOW_HDR_LEN(sizeof(struct ieee80211_hdr_3addr) + \
+   sizeof(struct rfc1042_hdr))
+#define WOW_MAX_REDUCE (WOW_HDR_LEN - sizeof(struct ethhdr) - \
+   offsetof(struct ieee80211_hdr_3addr, addr1))
 
 enum wmi_tdls_state {
WMI_TDLS_DISABLE,
diff --git a/drivers/net/wireless/ath/ath10k/wow.c 
b/drivers/net/wireless/ath/ath10k/wow.c
index c4cbccb..60eeaae 100644
--- a/drivers/net/wireless/ath/ath10k/wow.c
+++ b/drivers/net/wireless/ath/ath10k/wow.c
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2015-2017 Qualcomm Atheros, Inc.
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -76,6 +77,109 @@ static int ath10k_wow_cleanup(struct ath10k *ar)
return 0;
 }
 
+/**
+ * Convert a 802.3 format to a 802.11 format.
+ * ++---+++
+ * 802.3:  |dest mac(6B)|src mac(6B)|type(2B)| body...|
+ * ++---+++
+ *|__ |___|  |
+ *   |||  |
+ * +--+++---+---+---+
+ * 802.11: |4B|dest mac(6B)| 6B |src mac(6B)|  8B  |type(2B)|  body...  |
+ * +--+++---+---+---+
+ */
+static void ath10k_wow_convert_8023_to_80211
+   (struct cfg80211_pkt_pattern *new,
+   const struct cfg80211_pkt_pattern *old)
+{
+   u8 hdr_8023_pattern[ETH_HLEN] = {};
+   u8 hdr_8023_bit_mask[ETH_HLEN] = {};
+   u8 hdr_80211_pattern[WOW_HDR_LEN] = {};
+   u8 hdr_80211_bit_mask[WOW_HDR_LEN] = {};
+
+   int total_len = old->pkt_offset + old->pattern_len;
+   int hdr_80211_end_offset;
+
+   struct ieee80211_hdr_3addr *new_hdr_pattern =
+   (struct ieee80211_hdr_3addr *)hdr_80211_pattern;
+   struct ieee80211_hdr_3addr *new_hdr_mask =
+   (struct ieee80211_hdr_3addr *)hdr_80211_bit_mask;
+   struct ethhdr *old_hdr_pattern = (struct ethhdr *)hdr_8023_pattern;
+   struct ethhdr *old_hdr_mask = (struct ethhdr *)hdr_8023_bit_mask;
+   int hdr_len = sizeof(*new_hdr_pattern);
+
+   struct rfc1042_hdr *new_rfc_pattern =
+   (struct rfc1042_hdr *)(hdr_80211_pattern + hdr_len);
+   struct rfc1042_hdr *new_rfc_mask =
+   (struct rfc1042_hdr *)(hdr_80211_bit_mask + hdr_len);
+   int rfc_len = sizeof(*new_rfc_pattern);
+
+   memcpy(hdr_8023_pattern + old->pkt_offset,
+  old->pattern, ETH_HLEN - old->pkt_offset);
+   memcpy(hdr_8023_bit_mask + old->pkt_offset,
+  old->mask, ETH_HLEN - old->pkt_offset);
+
+   /* Copy destination address */
+   memcpy(new_hdr_pattern->addr1, old_hdr_pattern->h_dest, ETH_ALEN);
+   memcpy(new_hdr_mask->addr1, old_hdr_mask->h_dest, ETH_ALEN);
+
+   /* Copy source address */
+   memcpy(new_hdr_pattern->addr3, old_hdr_pattern->h_source, ETH_ALEN);
+   memcpy(new_hdr_mask->addr3, old_hdr_mask->h_source, ETH_ALEN);
+
+   /* Copy logic link type */
+   memcpy(_rfc_pattern->snap_type,
+  _hdr_pattern->h_proto,
+  sizeof(old_hdr_pattern->h_proto));
+   memcpy(_rfc_mask->snap_type,
+  _hdr_mask->h_proto,
+  sizeof(old_hdr_mask->h_proto));
+
+   /* 

Re: [PATCH] ANDROID: mac80211_hwsim: support/ignore power state changes

[Kalle Valo]

r...@google.com writes:

> From: Bjoern Johansson 
>
> Indicate support for power state changes and handle them by calling an
> empty function.
> The important part is "ieee80211_hw_set(hw, SUPPORTS_PS);" at the
> bottom of the diff. Without this upper layers in the kernel will return an
> error code when trying to set the power state because the driver doesn't
> indicate power state support. This in turn causes VTS
> (Android Vendor Test Suite) failures because the WiFi HAL can't enable
> power saving mode. The remaining code is just there to deal with the
> incoming state change request.
>
> Signed-off-by: Bjoern Johansson 
> Signed-off-by: Lingfeng Yang 
> Signed-off-by: Roman Kiryanov 

Why the odd "ANDROID:" prefix?

-- 
Kalle Valo

Re: [PATCH] ath10k: Convert wow pattern from 802.3 to 802.11

[Wen Gong]

Hi,

I will move the convert graph from comments to code and send Patch V2.
And new graph like this:
/**
+ * Convert a 802.3 format to a 802.11 format.
+ * ++---+++
+ * 802.3:  |dest mac(6B)|src mac(6B)|type(2B)| body...    |
+ * ++---+++
+ *    |__ |___    |  |
+ *   |    |    |  |
+ * 
+--+++---+---+---+
+ * 802.11: |4B|dest mac(6B)| 6B |src mac(6B)|  8B  |type(2B)|  body... 
 |
+ * 
+--+++---+---+---+

+ */
+static void ath10k_wow_convert_8023_to_80211
+    (struct cfg80211_pkt_pattern *new,
+    const struct cfg80211_pkt_pattern *old)


And the 444 bytes on stack will remain since the comments is: "we can go 
with this until somebody runs into a real problem"


On 2018-04-12 07:13, Brian Norris wrote:

Hi,

On Fri, Mar 30, 2018 at 11:18:19AM +0800, Wen Gong wrote:

When trying to set wow wakeup patterns it fails with this command:

iw phyxx wowlan enable patterns offset xx+ IP address xx.xx.xx.xx

The reason is that the wow pattern from upper layer is in 802.3 format
for this case, it need to convert it to 802.11 format. The input
offset parameter is used for 802.3, but the actual offset firmware
need depends on rx_decap_mode, so that it needs to be recalculated.
Pattern of 802.3 packet is not same with 802.11 packet. If the
rx_decap_mode is ATH10K_HW_TXRX_NATIVE_WIFI, then firmware will
receive data packet with 802.11 format from hardware.

Convert graph:
---
802.3  |dest mac(6B)|src mac(6B)|type(2B)| body...|
 |__ |___|_  |___
|| | |
802.11 |4B|dest mac(6B)| 6B |src mac(6B)|  8B  |type(2B)|  body...  |
---


It feels like this could go into the code comments? Or at least some
short version of it. (But hey, text is cheap, and who doesn't love 
ASCII

art?)



Tested with QCA6174 hw3.0 with firmware
WLAN.RM.4.4.1-00099-QCARMSWPZ-1, but this will also affect QCA9377.
This has always failed, so it's not a regression with new firmware
releases.

Signed-off-by: Wen Gong 
---
 drivers/net/wireless/ath/ath10k/wmi.h |   4 ++
 drivers/net/wireless/ath/ath10k/wow.c | 128 
--

 2 files changed, 126 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h

index c7b30ed..389f9c7 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -6724,6 +6724,10 @@ struct wmi_wow_ev_arg {
 #define WOW_MIN_PATTERN_SIZE   1
 #define WOW_MAX_PATTERN_SIZE   148
 #define WOW_MAX_PKT_OFFSET 128
+#define WOW_HDR_LEN(sizeof(struct ieee80211_hdr_3addr) + \
+   sizeof(struct rfc1042_hdr))
+#define WOW_MAX_REDUCE (WOW_HDR_LEN - sizeof(struct ethhdr) - \
+   offsetof(struct ieee80211_hdr_3addr, addr1))

 enum wmi_tdls_state {
WMI_TDLS_DISABLE,
diff --git a/drivers/net/wireless/ath/ath10k/wow.c 
b/drivers/net/wireless/ath/ath10k/wow.c

index c4cbccb..9b56a41 100644
--- a/drivers/net/wireless/ath/ath10k/wow.c
+++ b/drivers/net/wireless/ath/ath10k/wow.c
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2015-2017 Qualcomm Atheros, Inc.
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
  *
  * Permission to use, copy, modify, and/or distribute this software 
for any
  * purpose with or without fee is hereby granted, provided that the 
above

@@ -76,6 +77,98 @@ static int ath10k_wow_cleanup(struct ath10k *ar)
return 0;
 }

+static void ath10k_wow_convert_8023_to_80211
+   (struct cfg80211_pkt_pattern *new,
+   const struct cfg80211_pkt_pattern *old)
+{
+   u8 hdr_8023_pattern[ETH_HLEN] = {};
+   u8 hdr_8023_bit_mask[ETH_HLEN] = {};
+   u8 hdr_80211_pattern[WOW_HDR_LEN] = {};
+   u8 hdr_80211_bit_mask[WOW_HDR_LEN] = {};
+
+   int total_len = old->pkt_offset + old->pattern_len;
+   int hdr_80211_end_offset;
+
+   struct ieee80211_hdr_3addr *new_hdr_pattern =
+   (struct ieee80211_hdr_3addr *)hdr_80211_pattern;
+   struct ieee80211_hdr_3addr *new_hdr_mask =
+   (struct ieee80211_hdr_3addr *)hdr_80211_bit_mask;
+   struct ethhdr *old_hdr_pattern = (struct ethhdr *)hdr_8023_pattern;
+   struct ethhdr *old_hdr_mask = (struct ethhdr *)hdr_8023_bit_mask;
+   int hdr_len = sizeof(*new_hdr_pattern);
+
+   struct rfc1042_hdr *new_rfc_pattern =
+   (struct rfc1042_hdr *)(hdr_80211_pattern + hdr_len);
+   struct rfc1042_hdr 

[PATCH] ath10k:add support for multicast rate control

[Pradeep Kumar Chitrapu]

Issues wmi command to firmware when multicast rate change is received
with the new BSS_CHANGED_MCAST_RATE flag.

Signed-off-by: Pradeep Kumar Chitrapu 
---
 drivers/net/wireless/ath/ath10k/mac.c | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index bf05a36..63af46f 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5419,8 +5419,12 @@ static void ath10k_bss_info_changed(struct ieee80211_hw 
*hw,
 {
struct ath10k *ar = hw->priv;
struct ath10k_vif *arvif = (void *)vif->drv_priv;
-   int ret = 0;
+   struct ieee80211_supported_band *sband;
+   struct cfg80211_chan_def def;
u32 vdev_param, pdev_param, slottime, preamble;
+   int rate_index, ret = 0;
+   u8 rate;
+   enum nl80211_band band;
 
mutex_lock(>conf_mutex);
 
@@ -5588,6 +5592,25 @@ static void ath10k_bss_info_changed(struct ieee80211_hw 
*hw,
arvif->vdev_id, ret);
}
 
+   if (changed & BSS_CHANGED_MCAST_RATE &&
+   !WARN_ON(ath10k_mac_vif_chan(arvif->vif, ))) {
+   band = def.chan->band;
+   sband = >mac.sbands[band];
+   vdev_param = ar->wmi.vdev_param->mcast_data_rate;
+   rate_index = vif->bss_conf.mcast_rate[band] - 1;
+   rate = ATH10K_HW_MCS_RATE(sband->bitrates[rate_index].hw_value);
+   ath10k_dbg(ar, ATH10K_DBG_MAC,
+  "mac vdev %d mcast_rate %d\n",
+  arvif->vdev_id, rate);
+
+   ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id,
+   vdev_param, rate);
+   if (ret)
+   ath10k_warn(ar,
+   "failed to set mcast rate on vdev"
+   " %i: %d\n", arvif->vdev_id,  ret);
+   }
+
mutex_unlock(>conf_mutex);
 }
 
-- 
1.9.1

RE: [PATCH] ath10k: Convert wow pattern from 802.3 to 802.11

[Wen Gong]

Hi,

I will move the convert graph from comments to code.
And new graph like this:
/**
+ * Convert a 802.3 format to a 802.11 format.
+ * ++---+++
+ * 802.3:  |dest mac(6B)|src mac(6B)|type(2B)| body...|
+ * ++---+++
+ *|__ |___|  |
+ *   |||  |
+ * +--+++---+---+---+
+ * 802.11: |4B|dest mac(6B)| 6B |src mac(6B)|  8B  |type(2B)|  body...  |
+ * +--+++---+---+---+
+ */
+static void ath10k_wow_convert_8023_to_80211
+   (struct cfg80211_pkt_pattern *new,
+   const struct cfg80211_pkt_pattern *old)


And the 444 bytes on stack will remain since the comments is: "we can go with 
this until somebody runs into a real problem"

Thanks
Gong Wen

> -Original Message-
> From: ath10k [mailto:ath10k-boun...@lists.infradead.org] On Behalf Of
> Brian Norris
> Sent: Thursday, April 12, 2018 7:13 AM
> To: Wen Gong 
> Cc: linux-wireless@vger.kernel.org; ath...@lists.infradead.org
> Subject: Re: [PATCH] ath10k: Convert wow pattern from 802.3 to 802.11
> 
> Hi,
> 
> On Fri, Mar 30, 2018 at 11:18:19AM +0800, Wen Gong wrote:
> > When trying to set wow wakeup patterns it fails with this command:
> >
> > iw phyxx wowlan enable patterns offset xx+ IP address xx.xx.xx.xx
> >
> > The reason is that the wow pattern from upper layer is in 802.3 format
> > for this case, it need to convert it to 802.11 format. The input
> > offset parameter is used for 802.3, but the actual offset firmware
> > need depends on rx_decap_mode, so that it needs to be recalculated.
> > Pattern of 802.3 packet is not same with 802.11 packet. If the
> > rx_decap_mode is ATH10K_HW_TXRX_NATIVE_WIFI, then firmware will
> > receive data packet with 802.11 format from hardware.
> >
> > Convert graph:
> > ---
> > 802.3  |dest mac(6B)|src mac(6B)|type(2B)| body...|
> >  |__ |___|_  |___
> > || | |
> > 802.11 |4B|dest mac(6B)| 6B |src mac(6B)|  8B  |type(2B)|  body...  |
> > --
> > -
> 
> It feels like this could go into the code comments? Or at least some short
> version of it. (But hey, text is cheap, and who doesn't love ASCII
> art?)
> 
> >
> > Tested with QCA6174 hw3.0 with firmware
> > WLAN.RM.4.4.1-00099-QCARMSWPZ-1, but this will also affect QCA9377.
> > This has always failed, so it's not a regression with new firmware
> > releases.
> >
> > Signed-off-by: Wen Gong 
> > ---
> >  drivers/net/wireless/ath/ath10k/wmi.h |   4 ++
> >  drivers/net/wireless/ath/ath10k/wow.c | 128
> > --
> >  2 files changed, 126 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ath/ath10k/wmi.h
> > b/drivers/net/wireless/ath/ath10k/wmi.h
> > index c7b30ed..389f9c7 100644
> > --- a/drivers/net/wireless/ath/ath10k/wmi.h
> > +++ b/drivers/net/wireless/ath/ath10k/wmi.h
> > @@ -6724,6 +6724,10 @@ struct wmi_wow_ev_arg {
> >  #define WOW_MIN_PATTERN_SIZE   1
> >  #define WOW_MAX_PATTERN_SIZE   148
> >  #define WOW_MAX_PKT_OFFSET 128
> > +#define WOW_HDR_LEN(sizeof(struct ieee80211_hdr_3addr) + \
> > +   sizeof(struct rfc1042_hdr))
> > +#define WOW_MAX_REDUCE (WOW_HDR_LEN - sizeof(struct
> ethhdr) - \
> > +   offsetof(struct ieee80211_hdr_3addr, addr1))
> >
> >  enum wmi_tdls_state {
> > WMI_TDLS_DISABLE,
> > diff --git a/drivers/net/wireless/ath/ath10k/wow.c
> > b/drivers/net/wireless/ath/ath10k/wow.c
> > index c4cbccb..9b56a41 100644
> > --- a/drivers/net/wireless/ath/ath10k/wow.c
> > +++ b/drivers/net/wireless/ath/ath10k/wow.c
> > @@ -1,5 +1,6 @@
> >  /*
> >   * Copyright (c) 2015-2017 Qualcomm Atheros, Inc.
> > + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> >   *
> >   * Permission to use, copy, modify, and/or distribute this software for any
> >   * purpose with or without fee is hereby granted, provided that the
> > above @@ -76,6 +77,98 @@ static int ath10k_wow_cleanup(struct ath10k
> *ar)
> > return 0;
> >  }
> >
> > +static void ath10k_wow_convert_8023_to_80211
> > +   (struct cfg80211_pkt_pattern *new,
> > +   const struct cfg80211_pkt_pattern
> *old) {
> > +   u8 hdr_8023_pattern[ETH_HLEN] = {};
> > +   u8 hdr_8023_bit_mask[ETH_HLEN] = {};
> > +   u8 hdr_80211_pattern[WOW_HDR_LEN] = {};
> > +   u8 hdr_80211_bit_mask[WOW_HDR_LEN] = {};
> > +
> > +   int total_len = old->pkt_offset + old->pattern_len;
> > +   int 

Re: [PATCH] wcn36xx: use READ_ONCE() to access desc->ctrl

[Ramon Fried]

On 11 April 2018 at 09:58, Daniel Mack  wrote:
> On Tuesday, April 10, 2018 08:17 PM, Ramon Fried wrote:
>> On 10 April 2018 at 20:35, Daniel Mack  wrote:
>>> When accessing shared memory to check for the stat of submitted
>>> descriptors, make sure to use READ_ONCE(). This will guarantee the
>>> compiler treats these memory locations as volatile and doesn't apply
>>> any caching.
>>
>> The structure that is tested is not shared memory. It's accessed only
>> by the apps processor.
>
> Hmm? ctl->desc is of type struct wcn36xx_dxe_desc, which is packed and
> shared with the firmware. The WCN36xx_DXE_CTRL_VLD bit in ctrl bitfield
> is set by the firmware when a frame is valid, and before asserting the
> RX interrupt. So the host CPU must treat it as volatile and expect it to
> change.
>
> Am I reading this wrong?
>
No, you're right. I missed that.
>
> Thanks,
> Daniel

Re: [PATCH] ath10k: Convert wow pattern from 802.3 to 802.11

[Brian Norris]

Hi,

On Fri, Mar 30, 2018 at 11:18:19AM +0800, Wen Gong wrote:
> When trying to set wow wakeup patterns it fails with this command:
> 
> iw phyxx wowlan enable patterns offset xx+ IP address xx.xx.xx.xx
> 
> The reason is that the wow pattern from upper layer is in 802.3 format
> for this case, it need to convert it to 802.11 format. The input
> offset parameter is used for 802.3, but the actual offset firmware
> need depends on rx_decap_mode, so that it needs to be recalculated.
> Pattern of 802.3 packet is not same with 802.11 packet. If the
> rx_decap_mode is ATH10K_HW_TXRX_NATIVE_WIFI, then firmware will
> receive data packet with 802.11 format from hardware.
> 
> Convert graph:
> ---
> 802.3  |dest mac(6B)|src mac(6B)|type(2B)| body...|
>  |__ |___|_  |___
> || | |
> 802.11 |4B|dest mac(6B)| 6B |src mac(6B)|  8B  |type(2B)|  body...  |
> ---

It feels like this could go into the code comments? Or at least some
short version of it. (But hey, text is cheap, and who doesn't love ASCII
art?)

> 
> Tested with QCA6174 hw3.0 with firmware
> WLAN.RM.4.4.1-00099-QCARMSWPZ-1, but this will also affect QCA9377.
> This has always failed, so it's not a regression with new firmware
> releases.
> 
> Signed-off-by: Wen Gong 
> ---
>  drivers/net/wireless/ath/ath10k/wmi.h |   4 ++
>  drivers/net/wireless/ath/ath10k/wow.c | 128 
> --
>  2 files changed, 126 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
> b/drivers/net/wireless/ath/ath10k/wmi.h
> index c7b30ed..389f9c7 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.h
> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
> @@ -6724,6 +6724,10 @@ struct wmi_wow_ev_arg {
>  #define WOW_MIN_PATTERN_SIZE 1
>  #define WOW_MAX_PATTERN_SIZE 148
>  #define WOW_MAX_PKT_OFFSET   128
> +#define WOW_HDR_LEN  (sizeof(struct ieee80211_hdr_3addr) + \
> + sizeof(struct rfc1042_hdr))
> +#define WOW_MAX_REDUCE   (WOW_HDR_LEN - sizeof(struct ethhdr) - \
> + offsetof(struct ieee80211_hdr_3addr, addr1))
>  
>  enum wmi_tdls_state {
>   WMI_TDLS_DISABLE,
> diff --git a/drivers/net/wireless/ath/ath10k/wow.c 
> b/drivers/net/wireless/ath/ath10k/wow.c
> index c4cbccb..9b56a41 100644
> --- a/drivers/net/wireless/ath/ath10k/wow.c
> +++ b/drivers/net/wireless/ath/ath10k/wow.c
> @@ -1,5 +1,6 @@
>  /*
>   * Copyright (c) 2015-2017 Qualcomm Atheros, Inc.
> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
>   *
>   * Permission to use, copy, modify, and/or distribute this software for any
>   * purpose with or without fee is hereby granted, provided that the above
> @@ -76,6 +77,98 @@ static int ath10k_wow_cleanup(struct ath10k *ar)
>   return 0;
>  }
>  
> +static void ath10k_wow_convert_8023_to_80211
> + (struct cfg80211_pkt_pattern *new,
> + const struct cfg80211_pkt_pattern *old)
> +{
> + u8 hdr_8023_pattern[ETH_HLEN] = {};
> + u8 hdr_8023_bit_mask[ETH_HLEN] = {};
> + u8 hdr_80211_pattern[WOW_HDR_LEN] = {};
> + u8 hdr_80211_bit_mask[WOW_HDR_LEN] = {};
> +
> + int total_len = old->pkt_offset + old->pattern_len;
> + int hdr_80211_end_offset;
> +
> + struct ieee80211_hdr_3addr *new_hdr_pattern =
> + (struct ieee80211_hdr_3addr *)hdr_80211_pattern;
> + struct ieee80211_hdr_3addr *new_hdr_mask =
> + (struct ieee80211_hdr_3addr *)hdr_80211_bit_mask;
> + struct ethhdr *old_hdr_pattern = (struct ethhdr *)hdr_8023_pattern;
> + struct ethhdr *old_hdr_mask = (struct ethhdr *)hdr_8023_bit_mask;
> + int hdr_len = sizeof(*new_hdr_pattern);
> +
> + struct rfc1042_hdr *new_rfc_pattern =
> + (struct rfc1042_hdr *)(hdr_80211_pattern + hdr_len);
> + struct rfc1042_hdr *new_rfc_mask =
> + (struct rfc1042_hdr *)(hdr_80211_bit_mask + hdr_len);
> + int rfc_len = sizeof(*new_rfc_pattern);
> +
> + memcpy(hdr_8023_pattern + old->pkt_offset,
> +old->pattern, ETH_HLEN - old->pkt_offset);
> + memcpy(hdr_8023_bit_mask + old->pkt_offset,
> +old->mask, ETH_HLEN - old->pkt_offset);
> +
> + /* Copy destination address */
> + memcpy(new_hdr_pattern->addr1, old_hdr_pattern->h_dest, ETH_ALEN);
> + memcpy(new_hdr_mask->addr1, old_hdr_mask->h_dest, ETH_ALEN);
> +
> + /* Copy source address */
> + memcpy(new_hdr_pattern->addr3, old_hdr_pattern->h_source, ETH_ALEN);
> + memcpy(new_hdr_mask->addr3, old_hdr_mask->h_source, ETH_ALEN);
> +
> + /* Copy logic link type */
> + memcpy(_rfc_pattern->snap_type,
> +_hdr_pattern->h_proto,
> +sizeof(old_hdr_pattern->h_proto));
> + memcpy(_rfc_mask->snap_type,
> + 

[PATCH] ANDROID: mac80211_hwsim: support/ignore power state changes

[rkir]

From: Bjoern Johansson 

Indicate support for power state changes and handle them by calling an
empty function.
The important part is "ieee80211_hw_set(hw, SUPPORTS_PS);" at the
bottom of the diff. Without this upper layers in the kernel will return an
error code when trying to set the power state because the driver doesn't
indicate power state support. This in turn causes VTS
(Android Vendor Test Suite) failures because the WiFi HAL can't enable
power saving mode. The remaining code is just there to deal with the
incoming state change request.

Signed-off-by: Bjoern Johansson 
Signed-off-by: Lingfeng Yang 
Signed-off-by: Roman Kiryanov 
---
 drivers/net/wireless/mac80211_hwsim.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/net/wireless/mac80211_hwsim.c 
b/drivers/net/wireless/mac80211_hwsim.c
index 6afe896e5cb8..ff4741188814 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -1637,6 +1637,11 @@ static const char * const hwsim_chanwidths[] = {
[NL80211_CHAN_WIDTH_160] = "vht160",
 };
 
+static void mac80211_power_state_changed(bool enabled)
+{
+   /* TODO: Do something when the power state changes */
+}
+
 static int mac80211_hwsim_config(struct ieee80211_hw *hw, u32 changed)
 {
struct mac80211_hwsim_data *data = hw->priv;
@@ -1649,6 +1654,12 @@ static int mac80211_hwsim_config(struct ieee80211_hw 
*hw, u32 changed)
};
int idx;
 
+   if (changed & IEEE80211_CONF_CHANGE_PS) {
+   bool enabled = (conf->flags & IEEE80211_CONF_PS) != 0;
+
+   mac80211_power_state_changed(enabled);
+   }
+
if (conf->chandef.chan)
wiphy_dbg(hw->wiphy,
  "%s (freq=%d(%d - %d)/%s idle=%d ps=%d smps=%s)\n",
@@ -2650,7 +2661,9 @@ static int mac80211_hwsim_new_radio(struct genl_info 
*info,
ieee80211_hw_set(hw, AMPDU_AGGREGATION);
ieee80211_hw_set(hw, MFP_CAPABLE);
ieee80211_hw_set(hw, SIGNAL_DBM);
+   ieee80211_hw_set(hw, SUPPORTS_PS);
ieee80211_hw_set(hw, TDLS_WIDER_BW);
+
if (rctbl)
ieee80211_hw_set(hw, SUPPORTS_RC_TABLE);
 
-- 
2.17.0.484.g0c8726318c-goog

Re: [PATCH v3 4/9] rtlwifi: btcoex: Add 8822b routine to btc interfaces

[kbuild test robot]

Hi Ping-Ke,

I love your patch! Yet something to improve:

[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on next-20180411]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/pkshih-realtek-com/rtlwifi-btcoex-Add-8822b-btcoex-support/20180410-194853
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
master
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=alpha 

Note: the 
linux-review/pkshih-realtek-com/rtlwifi-btcoex-Add-8822b-btcoex-support/20180410-194853
 HEAD d96bfa6717e0ea33a20a978ecb6c52fab18d15d3 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.o: In function 
`exhalbtc_power_on_setting':
>> (.text+0x27bc): undefined reference to `ex_btc8822b1ant_power_on_setting'
   (.text+0x27c0): undefined reference to `ex_btc8822b1ant_power_on_setting'
>> (.text+0x27d8): undefined reference to `ex_btc8822b2ant_power_on_setting'
   (.text+0x27dc): undefined reference to `ex_btc8822b2ant_power_on_setting'
   drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.o: In function 
`exhalbtc_pre_load_firmware':
>> (.text+0x288c): undefined reference to `ex_btc8822b1ant_pre_load_firmware'
   (.text+0x2890): undefined reference to `ex_btc8822b1ant_pre_load_firmware'
>> (.text+0x28a8): undefined reference to `ex_btc8822b2ant_pre_load_firmware'
   (.text+0x28ac): undefined reference to `ex_btc8822b2ant_pre_load_firmware'
   drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.o: In function 
`exhalbtc_init_hw_config':
>> (.text+0x2a0c): undefined reference to `ex_btc8822b1ant_init_hw_config'
   (.text+0x2a10): undefined reference to `ex_btc8822b1ant_init_hw_config'
>> (.text+0x2a38): undefined reference to `ex_btc8822b2ant_init_hw_config'
   (.text+0x2a3c): undefined reference to `ex_btc8822b2ant_init_hw_config'
   drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.o: In function 
`exhalbtc_init_hw_config_wifi_only':
>> (.text+0x2ae4): undefined reference to `ex_hal8822b_wifi_only_hw_config'
   (.text+0x2ae8): undefined reference to `ex_hal8822b_wifi_only_hw_config'
   drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.o: In function 
`exhalbtc_init_coex_dm':
>> (.text+0x2c2c): undefined reference to `ex_btc8822b1ant_init_coex_dm'
   (.text+0x2c30): undefined reference to `ex_btc8822b1ant_init_coex_dm'
>> (.text+0x2c48): undefined reference to `ex_btc8822b2ant_init_coex_dm'
   (.text+0x2c4c): undefined reference to `ex_btc8822b2ant_init_coex_dm'
   drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.o: In function 
`exhalbtc_ips_notify':
>> (.text+0x2dbc): undefined reference to `ex_btc8822b1ant_ips_notify'
   (.text+0x2dc0): undefined reference to `ex_btc8822b1ant_ips_notify'
>> (.text+0x2dd8): undefined reference to `ex_btc8822b2ant_ips_notify'
   (.text+0x2ddc): undefined reference to `ex_btc8822b2ant_ips_notify'
   drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.o: In function 
`exhalbtc_lps_notify':
>> (.text+0x2f3c): undefined reference to `ex_btc8822b1ant_lps_notify'
   (.text+0x2f40): undefined reference to `ex_btc8822b1ant_lps_notify'
>> (.text+0x2f58): undefined reference to `ex_btc8822b2ant_lps_notify'
   (.text+0x2f5c): undefined reference to `ex_btc8822b2ant_lps_notify'
   drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.o: In function 
`exhalbtc_scan_notify':
>> (.text+0x30bc): undefined reference to `ex_btc8822b1ant_scan_notify'
   (.text+0x30c0): undefined reference to `ex_btc8822b1ant_scan_notify'
>> (.text+0x30d8): undefined reference to `ex_btc8822b2ant_scan_notify'
   (.text+0x30dc): undefined reference to `ex_btc8822b2ant_scan_notify'
   drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.o: In function 
`exhalbtc_scan_notify_wifi_only':
>> (.text+0x3124): undefined reference to `ex_hal8822b_wifi_only_scannotify'
   (.text+0x3128): undefined reference to `ex_hal8822b_wifi_only_scannotify'
   drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.o: In function 
`exhalbtc_connect_notify':
>> (.text+0x332c): undefined reference to `ex_btc8822b1ant_connect_notify'
   (.text+0x3334): undefined reference to `ex_btc8822b1ant_connect_notify'
>> (.text+0x3358): undefined reference to `ex_btc8822b2ant_connect_notify'
   (.text+0x3360): undefined reference to `ex_btc8822b2ant_connect_notify'
   drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.o: In funct

Re: [PATCH 1/1 RFC] wcn36xx: fix buffer commit logic on TX path

[Daniel Mack]

Hi Loic,

On Wednesday, April 11, 2018 03:30 PM, Loic Poulain wrote:
>> /* Move the head of the ring to the next empty descriptor */
>> -ch->head_blk_ctl = ctl->next;
>> +ch->head_blk_ctl = ctl_skb->next;
>> +
>> +   /* Commit all previous writes and set descriptors to VALID */
>> +   wmb();
> 
> Is this first memory barrier really needed? from what I understand, we
> only need to ensure that the control descriptor is marked valid at the
> end of the procedure and we don't really care about the paylod one.

Well, without documentation or the firmware sources, that's just
guesswork at this point. My assumption is only based on the weird
comments and workarounds in the downstream driver.

I added the second barrier to ensure that no descriptor is ever marked
valid unless all other bits are definitely in sync.


Thanks,
Daniel

Re: [PATCH 1/1 RFC] wcn36xx: fix buffer commit logic on TX path

[Loic Poulain]

Hi Daniel,

> /* Move the head of the ring to the next empty descriptor */
> -ch->head_blk_ctl = ctl->next;
> +ch->head_blk_ctl = ctl_skb->next;
> +
> +   /* Commit all previous writes and set descriptors to VALID */
> +   wmb();

Is this first memory barrier really needed? from what I understand, we
only need to ensure that the control descriptor is marked valid at the
end of the procedure and we don't really care about the paylod one.

> +   desc_skb->ctrl = ch->ctrl_skb;
> +   wmb();
> +   desc_bd->ctrl = ch->ctrl_bd;
>
> /*
>  * When connected and trying to send data frame chip can be in sleep

Otherwise, patch makes sense.

Regards,
Loic

[PATCH][next] iwlwifi: mvm: remove division by size of sizeof(struct ieee80211_wmm_rule)

[Colin King]

From: Colin Ian King 

The subtraction of two struct ieee80211_wmm_rule pointers leaves a result
that is automatically scaled down by the size of the size of pointed-to
type, hence the division by sizeof(struct ieee80211_wmm_rule) is
bogus and should be removed.

Detected by CoverityScan, CID#146 ("Extra sizeof expression")

Fixes: 77e30e10ee28 ("iwlwifi: mvm: query regdb for wmm rule if needed")
Signed-off-by: Colin Ian King 
---
 drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c 
b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
index ca0174680af9..e78219057d2f 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
@@ -1007,8 +1007,7 @@ iwl_parse_nvm_mcc_info(struct device *dev, const struct 
iwl_cfg *cfg,
continue;
 
copy_rd->reg_rules[i].wmm_rule = d_wmm +
-   (regd->reg_rules[i].wmm_rule - s_wmm) /
-   sizeof(struct ieee80211_wmm_rule);
+   (regd->reg_rules[i].wmm_rule - s_wmm);
}
 
 out:
-- 
2.17.0

Re: [PATCH] wcn36xx: use READ_ONCE() to access desc->ctrl

[Daniel Mack]

On Tuesday, April 10, 2018 08:17 PM, Ramon Fried wrote:
> On 10 April 2018 at 20:35, Daniel Mack  wrote:
>> When accessing shared memory to check for the stat of submitted
>> descriptors, make sure to use READ_ONCE(). This will guarantee the
>> compiler treats these memory locations as volatile and doesn't apply
>> any caching.
>
> The structure that is tested is not shared memory. It's accessed only
> by the apps processor.

Hmm? ctl->desc is of type struct wcn36xx_dxe_desc, which is packed and
shared with the firmware. The WCN36xx_DXE_CTRL_VLD bit in ctrl bitfield
is set by the firmware when a frame is valid, and before asserting the
RX interrupt. So the host CPU must treat it as volatile and expect it to
change.

Am I reading this wrong?


Thanks,
Daniel

[PATCH 1/2] rsi: fix nommu_map_sg overflow kernel panic

[Amitkumar Karwar]

From: Siva Rebbagondla 

Following overflow kernel panic is observed on some platforms while
loading the driver. It is fixed if dynamically allocated memory is
passed to SDIO instead of static one

[  927.513963] nommu_map_sg: overflow 17d54064ba7c+20 of device mask 
[  927.517712] Modules linked in: rsi_sdio(+) cmac bnep arc4 rsi_91x mac80211 
cfg80211
   btrsi rfcomm bluetooth ecdh_generic snd_soc_sst_bytcr_rt5660
[  927.517861] CPU: 0 PID: 1624 Comm: insmod Tainted: G W 4.15.0-1000 #1
[  927.517870] RIP: 0010:sdhci_send_command+0x5f0/0xa90 [sdhci]
[  927.517873] RSP: :ac3fc064b6d8 EFLAGS: 00010086
[  927.517895] Call Trace:
[  927.517908]  ? __schedule+0x3cd/0x890
[  927.517915]  ? mod_timer+0x17b/0x3c0
[  927.517922]  sdhci_request+0x7c/0xf0 [sdhci]
[  927.517928]  __mmc_start_request+0x5a/0x170
[  927.517932]  mmc_start_request+0x74/0x90
[  927.517936]  mmc_wait_for_req+0x87/0xe0
[  927.517940]  mmc_io_rw_extended+0x2fd/0x330
[  927.517946]  ? mmc_wait_data_done+0x30/0x30
[  927.517951]  sdio_io_rw_ext_helper+0x160/0x210
[  927.517956]  sdio_writesb+0x1d/0x20
[  927.517966]  rsi_sdio_write_register_multiple+0x68/0x110 [rsi_sdio]
[  927.517976]  rsi_hal_device_init+0x357/0x910 [rsi_91x]
[  927.517983]  ? rsi_hal_device_init+0x357/0x910 [rsi_91x]
[  927.517990]  rsi_probe+0x2c6/0x450 [rsi_sdio]
[  927.517995]  sdio_bus_probe+0xfc/0x110
[  927.518000]  driver_probe_device+0x2b3/0x490
[  927.518005]  __driver_attach+0xdf/0xf0
[  927.518008]  ? driver_probe_device+0x490/0x490
[  927.518014]  bus_for_each_dev+0x6c/0xc0
[  927.518018]  driver_attach+0x1e/0x20
[  927.518021]  bus_add_driver+0x1f4/0x270
[  927.518028]  ? rsi_sdio_ack_intr+0x50/0x50 [rsi_sdio]
[  927.518031]  driver_register+0x60/0xe0
[  927.518038]  ? rsi_sdio_ack_intr+0x50/0x50 [rsi_sdio]
[  927.518041]  sdio_register_driver+0x20/0x30
[  927.518047]  rsi_module_init+0x16/0x40 [rsi_sdio]

Signed-off-by: Siva Rebbagondla 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/rsi/rsi_91x_hal.c  | 35 -
 drivers/net/wireless/rsi/rsi_91x_sdio.c | 21 +---
 drivers/net/wireless/rsi/rsi_sdio.h |  2 +-
 3 files changed, 36 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_hal.c 
b/drivers/net/wireless/rsi/rsi_91x_hal.c
index b7c5403..0761e61 100644
--- a/drivers/net/wireless/rsi/rsi_91x_hal.c
+++ b/drivers/net/wireless/rsi/rsi_91x_hal.c
@@ -635,28 +635,32 @@ static int bl_write_header(struct rsi_hw *adapter, u8 
*flash_content,
   u32 content_size)
 {
struct rsi_host_intf_ops *hif_ops = adapter->host_intf_ops;
-   struct bl_header bl_hdr;
+   struct bl_header *bl_hdr;
u32 write_addr, write_len;
int status;
 
-   bl_hdr.flags = 0;
-   bl_hdr.image_no = cpu_to_le32(adapter->priv->coex_mode);
-   bl_hdr.check_sum = cpu_to_le32(
-   *(u32 *)_content[CHECK_SUM_OFFSET]);
-   bl_hdr.flash_start_address = cpu_to_le32(
-   *(u32 *)_content[ADDR_OFFSET]);
-   bl_hdr.flash_len = cpu_to_le32(*(u32 *)_content[LEN_OFFSET]);
+   bl_hdr = kzalloc(sizeof(*bl_hdr), GFP_KERNEL);
+   if (!bl_hdr)
+   return -ENOMEM;
+
+   bl_hdr->flags = 0;
+   bl_hdr->image_no = cpu_to_le32(adapter->priv->coex_mode);
+   bl_hdr->check_sum =
+   cpu_to_le32(*(u32 *)_content[CHECK_SUM_OFFSET]);
+   bl_hdr->flash_start_address =
+   cpu_to_le32(*(u32 *)_content[ADDR_OFFSET]);
+   bl_hdr->flash_len = cpu_to_le32(*(u32 *)_content[LEN_OFFSET]);
write_len = sizeof(struct bl_header);
 
if (adapter->rsi_host_intf == RSI_HOST_INTF_USB) {
write_addr = PING_BUFFER_ADDRESS;
status = hif_ops->write_reg_multiple(adapter, write_addr,
-(u8 *)_hdr, write_len);
+(u8 *)bl_hdr, write_len);
if (status < 0) {
rsi_dbg(ERR_ZONE,
"%s: Failed to load Version/CRC structure\n",
__func__);
-   return status;
+   goto fail;
}
} else {
write_addr = PING_BUFFER_ADDRESS >> 16;
@@ -665,20 +669,23 @@ static int bl_write_header(struct rsi_hw *adapter, u8 
*flash_content,
rsi_dbg(ERR_ZONE,
"%s: Unable to set ms word to common reg\n",
__func__);
-   return status;
+   goto fail;
}
write_addr = RSI_SD_REQUEST_MASTER |
 (PING_BUFFER_ADDRESS & 0x);
status = 

[PATCH 2/2] rsi: Fix 'invalid vdd' warning in mmc

[Amitkumar Karwar]

From: Siva Rebbagondla 

While performing cleanup, driver is messing with card->ocr
value by not masking rocr against ocr_avail. Below panic
is observed with some of the SDIO host controllers due to
this. Issue is resolved by reverting incorrect modifications
to vdd.

[  927.423821] mmc1: Invalid vdd 0x1f
[  927.423925] Modules linked in: rsi_sdio(+) cmac bnep arc4 rsi_91x
   mac80211 cfg80211 btrsi rfcomm bluetooth ecdh_generic
[  927.424073] CPU: 0 PID: 1624 Comm: insmod Tainted: G W
4.15.0-1000-caracalla #1
[  927.424075] Hardware name: Dell Inc. Edge Gateway3003/  , BIOS 
01.00.06 01/22/2018
[  927.424082] RIP: 0010:sdhci_set_power_noreg+0xdd/0x190[sdhci]
[  927.424085] RSP: 0018:ac3fc064b930 EFLAGS:  00010282
[  927.424107] Call Trace:
[  927.424118]  sdhci_set_power+0x5a/0x60 [sdhci]
[  927.424125]  sdhci_set_ios+0x360/0x3b0 [sdhci]
[  927.424133]  mmc_set_initial_state+0x92/0x120
[  927.424137]  mmc_power_up.part.34+0x33/0x1d0
[  927.424141]  mmc_power_up+0x17/0x20
[  927.424147]  mmc_sdio_runtime_resume+0x2d/0x50
[  927.424151]  mmc_runtime_resume+0x17/0x20
[  927.424156]  __rpm_callback+0xc4/0x200
[  927.424161]  ? idr_alloc_cyclic+0x57/0xd0
[  927.424165]  ? mmc_runtime_suspend+0x20/0x20
[  927.424169]  rpm_callback+0x24/0x80
[  927.424172]  ? mmc_runtime_suspend+0x20/0x20
[  927.424176]  rpm_resume+0x4b3/0x6c0
[  927.424181]  __pm_runtime_resume+0x4e/0x80
[  927.424188]  driver_probe_device+0x41/0x490
[  927.424192]  __driver_attach+0xdf/0xf0
[  927.424196]  ? driver_probe_device+0x490/0x490
[  927.424201]  bus_for_each_dev+0x6c/0xc0
[  927.424205]  driver_attach+0x1e/0x20
[  927.424209]  bus_add_driver+0x1f4/0x270
[  927.424217]  ? rsi_sdio_ack_intr+0x50/0x50 [rsi_sdio]
[  927.424221]  driver_register+0x60/0xe0
[  927.424227]  ? rsi_sdio_ack_intr+0x50/0x50 [rsi_sdio]
[  927.424231]  sdio_register_driver+0x20/0x30
[  927.424237]  rsi_module_init+0x16/0x40 [rsi_sdio]

Signed-off-by: Siva Rebbagondla 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/rsi/rsi_91x_sdio.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c 
b/drivers/net/wireless/rsi/rsi_91x_sdio.c
index f7f2820..416981d 100644
--- a/drivers/net/wireless/rsi/rsi_91x_sdio.c
+++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c
@@ -170,7 +170,6 @@ static void rsi_reset_card(struct sdio_func *pfunction)
int err;
struct mmc_card *card = pfunction->card;
struct mmc_host *host = card->host;
-   s32 bit = (fls(host->ocr_avail) - 1);
u8 cmd52_resp;
u32 clock, resp, i;
u16 rca;
@@ -190,7 +189,6 @@ static void rsi_reset_card(struct sdio_func *pfunction)
msleep(20);
 
/* Initialize the SDIO card */
-   host->ios.vdd = bit;
host->ios.chip_select = MMC_CS_DONTCARE;
host->ios.bus_mode = MMC_BUSMODE_OPENDRAIN;
host->ios.power_mode = MMC_POWER_UP;
-- 
2.7.4

Re: [PATCH 0/1] RFC: memory coherency and data races on TX path

[Daniel Mack]

Hi Ramon,

On Tuesday, April 10, 2018 08:11 PM, Ramon Fried wrote:
> On 10 April 2018 at 20:42, Daniel Mack  wrote:
>> I found something that I believe might be an issue, and I have an
>> idea on how to correct this, but unfortunately, this doesn't solve
>> the issues I occasionally see with this driver. I'd still like to
>> share it, because I might be totally mistaken in my understanding.
>
> Thanks for sharing you idea. Are you aware of the recent patch I sent
> that Loic Poulain
> wrote that fixes a race issue in access to wcn36xx_dxe_tx_frame()  ?
> Kalle just recently applied it to ath-next, I don't think it's
> available yet upstream.

Yes, my patch builds upon yours.

> The patch was fixing something similar, perhaps it will solve the
> issue you're experiencing.

I'm not even sure what kind of effect I'm hunting, so it's hard to tell.
Your patch definitely addresses a data race too though.

>> There's a problem with the latter presumption however which looks like
>> this in the driver code:
>>
>> desc->fr_len = ctl->skb->len;
>> /* set dxe descriptor to VALID */
>> desc->ctrl = ch->ctrl_skb;
>
> The firmware won't start reading the descriptors until it receives an
> interrupt from driver.
> which in turn happen later in the function using: wcn36xx_dxe_write_register()
> so I don't think reordering in this case make any problem.

I understand, but as I said, there's definitely the problem that the
channel is already running when wcn36xx_dxe_tx_frame() is entered. Try
adding this at the beginning of the the function and then run iperf:

int reg;
wcn36xx_dxe_read_register(wcn, ch->reg_ctrl, );
WARN_ON(reg & WCN36xx_DXE_CH_CTRL_EN);

I fail to see how the firmware would determine which descriptors to look
at without any type of synchronization mechanism.

>> Does that make sense? As I said, I can't really say this improves
>> anything, sadly, so I might be mistaken entirely. But I'll leave this
>> here for further discussion. Ideally, somebody with access to the
>> firmware sources could give an assessment whether this is an issue at
>> all or not.
>
> When I'm not sure regarding some implementation I consult with the
> downstream pronto driver.
> https://github.com/sultanqasim/qcom_wlan_prima
> 
> Did you look there if they actually placed wmb() ?

Yes, I've read some of that as well. They use wmb() before writing to
and rmb() after reading firmware registers. The equivalent upstream is
wcn36xx_dxe_[read,write}_register(), and they use writel() and readl()
which have the same barriers on arm64. So that's fine.

What's interesting though is that the downstream drivers sets the VLD
bit of the first descriptor of the chain *after* they set all the
others. There are also some confusing comments about that (/* First
frame not set VAL bit, why ??? */). Can you make sense of that?


Thanks,
Daniel