ath10k: support for multicast rate control

PATCH In review Pradeep Kumar Chitrapu 5 participants 9 messages May 8, 2018 – Jul 30, 2018 1 message not in the archive Qualcomm Atheros ATH10K wireless driver

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): cebad8674a69761e32a1a882de9a1259657c65d4

Pradeep Kumar Chitrapu

author

2018-05-08 01:34 UTC #1 lore raw

PATCH v2 1/1 ath10k: support for multicast rate control

Issues wmi command to firmwre when multicast rate change is received with the new BSS_CHANGED_MCAST_RATE flag.
Also fixes the incorrect fixed_rate setting for CCK rates which got introduced with addition of ath10k_rates_rev2 enum.

Tested on QCA9984 with firmware ver 10.4-3.6-00104

Signed-off-by Pradeep Kumar Chitrapu <[email protected]>

---
v2:
- fixed the CCK rates setting for mcast_rate and fixed_rate paths.
- set broadcast rate along with multicast rate setting.

 drivers/net/wireless/ath/ath10k/mac.c | 54 ++++++++++++++++++++++++++++++++---
 1 file changed, 50 insertions(+), 4 deletions(-)

drivers/net/wireless/ath/ath10k/mac.c +50 -4

index 3d7119a..70a0563 100644
@@ -101,6 +101,8 @@
 #define ath10k_g_rates_rev2 (ath10k_rates_rev2 + 0)
 #define ath10k_g_rates_rev2_size (ARRAY_SIZE(ath10k_rates_rev2))
 
+#define ath10k_wmi_legacy_rates ath10k_rates
+
 static bool ath10k_mac_bitrate_is_cck(int bitrate)
 {
 	switch (bitrate) {

@@ -5426,8 +5428,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 cfg80211_chan_def def;
 	u32 vdev_param, pdev_param, slottime, preamble;
+	u16 bitrate, hw_value;
+	u8 rate;
+	int rateidx, ret = 0;
+	enum nl80211_band band;
 
 	mutex_lock(&ar->conf_mutex);

@@ -5595,6 +5601,44 @@ 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, &def))) {
+		band = def.chan->band;
+		rateidx = vif->bss_conf.mcast_rate[band] - 1;
+
+		if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY)
+			rateidx += ATH10K_MAC_FIRST_OFDM_RATE_IDX;
+
+		bitrate = ath10k_wmi_legacy_rates[rateidx].bitrate;
+		hw_value = ath10k_wmi_legacy_rates[rateidx].hw_value;
+		if (ath10k_mac_bitrate_is_cck(bitrate))
+			preamble = WMI_RATE_PREAMBLE_CCK;
+		else
+			preamble = WMI_RATE_PREAMBLE_OFDM;
+
+		rate = ATH10K_HW_RATECODE(hw_value, 0, preamble);
+
+		ath10k_dbg(ar, ATH10K_DBG_MAC,
+			   "mac vdev %d mcast_rate %x\n",
+			   arvif->vdev_id, rate);
+
+		vdev_param = ar->wmi.vdev_param->mcast_data_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);
+
+		vdev_param = ar->wmi.vdev_param->bcast_data_rate;
+		ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id,
+						vdev_param, rate);
+		if (ret)
+			ath10k_warn(ar,
+				    "failed to set bcast rate on vdev %i: %d\n",
+				    arvif->vdev_id,  ret);
+	}
+
 	mutex_unlock(&ar->conf_mutex);
 }

@@ -6895,7 +6939,6 @@ ath10k_mac_bitrate_mask_get_single_rate(
 					const struct cfg80211_bitrate_mask *mask,
 					u8 *rate, u8 *nss)
 {
-	struct ieee80211_supported_band *sband = &ar->mac.sbands[band];
 	int rate_idx;
 	int i;
 	u16 bitrate;

@@ -6905,8 +6948,11 @@ ath10k_mac_bitrate_mask_get_single_rate(
 	if (hweight32(mask->control[band].legacy) == 1) {
 		rate_idx = ffs(mask->control[band].legacy) - 1;
 
-		hw_rate = sband->bitrates[rate_idx].hw_value;
-		bitrate = sband->bitrates[rate_idx].bitrate;
+		if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY)
+			rate_idx += ATH10K_MAC_FIRST_OFDM_RATE_IDX;
+
+		hw_rate = ath10k_wmi_legacy_rates[rate_idx].hw_value;
+		bitrate = ath10k_wmi_legacy_rates[rate_idx].bitrate;
 
 		if (ath10k_mac_bitrate_is_cck(bitrate))
 			preamble = WMI_RATE_PREAMBLE_CCK;

Signature · 1 line

1.9.1

Sven Eckelmann

2018-05-09 06:15 UTC #2 lore raw

Quoted 5 lines · On Montag, 7. Mai 2018 18:34:51 CEST Pradeep Kumar Chitrapu wrote:

Issues wmi command to firmwre when multicast rate change is received with the new BSS_CHANGED_MCAST_RATE flag.
Also fixes the incorrect fixed_rate setting for CCK rates which got introduced with addition of ath10k_rates_rev2 enum.

Quoted 7 lines

Tested on QCA9984 with firmware ver 10.4-3.6-00104
Signed-off-by Pradeep Kumar Chitrapu <[email protected]>
---
v2:
- fixed the CCK rates setting for mcast_rate and fixed_rate paths.
- set broadcast rate along with multicast rate setting.

These things are only modified in ath10k_bss_info_changed and not saved/ restored. What happens when the HW needs to be reset (there are are couple of firmware crashes which can be seen in the wild and are handled by ath10k)? I would guess that not all of them automatically cause an .bss_info_changed.

Kind regards,
Sven

Sebastian Gottschall

2018-05-09 06:57 UTC #3 lore raw

Am 09.05.2018 um 08:15 schrieb Sven Eckelmann:

Quoted 13 lines · On Montag, 7. Mai 2018 18:34:51 CEST Pradeep Kumar Chitrapu wrote:

Quoted 5 lines
Issues wmi command to firmwre when multicast rate change is received with the new BSS_CHANGED_MCAST_RATE flag.
Also fixes the incorrect fixed_rate setting for CCK rates which got introduced with addition of ath10k_rates_rev2 enum.
Quoted 7 lines
Tested on QCA9984 with firmware ver 10.4-3.6-00104
Signed-off-by Pradeep Kumar Chitrapu <[email protected]>
---
v2:
- fixed the CCK rates setting for mcast_rate and fixed_rate paths.
- set broadcast rate along with multicast rate setting.

Quoted 5 lines

These things are only modified in ath10k_bss_info_changed and not saved/ restored. What happens when the HW needs to be reset (there are are couple of firmware crashes which can be seen in the wild and are handled by ath10k)? I would guess that not all of them automatically cause an .bss_info_changed.

i have never seen a card properly recovering after a firmware crash, all firmware crashes i have seen
are caused by bugs in firmware handling or the firmware itself. so if it recovers it crashes immediatly again
ending in a endless crashloop since the cause for the crash hasnt been fixed. they are often triggered by extern clients for instance which still remain in the field. i think firmware crashes should not be hidden by recovering. this would also force users to report problems more frequently, than they do since they dont even take notice of such problems

Sebastian

Quoted 1 line

Ben Greear

2018-05-09 14:32 UTC #4 lore raw

Quoted 19 lines · Sebastian Gottschall

Am 09.05.2018 um 08:15 schrieb Sven Eckelmann:
Quoted 16 lines · On Montag, 7. Mai 2018 18:34:51 CEST Pradeep Kumar Chitrapu wrote:
Quoted 11 lines
Issues wmi command to firmwre when multicast rate change is received with the new BSS_CHANGED_MCAST_RATE flag.
Also fixes the incorrect fixed_rate setting for CCK rates which got introduced with addition of ath10k_rates_rev2 enum.
Tested on QCA9984 with firmware ver 10.4-3.6-00104
Signed-off-by Pradeep Kumar Chitrapu <[email protected]>
---
v2:
- fixed the CCK rates setting for mcast_rate and fixed_rate paths.
- set broadcast rate along with multicast rate setting.
These things are only modified in ath10k_bss_info_changed and not saved/ restored. What happens when the HW needs to be reset (there are are couple of firmware crashes which can be seen in the wild and are handled by ath10k)? I would guess that not all of them automatically cause an .bss_info_changed.

Yes, that sounds like a good idea to me.

Quoted 5 lines

i have never seen a card properly recovering after a firmware crash, all firmware crashes i have seen
are caused by bugs in firmware handling or the firmware itself. so if it recovers it crashes immediatly again
ending in a endless crashloop since the cause for the crash hasnt been fixed. they are often triggered by extern clients for instance which still remain in the field. i think firmware crashes should not be hidden by recovering. this would also force users to report problems more frequently, than they do since they dont even take notice of such problems

We see recovery work often. If you see repeatable crashes, post them to the list.

Do you know of any particular external clients that cause these crashes?

Thanks,
Ben

Signature · 2 lines

Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com

[email protected]

author

2018-05-10 02:46 UTC #5 lore raw

Quoted 16 lines · Ben Greear

Quoted 15 lines · Sebastian Gottschall
Am 09.05.2018 um 08:15 schrieb Sven Eckelmann:
Quoted 12 lines · On Montag, 7. Mai 2018 18:34:51 CEST Pradeep Kumar Chitrapu wrote:
Quoted 11 lines
Issues wmi command to firmwre when multicast rate change is received with the new BSS_CHANGED_MCAST_RATE flag.
Also fixes the incorrect fixed_rate setting for CCK rates which got introduced with addition of ath10k_rates_rev2 enum.
Tested on QCA9984 with firmware ver 10.4-3.6-00104
Signed-off-by Pradeep Kumar Chitrapu <[email protected]>
---
v2:
- fixed the CCK rates setting for mcast_rate and fixed_rate paths.
- set broadcast rate along with multicast rate setting.

Quoted 7 lines

Quoted 4 lines
Quoted 4 lines
These things are only modified in ath10k_bss_info_changed and not saved/ restored. What happens when the HW needs to be reset (there are are couple of firmware crashes which can be seen in the wild and are handled by ath10k)? I would guess that not all of them automatically cause an .bss_info_changed.
Yes, that sounds like a good idea to me.

Hi Sven, Thanks for the review.
In case of HW reset, I see ieee80211_reconfig triggers bss_info changed and BSS_CHANGED_MCAST_RATE is already being set in this function.
(https://patchwork.kernel.org/patch/10302175/). isn't this sufficient for the re-configuring the mcast rate? Please let me know if I am missing something.

Thanks
Pradeep

Quoted 13 lines

Quoted 5 lines
i have never seen a card properly recovering after a firmware crash, all firmware crashes i have seen
are caused by bugs in firmware handling or the firmware itself. so if it recovers it crashes immediatly again
ending in a endless crashloop since the cause for the crash hasnt been fixed. they are often triggered by extern clients for instance which still remain in the field. i think firmware crashes should not be hidden by recovering. this would also force users to report problems more frequently, than they do since they dont even take notice of such problems
We see recovery work often. If you see repeatable crashes, post them to the list.
Do you know of any particular external clients that cause these crashes?
Thanks,
Ben

Kalle Valo

2018-06-14 14:46 UTC #6 lore raw

In reply to Pradeep Kumar Chitrapu

Quoted 9 lines · Pradeep Kumar Chitrapu

Issues wmi command to firmwre when multicast rate change is received with the new BSS_CHANGED_MCAST_RATE flag.
Also fixes the incorrect fixed_rate setting for CCK rates which got introduced with addition of ath10k_rates_rev2 enum.
Tested on QCA9984 with firmware ver 10.4-3.6-00104
Signed-off-by Pradeep Kumar Chitrapu <[email protected]>
Signed-off-by Kalle Valo <[email protected]>

ath10k-check found some whitespace issues:

drivers/net/wireless/ath/ath10k/mac.c:6110: Alignment should match open parenthesis drivers/net/wireless/ath/ath10k/mac.c:6113: Alignment should match open parenthesis drivers/net/wireless/ath/ath10k/mac.c:6116: Alignment should match open parenthesis

I fixed those in the pending branch.

Signature · 3 lines

https://patchwork.kernel.org/patch/10385043/

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

Kalle Valo

2018-06-14 14:47 UTC #7 lore raw

In reply to Pradeep Kumar Chitrapu

Quoted 9 lines · Pradeep Kumar Chitrapu

Issues wmi command to firmwre when multicast rate change is received with the new BSS_CHANGED_MCAST_RATE flag.
Also fixes the incorrect fixed_rate setting for CCK rates which got introduced with addition of ath10k_rates_rev2 enum.
Tested on QCA9984 with firmware ver 10.4-3.6-00104
Signed-off-by Pradeep Kumar Chitrapu <[email protected]>
Signed-off-by Kalle Valo <[email protected]>

ath10k-check found some whitespace issues:

I fixed those in the pending branch.

Signature · 9 lines

https://patchwork.kernel.org/patch/10385043/

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


_______________________________________________
ath10k mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k

Kalle Valo

2018-07-30 17:47 UTC #8 lore raw

In reply to Pradeep Kumar Chitrapu

Quoted 8 lines · Pradeep Kumar Chitrapu

Issues a wmi command to firmware when multicast rate change is received with the new BSS_CHANGED_MCAST_RATE flag. Also fixes the incorrect fixed_rate setting for CCK rates which got introduced with addition of ath10k_rates_rev2 enum.
Tested on QCA9984 with firmware ver 10.4-3.6-00104
Signed-off-by Pradeep Kumar Chitrapu <[email protected]>
Signed-off-by Kalle Valo <[email protected]>

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

cd93b83ad927 ath10k: support for multicast rate control

Signature · 9 lines

https://patchwork.kernel.org/patch/10385043/

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


_______________________________________________
ath10k mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k

Kalle Valo

2018-07-30 19:23 UTC #9 lore raw

In reply to Pradeep Kumar Chitrapu

Quoted 8 lines · Pradeep Kumar Chitrapu

Issues a wmi command to firmware when multicast rate change is received with the new BSS_CHANGED_MCAST_RATE flag. Also fixes the incorrect fixed_rate setting for CCK rates which got introduced with addition of ath10k_rates_rev2 enum.
Tested on QCA9984 with firmware ver 10.4-3.6-00104
Signed-off-by Pradeep Kumar Chitrapu <[email protected]>
Signed-off-by Kalle Valo <[email protected]>

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

cd93b83ad927 ath10k: support for multicast rate control

Signature · 3 lines

https://patchwork.kernel.org/patch/10385043/

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