[PATCH v2] ath10k: Update the phymode along with bandwidth change request

[PATCH v2] ath10k: Update the phymode along with bandwidth change request

[Ryan Hsu]

In the case of Station connects to AP with narrower bandwidth at beginning.
And later the AP changes the bandwidth to winder bandwidth, the AP will
beacon with wider bandwidth IE, eg VHT20->VHT40->VHT80 or VHT40->VHT80.

Since the supported BANDWIDTH will be limited by the PHYMODE, so while
Station receives the bandwidth change request, it will also need to
reconfigure the PHYMODE setting to firmware instead of just configuring
the BANDWIDTH info, otherwise it'll trigger a firmware crash with
non-support bandwidth.

The issue was observed in WLAN.RM.4.4.1-00051-QCARMSWP-1, QCA6174 with
below scenario.
---
AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0 MHz)
disconnect from AP xxx for new auth to yyy
RX ReassocResp from xxx (capab=0x1111 status=0 aid=102)
associated

....

AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0 MHz)
AP xxx changed bandwidth, new config is 5200 MHz, width 3 (5210/0 MHz)

....

firmware register dump:
[00]: 0x05030000 0x000015B3 0x00987291 0x00955B31
[04]: 0x00987291 0x00060730 0x00000004 0x00000001
[08]: 0x004089F0 0x00955A00 0x000A0B00 0x00400000
[12]: 0x00000009 0x00000000 0x00952CD0 0x00952CE6
[16]: 0x00952CC4 0x0098E25F 0x00000000 0x0091080D
[20]: 0x40987291 0x0040E7A8 0x00000000 0x0041EE3C
[24]: 0x809ABF05 0x0040E808 0x00000000 0xC0987291
[28]: 0x809A650C 0x0040E948 0x0041FE40 0x004345C4
[32]: 0x809A5C63 0x0040E988 0x0040E9AC 0x0042D1A8
[36]: 0x8091D252 0x0040E9A8 0x00000002 0x00000001
[40]: 0x809FDA9D 0x0040EA58 0x0043D554 0x0042D554
[44]: 0x809F8B22 0x0040EA78 0x0043D554 0x00000001
[48]: 0x80911210 0x0040EAC8 0x00000010 0x004041D0
[52]: 0x80911154 0x0040EB28 0x00400000 0x00000000
[56]: 0x8091122D 0x0040EB48 0x00000000 0x00400600
--

Reported-by: Rouven Czerwinski <rouven@czerwinskis.de>
Signed-off-by: Ryan Hsu <ryanhsu@codeaurora.org>
---
 drivers/net/wireless/ath/ath10k/mac.c | 16 ++++++++++++++--
 drivers/net/wireless/ath/ath10k/wmi.h |  1 +
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index e9c2fb3..836e0a4 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6058,8 +6058,19 @@ static void ath10k_sta_rc_update_wk(struct work_struct *wk)
 			   ath10k_mac_max_vht_nss(vht_mcs_mask)));
 
 	if (changed & IEEE80211_RC_BW_CHANGED) {
-		ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM peer bw %d\n",
-			   sta->addr, bw);
+		enum wmi_phy_mode mode;
+
+		mode = chan_to_phymode(&def);
+		ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM peer bw %d phymode %d\n",
+				sta->addr, bw, mode);
+
+		err = ath10k_wmi_peer_set_param(ar, arvif->vdev_id, sta->addr,
+				WMI_PEER_PHYMODE, mode);
+		if (err) {
+			ath10k_warn(ar, "failed to update STA %pM peer phymode %d: %d\n",
+					sta->addr, mode, err);
+			goto exit;
+		}
 
 		err = ath10k_wmi_peer_set_param(ar, arvif->vdev_id, sta->addr,
 						WMI_PEER_CHAN_WIDTH, bw);
@@ -6100,6 +6111,7 @@ static void ath10k_sta_rc_update_wk(struct work_struct *wk)
 				    sta->addr);
 	}
 
+exit:
 	mutex_unlock(&ar->conf_mutex);
 }
 
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index b48db54..d68afb6 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -6144,6 +6144,7 @@ enum wmi_peer_param {
 	WMI_PEER_NSS        = 0x5,
 	WMI_PEER_USE_4ADDR  = 0x6,
 	WMI_PEER_DEBUG      = 0xa,
+	WMI_PEER_PHYMODE    = 0xd,
 	WMI_PEER_DUMMY_VAR  = 0xff, /* dummy parameter for STA PS workaround */
 };
 
-- 
1.9.1

[PATCH v2] ath10k: Update the phymode along with bandwidth change request

[Ryan Hsu]

In the case of Station connects to AP with narrower bandwidth at beginning.
And later the AP changes the bandwidth to winder bandwidth, the AP will
beacon with wider bandwidth IE, eg VHT20->VHT40->VHT80 or VHT40->VHT80.

Since the supported BANDWIDTH will be limited by the PHYMODE, so while
Station receives the bandwidth change request, it will also need to
reconfigure the PHYMODE setting to firmware instead of just configuring
the BANDWIDTH info, otherwise it'll trigger a firmware crash with
non-support bandwidth.

The issue was observed in WLAN.RM.4.4.1-00051-QCARMSWP-1, QCA6174 with
below scenario.
---
AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0 MHz)
disconnect from AP xxx for new auth to yyy
RX ReassocResp from xxx (capab=0x1111 status=0 aid=102)
associated

....

AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0 MHz)
AP xxx changed bandwidth, new config is 5200 MHz, width 3 (5210/0 MHz)

....

firmware register dump:
[00]: 0x05030000 0x000015B3 0x00987291 0x00955B31
[04]: 0x00987291 0x00060730 0x00000004 0x00000001
[08]: 0x004089F0 0x00955A00 0x000A0B00 0x00400000
[12]: 0x00000009 0x00000000 0x00952CD0 0x00952CE6
[16]: 0x00952CC4 0x0098E25F 0x00000000 0x0091080D
[20]: 0x40987291 0x0040E7A8 0x00000000 0x0041EE3C
[24]: 0x809ABF05 0x0040E808 0x00000000 0xC0987291
[28]: 0x809A650C 0x0040E948 0x0041FE40 0x004345C4
[32]: 0x809A5C63 0x0040E988 0x0040E9AC 0x0042D1A8
[36]: 0x8091D252 0x0040E9A8 0x00000002 0x00000001
[40]: 0x809FDA9D 0x0040EA58 0x0043D554 0x0042D554
[44]: 0x809F8B22 0x0040EA78 0x0043D554 0x00000001
[48]: 0x80911210 0x0040EAC8 0x00000010 0x004041D0
[52]: 0x80911154 0x0040EB28 0x00400000 0x00000000
[56]: 0x8091122D 0x0040EB48 0x00000000 0x00400600
--

Reported-by: Rouven Czerwinski <rouven@czerwinskis.de>
Signed-off-by: Ryan Hsu <ryanhsu@codeaurora.org>
---
 drivers/net/wireless/ath/ath10k/mac.c | 16 ++++++++++++++--
 drivers/net/wireless/ath/ath10k/wmi.h |  1 +
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index e9c2fb3..836e0a4 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6058,8 +6058,19 @@ static void ath10k_sta_rc_update_wk(struct work_struct *wk)
 			   ath10k_mac_max_vht_nss(vht_mcs_mask)));
 
 	if (changed & IEEE80211_RC_BW_CHANGED) {
-		ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM peer bw %d\n",
-			   sta->addr, bw);
+		enum wmi_phy_mode mode;
+
+		mode = chan_to_phymode(&def);
+		ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM peer bw %d phymode %d\n",
+				sta->addr, bw, mode);
+
+		err = ath10k_wmi_peer_set_param(ar, arvif->vdev_id, sta->addr,
+				WMI_PEER_PHYMODE, mode);
+		if (err) {
+			ath10k_warn(ar, "failed to update STA %pM peer phymode %d: %d\n",
+					sta->addr, mode, err);
+			goto exit;
+		}
 
 		err = ath10k_wmi_peer_set_param(ar, arvif->vdev_id, sta->addr,
 						WMI_PEER_CHAN_WIDTH, bw);
@@ -6100,6 +6111,7 @@ static void ath10k_sta_rc_update_wk(struct work_struct *wk)
 				    sta->addr);
 	}
 
+exit:
 	mutex_unlock(&ar->conf_mutex);
 }
 
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index b48db54..d68afb6 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -6144,6 +6144,7 @@ enum wmi_peer_param {
 	WMI_PEER_NSS        = 0x5,
 	WMI_PEER_USE_4ADDR  = 0x6,
 	WMI_PEER_DEBUG      = 0xa,
+	WMI_PEER_PHYMODE    = 0xd,
 	WMI_PEER_DUMMY_VAR  = 0xff, /* dummy parameter for STA PS workaround */
 };
 
-- 
1.9.1


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] ath10k: Update the phymode along with bandwidth change request

[Timur Kristóf]

On Fri, 2018-06-08 at 11:32 -0700, Ryan Hsu wrote:
> In the case of Station connects to AP with narrower bandwidth at
> beginning.
> And later the AP changes the bandwidth to winder bandwidth, the AP
> will
> beacon with wider bandwidth IE, eg VHT20->VHT40->VHT80 or VHT40-
> >VHT80.
> 
> Since the supported BANDWIDTH will be limited by the PHYMODE, so
> while
> Station receives the bandwidth change request, it will also need to
> reconfigure the PHYMODE setting to firmware instead of just
> configuring
> the BANDWIDTH info, otherwise it'll trigger a firmware crash with
> non-support bandwidth.
> 
> The issue was observed in WLAN.RM.4.4.1-00051-QCARMSWP-1, QCA6174
> with
> below scenario.
> ---
> AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0
> MHz)
> disconnect from AP xxx for new auth to yyy
> RX ReassocResp from xxx (capab=0x1111 status=0 aid=102)
> associated
> 
> ....
> 
> AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0
> MHz)
> AP xxx changed bandwidth, new config is 5200 MHz, width 3 (5210/0
> MHz)
> 
> ....
> 
> firmware register dump:
> [00]: 0x05030000 0x000015B3 0x00987291 0x00955B31
> [04]: 0x00987291 0x00060730 0x00000004 0x00000001
> [08]: 0x004089F0 0x00955A00 0x000A0B00 0x00400000
> [12]: 0x00000009 0x00000000 0x00952CD0 0x00952CE6
> [16]: 0x00952CC4 0x0098E25F 0x00000000 0x0091080D
> [20]: 0x40987291 0x0040E7A8 0x00000000 0x0041EE3C
> [24]: 0x809ABF05 0x0040E808 0x00000000 0xC0987291
> [28]: 0x809A650C 0x0040E948 0x0041FE40 0x004345C4
> [32]: 0x809A5C63 0x0040E988 0x0040E9AC 0x0042D1A8
> [36]: 0x8091D252 0x0040E9A8 0x00000002 0x00000001
> [40]: 0x809FDA9D 0x0040EA58 0x0043D554 0x0042D554
> [44]: 0x809F8B22 0x0040EA78 0x0043D554 0x00000001
> [48]: 0x80911210 0x0040EAC8 0x00000010 0x004041D0
> [52]: 0x80911154 0x0040EB28 0x00400000 0x00000000
> [56]: 0x8091122D 0x0040EB48 0x00000000 0x00400600
> --
> 
> Reported-by: Rouven Czerwinski <rouven@czerwinskis.de>
> Signed-off-by: Ryan Hsu <ryanhsu@codeaurora.org>
> ---
>  drivers/net/wireless/ath/ath10k/mac.c | 16 ++++++++++++++--
>  drivers/net/wireless/ath/ath10k/wmi.h |  1 +
>  2 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
> b/drivers/net/wireless/ath/ath10k/mac.c
> index e9c2fb3..836e0a4 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -6058,8 +6058,19 @@ static void ath10k_sta_rc_update_wk(struct
> work_struct *wk)
>  			   ath10k_mac_max_vht_nss(vht_mcs_mask)));
>  
>  	if (changed & IEEE80211_RC_BW_CHANGED) {
> -		ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM
> peer bw %d\n",
> -			   sta->addr, bw);
> +		enum wmi_phy_mode mode;
> +
> +		mode = chan_to_phymode(&def);
> +		ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM
> peer bw %d phymode %d\n",
> +				sta->addr, bw, mode);
> +
> +		err = ath10k_wmi_peer_set_param(ar, arvif->vdev_id,
> sta->addr,
> +				WMI_PEER_PHYMODE, mode);
> +		if (err) {
> +			ath10k_warn(ar, "failed to update STA %pM
> peer phymode %d: %d\n",
> +					sta->addr, mode, err);
> +			goto exit;
> +		}
>  
>  		err = ath10k_wmi_peer_set_param(ar, arvif->vdev_id,
> sta->addr,
>  						WMI_PEER_CHAN_WIDTH,
> bw);
> @@ -6100,6 +6111,7 @@ static void ath10k_sta_rc_update_wk(struct
> work_struct *wk)
>  				    sta->addr);
>  	}
>  
> +exit:
>  	mutex_unlock(&ar->conf_mutex);
>  }
>  
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.h
> b/drivers/net/wireless/ath/ath10k/wmi.h
> index b48db54..d68afb6 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.h
> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
> @@ -6144,6 +6144,7 @@ enum wmi_peer_param {
>  	WMI_PEER_NSS        = 0x5,
>  	WMI_PEER_USE_4ADDR  = 0x6,
>  	WMI_PEER_DEBUG      = 0xa,
> +	WMI_PEER_PHYMODE    = 0xd,
>  	WMI_PEER_DUMMY_VAR  = 0xff, /* dummy parameter for STA PS
> workaround */
>  };
>  


Hi,

I can confirm that this patch works on my machine, and prevents the
crash previously caused by changing the bandwidth. Can it be accepted,
or is there anything I can help with, to get it accepted?

Thanks,
Tim

Re: [PATCH v2] ath10k: Update the phymode along with bandwidth change request

[Timur Kristóf]

On Fri, 2018-06-08 at 11:32 -0700, Ryan Hsu wrote:
> In the case of Station connects to AP with narrower bandwidth at
> beginning.
> And later the AP changes the bandwidth to winder bandwidth, the AP
> will
> beacon with wider bandwidth IE, eg VHT20->VHT40->VHT80 or VHT40-
> >VHT80.
> 
> Since the supported BANDWIDTH will be limited by the PHYMODE, so
> while
> Station receives the bandwidth change request, it will also need to
> reconfigure the PHYMODE setting to firmware instead of just
> configuring
> the BANDWIDTH info, otherwise it'll trigger a firmware crash with
> non-support bandwidth.
> 
> The issue was observed in WLAN.RM.4.4.1-00051-QCARMSWP-1, QCA6174
> with
> below scenario.
> ---
> AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0
> MHz)
> disconnect from AP xxx for new auth to yyy
> RX ReassocResp from xxx (capab=0x1111 status=0 aid=102)
> associated
> 
> ....
> 
> AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0
> MHz)
> AP xxx changed bandwidth, new config is 5200 MHz, width 3 (5210/0
> MHz)
> 
> ....
> 
> firmware register dump:
> [00]: 0x05030000 0x000015B3 0x00987291 0x00955B31
> [04]: 0x00987291 0x00060730 0x00000004 0x00000001
> [08]: 0x004089F0 0x00955A00 0x000A0B00 0x00400000
> [12]: 0x00000009 0x00000000 0x00952CD0 0x00952CE6
> [16]: 0x00952CC4 0x0098E25F 0x00000000 0x0091080D
> [20]: 0x40987291 0x0040E7A8 0x00000000 0x0041EE3C
> [24]: 0x809ABF05 0x0040E808 0x00000000 0xC0987291
> [28]: 0x809A650C 0x0040E948 0x0041FE40 0x004345C4
> [32]: 0x809A5C63 0x0040E988 0x0040E9AC 0x0042D1A8
> [36]: 0x8091D252 0x0040E9A8 0x00000002 0x00000001
> [40]: 0x809FDA9D 0x0040EA58 0x0043D554 0x0042D554
> [44]: 0x809F8B22 0x0040EA78 0x0043D554 0x00000001
> [48]: 0x80911210 0x0040EAC8 0x00000010 0x004041D0
> [52]: 0x80911154 0x0040EB28 0x00400000 0x00000000
> [56]: 0x8091122D 0x0040EB48 0x00000000 0x00400600
> --
> 
> Reported-by: Rouven Czerwinski <rouven@czerwinskis.de>
> Signed-off-by: Ryan Hsu <ryanhsu@codeaurora.org>
> ---
>  drivers/net/wireless/ath/ath10k/mac.c | 16 ++++++++++++++--
>  drivers/net/wireless/ath/ath10k/wmi.h |  1 +
>  2 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
> b/drivers/net/wireless/ath/ath10k/mac.c
> index e9c2fb3..836e0a4 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -6058,8 +6058,19 @@ static void ath10k_sta_rc_update_wk(struct
> work_struct *wk)
>  			   ath10k_mac_max_vht_nss(vht_mcs_mask)));
>  
>  	if (changed & IEEE80211_RC_BW_CHANGED) {
> -		ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM
> peer bw %d\n",
> -			   sta->addr, bw);
> +		enum wmi_phy_mode mode;
> +
> +		mode = chan_to_phymode(&def);
> +		ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM
> peer bw %d phymode %d\n",
> +				sta->addr, bw, mode);
> +
> +		err = ath10k_wmi_peer_set_param(ar, arvif->vdev_id,
> sta->addr,
> +				WMI_PEER_PHYMODE, mode);
> +		if (err) {
> +			ath10k_warn(ar, "failed to update STA %pM
> peer phymode %d: %d\n",
> +					sta->addr, mode, err);
> +			goto exit;
> +		}
>  
>  		err = ath10k_wmi_peer_set_param(ar, arvif->vdev_id,
> sta->addr,
>  						WMI_PEER_CHAN_WIDTH,
> bw);
> @@ -6100,6 +6111,7 @@ static void ath10k_sta_rc_update_wk(struct
> work_struct *wk)
>  				    sta->addr);
>  	}
>  
> +exit:
>  	mutex_unlock(&ar->conf_mutex);
>  }
>  
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.h
> b/drivers/net/wireless/ath/ath10k/wmi.h
> index b48db54..d68afb6 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.h
> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
> @@ -6144,6 +6144,7 @@ enum wmi_peer_param {
>  	WMI_PEER_NSS        = 0x5,
>  	WMI_PEER_USE_4ADDR  = 0x6,
>  	WMI_PEER_DEBUG      = 0xa,
> +	WMI_PEER_PHYMODE    = 0xd,
>  	WMI_PEER_DUMMY_VAR  = 0xff, /* dummy parameter for STA PS
> workaround */
>  };
>  


Hi,

I can confirm that this patch works on my machine, and prevents the
crash previously caused by changing the bandwidth. Can it be accepted,
or is there anything I can help with, to get it accepted?

Thanks,
Tim


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] ath10k: Update the phymode along with bandwidth change request

[Kalle Valo]

Timur Krist=C3=B3f <timur.kristof@gmail.com> writes:

> On Fri, 2018-06-08 at 11:32 -0700, Ryan Hsu wrote:
>> In the case of Station connects to AP with narrower bandwidth at
>> beginning.
>> And later the AP changes the bandwidth to winder bandwidth, the AP
>> will
>> beacon with wider bandwidth IE, eg VHT20->VHT40->VHT80 or VHT40-
>> >VHT80.
>>=20
>> Since the supported BANDWIDTH will be limited by the PHYMODE, so
>> while
>> Station receives the bandwidth change request, it will also need to
>> reconfigure the PHYMODE setting to firmware instead of just
>> configuring
>> the BANDWIDTH info, otherwise it'll trigger a firmware crash with
>> non-support bandwidth.
>>=20
>> The issue was observed in WLAN.RM.4.4.1-00051-QCARMSWP-1, QCA6174
>> with
>> below scenario.

[...]

> I can confirm that this patch works on my machine, and prevents the
> crash previously caused by changing the bandwidth.

Great, thanks a lot for working on this. I'll add your Tested-by to the
commit log.

> Can it be accepted, or is there anything I can help with, to get it
> accepted?

Strangely I can't find Timur's version of the patch from patchwork:

https://patchwork.kernel.org/project/linux-wireless/list/?state=3D*

Maybe it got dropped due to some UTF-8 problems? patchwork is known to
be problematic with UTF-8.

Anyway, I'll queue Ryan's v2 to 4.18. It first goes to the pending
branch for build testing and from there to ath-current branch.

--=20
Kalle Valo

Re: [PATCH v2] ath10k: Update the phymode along with bandwidth change request

[Kalle Valo]

Timur Kristóf <timur.kristof@gmail.com> writes:

> On Fri, 2018-06-08 at 11:32 -0700, Ryan Hsu wrote:
>> In the case of Station connects to AP with narrower bandwidth at
>> beginning.
>> And later the AP changes the bandwidth to winder bandwidth, the AP
>> will
>> beacon with wider bandwidth IE, eg VHT20->VHT40->VHT80 or VHT40-
>> >VHT80.
>> 
>> Since the supported BANDWIDTH will be limited by the PHYMODE, so
>> while
>> Station receives the bandwidth change request, it will also need to
>> reconfigure the PHYMODE setting to firmware instead of just
>> configuring
>> the BANDWIDTH info, otherwise it'll trigger a firmware crash with
>> non-support bandwidth.
>> 
>> The issue was observed in WLAN.RM.4.4.1-00051-QCARMSWP-1, QCA6174
>> with
>> below scenario.

[...]

> I can confirm that this patch works on my machine, and prevents the
> crash previously caused by changing the bandwidth.

Great, thanks a lot for working on this. I'll add your Tested-by to the
commit log.

> Can it be accepted, or is there anything I can help with, to get it
> accepted?

Strangely I can't find Timur's version of the patch from patchwork:

https://patchwork.kernel.org/project/linux-wireless/list/?state=*

Maybe it got dropped due to some UTF-8 problems? patchwork is known to
be problematic with UTF-8.

Anyway, I'll queue Ryan's v2 to 4.18. It first goes to the pending
branch for build testing and from there to ath-current branch.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] ath10k: Update the phymode along with bandwidth change request

[Timur Kristóf]

On Tue, 2018-06-12 at 14:40 +0300, Kalle Valo wrote:
> Timur Kristóf <timur.kristof@gmail.com> writes:
> 
> > On Fri, 2018-06-08 at 11:32 -0700, Ryan Hsu wrote:
> > > In the case of Station connects to AP with narrower bandwidth at
> > > beginning.
> > > And later the AP changes the bandwidth to winder bandwidth, the
> > > AP
> > > will
> > > beacon with wider bandwidth IE, eg VHT20->VHT40->VHT80 or VHT40-
> > > > VHT80.
> > > 
> > > Since the supported BANDWIDTH will be limited by the PHYMODE, so
> > > while
> > > Station receives the bandwidth change request, it will also need
> > > to
> > > reconfigure the PHYMODE setting to firmware instead of just
> > > configuring
> > > the BANDWIDTH info, otherwise it'll trigger a firmware crash with
> > > non-support bandwidth.
> > > 
> > > The issue was observed in WLAN.RM.4.4.1-00051-QCARMSWP-1, QCA6174
> > > with
> > > below scenario.
> 
> [...]
> 
> > I can confirm that this patch works on my machine, and prevents the
> > crash previously caused by changing the bandwidth.
> 
> Great, thanks a lot for working on this. I'll add your Tested-by to
> the
> commit log.

Thanks!

> > Can it be accepted, or is there anything I can help with, to get it
> > accepted?
> 
> Strangely I can't find Timur's version of the patch from patchwork:
> 
> https://patchwork.kernel.org/project/linux-wireless/list/?state=*
> 
> Maybe it got dropped due to some UTF-8 problems? patchwork is known
> to
> be problematic with UTF-8.

Not sure. It doesn't really matter now, Ryan's version is fine too.

> Anyway, I'll queue Ryan's v2 to 4.18. It first goes to the pending
> branch for build testing and from there to ath-current branch.

Awesome, thank you Kalle!

Best regards,
Tim

Re: [PATCH v2] ath10k: Update the phymode along with bandwidth change request

[Timur Kristóf]

On Tue, 2018-06-12 at 14:40 +0300, Kalle Valo wrote:
> Timur Kristóf <timur.kristof@gmail.com> writes:
> 
> > On Fri, 2018-06-08 at 11:32 -0700, Ryan Hsu wrote:
> > > In the case of Station connects to AP with narrower bandwidth at
> > > beginning.
> > > And later the AP changes the bandwidth to winder bandwidth, the
> > > AP
> > > will
> > > beacon with wider bandwidth IE, eg VHT20->VHT40->VHT80 or VHT40-
> > > > VHT80.
> > > 
> > > Since the supported BANDWIDTH will be limited by the PHYMODE, so
> > > while
> > > Station receives the bandwidth change request, it will also need
> > > to
> > > reconfigure the PHYMODE setting to firmware instead of just
> > > configuring
> > > the BANDWIDTH info, otherwise it'll trigger a firmware crash with
> > > non-support bandwidth.
> > > 
> > > The issue was observed in WLAN.RM.4.4.1-00051-QCARMSWP-1, QCA6174
> > > with
> > > below scenario.
> 
> [...]
> 
> > I can confirm that this patch works on my machine, and prevents the
> > crash previously caused by changing the bandwidth.
> 
> Great, thanks a lot for working on this. I'll add your Tested-by to
> the
> commit log.

Thanks!

> > Can it be accepted, or is there anything I can help with, to get it
> > accepted?
> 
> Strangely I can't find Timur's version of the patch from patchwork:
> 
> https://patchwork.kernel.org/project/linux-wireless/list/?state=*
> 
> Maybe it got dropped due to some UTF-8 problems? patchwork is known
> to
> be problematic with UTF-8.

Not sure. It doesn't really matter now, Ryan's version is fine too.

> Anyway, I'll queue Ryan's v2 to 4.18. It first goes to the pending
> branch for build testing and from there to ath-current branch.

Awesome, thank you Kalle!

Best regards,
Tim

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] ath10k: Update the phymode along with bandwidth change request

[Kalle Valo]

Timur Krist=C3=B3f <timur.kristof@gmail.com> writes:

>> > Can it be accepted, or is there anything I can help with, to get it
>> > accepted?
>>=20
>> Strangely I can't find Timur's version of the patch from patchwork:
>>=20
>> https://patchwork.kernel.org/project/linux-wireless/list/?state=3D*
>>=20
>> Maybe it got dropped due to some UTF-8 problems? patchwork is known
>> to
>> be problematic with UTF-8.
>
> Not sure. It doesn't really matter now, Ryan's version is fine too.

Sure but try to remember this if you are planning to submit more
wireless patches in the future. Johannes and me take patches directly
from patchwork, and if the patch isn't there we won't see it.

--=20
Kalle Valo

Re: [PATCH v2] ath10k: Update the phymode along with bandwidth change request

[Kalle Valo]

Timur Kristóf <timur.kristof@gmail.com> writes:

>> > Can it be accepted, or is there anything I can help with, to get it
>> > accepted?
>> 
>> Strangely I can't find Timur's version of the patch from patchwork:
>> 
>> https://patchwork.kernel.org/project/linux-wireless/list/?state=*
>> 
>> Maybe it got dropped due to some UTF-8 problems? patchwork is known
>> to
>> be problematic with UTF-8.
>
> Not sure. It doesn't really matter now, Ryan's version is fine too.

Sure but try to remember this if you are planning to submit more
wireless patches in the future. Johannes and me take patches directly
from patchwork, and if the patch isn't there we won't see it.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] ath10k: Update the phymode along with bandwidth change request

[Kalle Valo]

Ryan Hsu <ryanhsu@codeaurora.org> writes:

> In the case of Station connects to AP with narrower bandwidth at beginning.
> And later the AP changes the bandwidth to winder bandwidth, the AP will
> beacon with wider bandwidth IE, eg VHT20->VHT40->VHT80 or VHT40->VHT80.
>
> Since the supported BANDWIDTH will be limited by the PHYMODE, so while
> Station receives the bandwidth change request, it will also need to
> reconfigure the PHYMODE setting to firmware instead of just configuring
> the BANDWIDTH info, otherwise it'll trigger a firmware crash with
> non-support bandwidth.
>
> The issue was observed in WLAN.RM.4.4.1-00051-QCARMSWP-1, QCA6174 with
> below scenario.
> ---

BTW, I don't recommend using "---" or similar delimeters in the actual
commit log. Git uses that string as a separator between the commit log
and actual patch and that broke my patchwork script. I fixed the commit
log manually in the pending branch, and added Timur's Tested-by, please
check (I hope I got UTF-8 correct!):

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=master-pending&id=5aee6aeda5dae74e1c79256fc1df2e7599038fa7

-- 
Kalle Valo

Re: [PATCH v2] ath10k: Update the phymode along with bandwidth change request

[Kalle Valo]

Ryan Hsu <ryanhsu@codeaurora.org> writes:

> In the case of Station connects to AP with narrower bandwidth at beginning.
> And later the AP changes the bandwidth to winder bandwidth, the AP will
> beacon with wider bandwidth IE, eg VHT20->VHT40->VHT80 or VHT40->VHT80.
>
> Since the supported BANDWIDTH will be limited by the PHYMODE, so while
> Station receives the bandwidth change request, it will also need to
> reconfigure the PHYMODE setting to firmware instead of just configuring
> the BANDWIDTH info, otherwise it'll trigger a firmware crash with
> non-support bandwidth.
>
> The issue was observed in WLAN.RM.4.4.1-00051-QCARMSWP-1, QCA6174 with
> below scenario.
> ---

BTW, I don't recommend using "---" or similar delimeters in the actual
commit log. Git uses that string as a separator between the commit log
and actual patch and that broke my patchwork script. I fixed the commit
log manually in the pending branch, and added Timur's Tested-by, please
check (I hope I got UTF-8 correct!):

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=master-pending&id=5aee6aeda5dae74e1c79256fc1df2e7599038fa7

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] ath10k: Update the phymode along with bandwidth change request

[Ryan Hsu]

On 06/14/2018 02:07 AM, Kalle Valo wrote:

> BTW, I don't recommend using "---" or similar delimeters in the actual
> commit log. Git uses that string as a separator between the commit log
> and actual patch and that broke my patchwork script. I fixed the commit
> log manually in the pending branch, and added Timur's Tested-by, please
> check (I hope I got UTF-8 correct!):
>
> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=master-pending&id=5aee6aeda5dae74e1c79256fc1df2e7599038fa7
>

Thanks Kalle, patch looks good to me, will avoid use "---".

-- 
Ryan Hsu

Re: [PATCH v2] ath10k: Update the phymode along with bandwidth change request

[Ryan Hsu]

On 06/14/2018 02:07 AM, Kalle Valo wrote:

> BTW, I don't recommend using "---" or similar delimeters in the actual
> commit log. Git uses that string as a separator between the commit log
> and actual patch and that broke my patchwork script. I fixed the commit
> log manually in the pending branch, and added Timur's Tested-by, please
> check (I hope I got UTF-8 correct!):
>
> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=master-pending&id=5aee6aeda5dae74e1c79256fc1df2e7599038fa7
>

Thanks Kalle, patch looks good to me, will avoid use "---".

-- 
Ryan Hsu


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [v2] ath10k: Update the phymode along with bandwidth change request

[Kalle Valo]

Ryan Hsu <ryanhsu@codeaurora.org> wrote:

> In the case of Station connects to AP with narrower bandwidth at beginning.
> And later the AP changes the bandwidth to winder bandwidth, the AP will
> beacon with wider bandwidth IE, eg VHT20->VHT40->VHT80 or VHT40->VHT80.
> 
> Since the supported BANDWIDTH will be limited by the PHYMODE, so while
> Station receives the bandwidth change request, it will also need to
> reconfigure the PHYMODE setting to firmware instead of just configuring
> the BANDWIDTH info, otherwise it'll trigger a firmware crash with
> non-support bandwidth.
> 
> The issue was observed in WLAN.RM.4.4.1-00051-QCARMSWP-1, QCA6174 with
> below scenario:
> 
> AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0 MHz)
> disconnect from AP xxx for new auth to yyy
> RX ReassocResp from xxx (capab=0x1111 status=0 aid=102)
> associated
> 
> ....
> 
> AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0 MHz)
> AP xxx changed bandwidth, new config is 5200 MHz, width 3 (5210/0 MHz)
> 
> ....
> 
> firmware register dump:
> [00]: 0x05030000 0x000015B3 0x00987291 0x00955B31
> [04]: 0x00987291 0x00060730 0x00000004 0x00000001
> [08]: 0x004089F0 0x00955A00 0x000A0B00 0x00400000
> [12]: 0x00000009 0x00000000 0x00952CD0 0x00952CE6
> [16]: 0x00952CC4 0x0098E25F 0x00000000 0x0091080D
> [20]: 0x40987291 0x0040E7A8 0x00000000 0x0041EE3C
> [24]: 0x809ABF05 0x0040E808 0x00000000 0xC0987291
> [28]: 0x809A650C 0x0040E948 0x0041FE40 0x004345C4
> [32]: 0x809A5C63 0x0040E988 0x0040E9AC 0x0042D1A8
> [36]: 0x8091D252 0x0040E9A8 0x00000002 0x00000001
> [40]: 0x809FDA9D 0x0040EA58 0x0043D554 0x0042D554
> [44]: 0x809F8B22 0x0040EA78 0x0043D554 0x00000001
> [48]: 0x80911210 0x0040EAC8 0x00000010 0x004041D0
> [52]: 0x80911154 0x0040EB28 0x00400000 0x00000000
> [56]: 0x8091122D 0x0040EB48 0x00000000 0x00400600
> 
> Reported-by: Rouven Czerwinski <rouven@czerwinskis.de>
> Tested-by: Timur Kristóf <timur.kristof@gmail.com>
> Signed-off-by: Ryan Hsu <ryanhsu@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Patch applied to ath-current branch of ath.git, thanks.

9191fc2a431b ath10k: update the phymode along with bandwidth change request

-- 
https://patchwork.kernel.org/patch/10454965/

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

Re: [v2] ath10k: Update the phymode along with bandwidth change request

[Kalle Valo]

Ryan Hsu <ryanhsu@codeaurora.org> wrote:

> In the case of Station connects to AP with narrower bandwidth at beginning.
> And later the AP changes the bandwidth to winder bandwidth, the AP will
> beacon with wider bandwidth IE, eg VHT20->VHT40->VHT80 or VHT40->VHT80.
> 
> Since the supported BANDWIDTH will be limited by the PHYMODE, so while
> Station receives the bandwidth change request, it will also need to
> reconfigure the PHYMODE setting to firmware instead of just configuring
> the BANDWIDTH info, otherwise it'll trigger a firmware crash with
> non-support bandwidth.
> 
> The issue was observed in WLAN.RM.4.4.1-00051-QCARMSWP-1, QCA6174 with
> below scenario:
> 
> AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0 MHz)
> disconnect from AP xxx for new auth to yyy
> RX ReassocResp from xxx (capab=0x1111 status=0 aid=102)
> associated
> 
> ....
> 
> AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0 MHz)
> AP xxx changed bandwidth, new config is 5200 MHz, width 3 (5210/0 MHz)
> 
> ....
> 
> firmware register dump:
> [00]: 0x05030000 0x000015B3 0x00987291 0x00955B31
> [04]: 0x00987291 0x00060730 0x00000004 0x00000001
> [08]: 0x004089F0 0x00955A00 0x000A0B00 0x00400000
> [12]: 0x00000009 0x00000000 0x00952CD0 0x00952CE6
> [16]: 0x00952CC4 0x0098E25F 0x00000000 0x0091080D
> [20]: 0x40987291 0x0040E7A8 0x00000000 0x0041EE3C
> [24]: 0x809ABF05 0x0040E808 0x00000000 0xC0987291
> [28]: 0x809A650C 0x0040E948 0x0041FE40 0x004345C4
> [32]: 0x809A5C63 0x0040E988 0x0040E9AC 0x0042D1A8
> [36]: 0x8091D252 0x0040E9A8 0x00000002 0x00000001
> [40]: 0x809FDA9D 0x0040EA58 0x0043D554 0x0042D554
> [44]: 0x809F8B22 0x0040EA78 0x0043D554 0x00000001
> [48]: 0x80911210 0x0040EAC8 0x00000010 0x004041D0
> [52]: 0x80911154 0x0040EB28 0x00400000 0x00000000
> [56]: 0x8091122D 0x0040EB48 0x00000000 0x00400600
> 
> Reported-by: Rouven Czerwinski <rouven@czerwinskis.de>
> Tested-by: Timur Kristóf <timur.kristof@gmail.com>
> Signed-off-by: Ryan Hsu <ryanhsu@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Patch applied to ath-current branch of ath.git, thanks.

9191fc2a431b ath10k: update the phymode along with bandwidth change request

-- 
https://patchwork.kernel.org/patch/10454965/

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


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [v2] ath10k: Update the phymode along with bandwidth change request

[Timur Kristóf]

On Thu, 2018-06-28 at 09:28 +0000, Kalle Valo wrote:
> Ryan Hsu <ryanhsu@codeaurora.org> wrote:
> 
> > In the case of Station connects to AP with narrower bandwidth at
> > beginning.
> > And later the AP changes the bandwidth to winder bandwidth, the AP
> > will
> > beacon with wider bandwidth IE, eg VHT20->VHT40->VHT80 or VHT40-
> > >VHT80.
> > 
> > Since the supported BANDWIDTH will be limited by the PHYMODE, so
> > while
> > Station receives the bandwidth change request, it will also need to
> > reconfigure the PHYMODE setting to firmware instead of just
> > configuring
> > the BANDWIDTH info, otherwise it'll trigger a firmware crash with
> > non-support bandwidth.
> > 
> > The issue was observed in WLAN.RM.4.4.1-00051-QCARMSWP-1, QCA6174
> > with
> > below scenario:
> > 
> > AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0
> > MHz)
> > disconnect from AP xxx for new auth to yyy
> > RX ReassocResp from xxx (capab=0x1111 status=0 aid=102)
> > associated
> > 
> > ....
> > 
> > AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0
> > MHz)
> > AP xxx changed bandwidth, new config is 5200 MHz, width 3 (5210/0
> > MHz)
> > 
> > ....
> > 
> > firmware register dump:
> > [00]: 0x05030000 0x000015B3 0x00987291 0x00955B31
> > [04]: 0x00987291 0x00060730 0x00000004 0x00000001
> > [08]: 0x004089F0 0x00955A00 0x000A0B00 0x00400000
> > [12]: 0x00000009 0x00000000 0x00952CD0 0x00952CE6
> > [16]: 0x00952CC4 0x0098E25F 0x00000000 0x0091080D
> > [20]: 0x40987291 0x0040E7A8 0x00000000 0x0041EE3C
> > [24]: 0x809ABF05 0x0040E808 0x00000000 0xC0987291
> > [28]: 0x809A650C 0x0040E948 0x0041FE40 0x004345C4
> > [32]: 0x809A5C63 0x0040E988 0x0040E9AC 0x0042D1A8
> > [36]: 0x8091D252 0x0040E9A8 0x00000002 0x00000001
> > [40]: 0x809FDA9D 0x0040EA58 0x0043D554 0x0042D554
> > [44]: 0x809F8B22 0x0040EA78 0x0043D554 0x00000001
> > [48]: 0x80911210 0x0040EAC8 0x00000010 0x004041D0
> > [52]: 0x80911154 0x0040EB28 0x00400000 0x00000000
> > [56]: 0x8091122D 0x0040EB48 0x00000000 0x00400600
> > 
> > Reported-by: Rouven Czerwinski <rouven@czerwinskis.de>
> > Tested-by: Timur Kristóf <timur.kristof@gmail.com>
> > Signed-off-by: Ryan Hsu <ryanhsu@codeaurora.org>
> > Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
> 
> Patch applied to ath-current branch of ath.git, thanks.
> 
> 9191fc2a431b ath10k: update the phymode along with bandwidth change
> request

Thank you Kalle.
Does this mean that the patch will get into kernel 4.18?

Best regards,
Tim

Re: [v2] ath10k: Update the phymode along with bandwidth change request

[Timur Kristóf]

On Thu, 2018-06-28 at 09:28 +0000, Kalle Valo wrote:
> Ryan Hsu <ryanhsu@codeaurora.org> wrote:
> 
> > In the case of Station connects to AP with narrower bandwidth at
> > beginning.
> > And later the AP changes the bandwidth to winder bandwidth, the AP
> > will
> > beacon with wider bandwidth IE, eg VHT20->VHT40->VHT80 or VHT40-
> > >VHT80.
> > 
> > Since the supported BANDWIDTH will be limited by the PHYMODE, so
> > while
> > Station receives the bandwidth change request, it will also need to
> > reconfigure the PHYMODE setting to firmware instead of just
> > configuring
> > the BANDWIDTH info, otherwise it'll trigger a firmware crash with
> > non-support bandwidth.
> > 
> > The issue was observed in WLAN.RM.4.4.1-00051-QCARMSWP-1, QCA6174
> > with
> > below scenario:
> > 
> > AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0
> > MHz)
> > disconnect from AP xxx for new auth to yyy
> > RX ReassocResp from xxx (capab=0x1111 status=0 aid=102)
> > associated
> > 
> > ....
> > 
> > AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0
> > MHz)
> > AP xxx changed bandwidth, new config is 5200 MHz, width 3 (5210/0
> > MHz)
> > 
> > ....
> > 
> > firmware register dump:
> > [00]: 0x05030000 0x000015B3 0x00987291 0x00955B31
> > [04]: 0x00987291 0x00060730 0x00000004 0x00000001
> > [08]: 0x004089F0 0x00955A00 0x000A0B00 0x00400000
> > [12]: 0x00000009 0x00000000 0x00952CD0 0x00952CE6
> > [16]: 0x00952CC4 0x0098E25F 0x00000000 0x0091080D
> > [20]: 0x40987291 0x0040E7A8 0x00000000 0x0041EE3C
> > [24]: 0x809ABF05 0x0040E808 0x00000000 0xC0987291
> > [28]: 0x809A650C 0x0040E948 0x0041FE40 0x004345C4
> > [32]: 0x809A5C63 0x0040E988 0x0040E9AC 0x0042D1A8
> > [36]: 0x8091D252 0x0040E9A8 0x00000002 0x00000001
> > [40]: 0x809FDA9D 0x0040EA58 0x0043D554 0x0042D554
> > [44]: 0x809F8B22 0x0040EA78 0x0043D554 0x00000001
> > [48]: 0x80911210 0x0040EAC8 0x00000010 0x004041D0
> > [52]: 0x80911154 0x0040EB28 0x00400000 0x00000000
> > [56]: 0x8091122D 0x0040EB48 0x00000000 0x00400600
> > 
> > Reported-by: Rouven Czerwinski <rouven@czerwinskis.de>
> > Tested-by: Timur Kristóf <timur.kristof@gmail.com>
> > Signed-off-by: Ryan Hsu <ryanhsu@codeaurora.org>
> > Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
> 
> Patch applied to ath-current branch of ath.git, thanks.
> 
> 9191fc2a431b ath10k: update the phymode along with bandwidth change
> request

Thank you Kalle.
Does this mean that the patch will get into kernel 4.18?

Best regards,
Tim


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [v2] ath10k: Update the phymode along with bandwidth change request

[Kalle Valo]

Timur Krist=C3=B3f <timur.kristof@gmail.com> writes:

> On Thu, 2018-06-28 at 09:28 +0000, Kalle Valo wrote:
>> Ryan Hsu <ryanhsu@codeaurora.org> wrote:
>>=20
>> > In the case of Station connects to AP with narrower bandwidth at
>> > beginning.
>> > And later the AP changes the bandwidth to winder bandwidth, the AP
>> > will
>> > beacon with wider bandwidth IE, eg VHT20->VHT40->VHT80 or VHT40-
>> > >VHT80.
>> >=20
>> > Since the supported BANDWIDTH will be limited by the PHYMODE, so
>> > while
>> > Station receives the bandwidth change request, it will also need to
>> > reconfigure the PHYMODE setting to firmware instead of just
>> > configuring
>> > the BANDWIDTH info, otherwise it'll trigger a firmware crash with
>> > non-support bandwidth.
>> >=20
>> > The issue was observed in WLAN.RM.4.4.1-00051-QCARMSWP-1, QCA6174
>> > with
>> > below scenario:
>> >=20
>> > AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0
>> > MHz)
>> > disconnect from AP xxx for new auth to yyy
>> > RX ReassocResp from xxx (capab=3D0x1111 status=3D0 aid=3D102)
>> > associated
>> >=20
>> > ....
>> >=20
>> > AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0
>> > MHz)
>> > AP xxx changed bandwidth, new config is 5200 MHz, width 3 (5210/0
>> > MHz)
>> >=20
>> > ....
>> >=20
>> > firmware register dump:
>> > [00]: 0x05030000 0x000015B3 0x00987291 0x00955B31
>> > [04]: 0x00987291 0x00060730 0x00000004 0x00000001
>> > [08]: 0x004089F0 0x00955A00 0x000A0B00 0x00400000
>> > [12]: 0x00000009 0x00000000 0x00952CD0 0x00952CE6
>> > [16]: 0x00952CC4 0x0098E25F 0x00000000 0x0091080D
>> > [20]: 0x40987291 0x0040E7A8 0x00000000 0x0041EE3C
>> > [24]: 0x809ABF05 0x0040E808 0x00000000 0xC0987291
>> > [28]: 0x809A650C 0x0040E948 0x0041FE40 0x004345C4
>> > [32]: 0x809A5C63 0x0040E988 0x0040E9AC 0x0042D1A8
>> > [36]: 0x8091D252 0x0040E9A8 0x00000002 0x00000001
>> > [40]: 0x809FDA9D 0x0040EA58 0x0043D554 0x0042D554
>> > [44]: 0x809F8B22 0x0040EA78 0x0043D554 0x00000001
>> > [48]: 0x80911210 0x0040EAC8 0x00000010 0x004041D0
>> > [52]: 0x80911154 0x0040EB28 0x00400000 0x00000000
>> > [56]: 0x8091122D 0x0040EB48 0x00000000 0x00400600
>> >=20
>> > Reported-by: Rouven Czerwinski <rouven@czerwinskis.de>
>> > Tested-by: Timur Krist=C3=B3f <timur.kristof@gmail.com>
>> > Signed-off-by: Ryan Hsu <ryanhsu@codeaurora.org>
>> > Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>>=20
>> Patch applied to ath-current branch of ath.git, thanks.
>>=20
>> 9191fc2a431b ath10k: update the phymode along with bandwidth change
>> request
>
> Thank you Kalle.
> Does this mean that the patch will get into kernel 4.18?

Yes, if all goes well. But it might take a week or two before it reaches
Linus' tree as I submit patches to net tree.

--=20
Kalle Valo

Re: [v2] ath10k: Update the phymode along with bandwidth change request

[Kalle Valo]

Timur Kristóf <timur.kristof@gmail.com> writes:

> On Thu, 2018-06-28 at 09:28 +0000, Kalle Valo wrote:
>> Ryan Hsu <ryanhsu@codeaurora.org> wrote:
>> 
>> > In the case of Station connects to AP with narrower bandwidth at
>> > beginning.
>> > And later the AP changes the bandwidth to winder bandwidth, the AP
>> > will
>> > beacon with wider bandwidth IE, eg VHT20->VHT40->VHT80 or VHT40-
>> > >VHT80.
>> > 
>> > Since the supported BANDWIDTH will be limited by the PHYMODE, so
>> > while
>> > Station receives the bandwidth change request, it will also need to
>> > reconfigure the PHYMODE setting to firmware instead of just
>> > configuring
>> > the BANDWIDTH info, otherwise it'll trigger a firmware crash with
>> > non-support bandwidth.
>> > 
>> > The issue was observed in WLAN.RM.4.4.1-00051-QCARMSWP-1, QCA6174
>> > with
>> > below scenario:
>> > 
>> > AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0
>> > MHz)
>> > disconnect from AP xxx for new auth to yyy
>> > RX ReassocResp from xxx (capab=0x1111 status=0 aid=102)
>> > associated
>> > 
>> > ....
>> > 
>> > AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0
>> > MHz)
>> > AP xxx changed bandwidth, new config is 5200 MHz, width 3 (5210/0
>> > MHz)
>> > 
>> > ....
>> > 
>> > firmware register dump:
>> > [00]: 0x05030000 0x000015B3 0x00987291 0x00955B31
>> > [04]: 0x00987291 0x00060730 0x00000004 0x00000001
>> > [08]: 0x004089F0 0x00955A00 0x000A0B00 0x00400000
>> > [12]: 0x00000009 0x00000000 0x00952CD0 0x00952CE6
>> > [16]: 0x00952CC4 0x0098E25F 0x00000000 0x0091080D
>> > [20]: 0x40987291 0x0040E7A8 0x00000000 0x0041EE3C
>> > [24]: 0x809ABF05 0x0040E808 0x00000000 0xC0987291
>> > [28]: 0x809A650C 0x0040E948 0x0041FE40 0x004345C4
>> > [32]: 0x809A5C63 0x0040E988 0x0040E9AC 0x0042D1A8
>> > [36]: 0x8091D252 0x0040E9A8 0x00000002 0x00000001
>> > [40]: 0x809FDA9D 0x0040EA58 0x0043D554 0x0042D554
>> > [44]: 0x809F8B22 0x0040EA78 0x0043D554 0x00000001
>> > [48]: 0x80911210 0x0040EAC8 0x00000010 0x004041D0
>> > [52]: 0x80911154 0x0040EB28 0x00400000 0x00000000
>> > [56]: 0x8091122D 0x0040EB48 0x00000000 0x00400600
>> > 
>> > Reported-by: Rouven Czerwinski <rouven@czerwinskis.de>
>> > Tested-by: Timur Kristóf <timur.kristof@gmail.com>
>> > Signed-off-by: Ryan Hsu <ryanhsu@codeaurora.org>
>> > Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>> 
>> Patch applied to ath-current branch of ath.git, thanks.
>> 
>> 9191fc2a431b ath10k: update the phymode along with bandwidth change
>> request
>
> Thank you Kalle.
> Does this mean that the patch will get into kernel 4.18?

Yes, if all goes well. But it might take a week or two before it reaches
Linus' tree as I submit patches to net tree.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k