* [PATCH v2] ath10k: support for multicast rate control [not found] <cebad8674a69761e32a1a882de9a1259657c65d4> @ 2018-05-08 1:34 ` Pradeep Kumar Chitrapu 0 siblings, 0 replies; 14+ messages in thread From: Pradeep Kumar Chitrapu @ 2018-05-08 1:34 UTC (permalink / raw) To: ath10k; +Cc: linux-wireless, 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 <pradeepc@codeaurora.org> --- 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(-) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 3d7119a..70a0563 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -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; -- 1.9.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH v2] ath10k: support for multicast rate control @ 2018-05-08 1:34 ` Pradeep Kumar Chitrapu 0 siblings, 0 replies; 14+ messages in thread From: Pradeep Kumar Chitrapu @ 2018-05-08 1:34 UTC (permalink / raw) To: ath10k; +Cc: Pradeep Kumar Chitrapu, linux-wireless 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 <pradeepc@codeaurora.org> --- 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(-) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 3d7119a..70a0563 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -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; -- 1.9.1 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH v2] ath10k: support for multicast rate control 2018-05-08 1:34 ` Pradeep Kumar Chitrapu @ 2018-05-09 6:15 ` Sven Eckelmann -1 siblings, 0 replies; 14+ messages in thread From: Sven Eckelmann @ 2018-05-09 6:15 UTC (permalink / raw) To: Pradeep Kumar Chitrapu; +Cc: ath10k, linux-wireless [-- Attachment #1: Type: text/plain, Size: 898 bytes --] 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. > > Tested on QCA9984 with firmware ver 10.4-3.6-00104 > > Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> > --- > 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 [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2] ath10k: support for multicast rate control @ 2018-05-09 6:15 ` Sven Eckelmann 0 siblings, 0 replies; 14+ messages in thread From: Sven Eckelmann @ 2018-05-09 6:15 UTC (permalink / raw) To: Pradeep Kumar Chitrapu; +Cc: linux-wireless, ath10k [-- Attachment #1.1: Type: text/plain, Size: 898 bytes --] 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. > > Tested on QCA9984 with firmware ver 10.4-3.6-00104 > > Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> > --- > 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 [-- Attachment #1.2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 146 bytes --] _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2] ath10k: support for multicast rate control 2018-05-09 6:15 ` Sven Eckelmann @ 2018-05-09 6:57 ` Sebastian Gottschall -1 siblings, 0 replies; 14+ messages in thread From: Sebastian Gottschall @ 2018-05-09 6:57 UTC (permalink / raw) To: Sven Eckelmann, Pradeep Kumar Chitrapu; +Cc: ath10k, linux-wireless Am 09.05.2018 um 08:15 schrieb Sven Eckelmann: > 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. >> >> Tested on QCA9984 with firmware ver 10.4-3.6-00104 >> >> Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> >> --- >> 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. > 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 > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2] ath10k: support for multicast rate control @ 2018-05-09 6:57 ` Sebastian Gottschall 0 siblings, 0 replies; 14+ messages in thread From: Sebastian Gottschall @ 2018-05-09 6:57 UTC (permalink / raw) To: Sven Eckelmann, Pradeep Kumar Chitrapu; +Cc: linux-wireless, ath10k Am 09.05.2018 um 08:15 schrieb Sven Eckelmann: > 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. >> >> Tested on QCA9984 with firmware ver 10.4-3.6-00104 >> >> Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> >> --- >> 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. > 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 > _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2] ath10k: support for multicast rate control 2018-05-09 6:57 ` Sebastian Gottschall @ 2018-05-09 14:31 ` Ben Greear -1 siblings, 0 replies; 14+ messages in thread From: Ben Greear @ 2018-05-09 14:31 UTC (permalink / raw) To: Sebastian Gottschall, Sven Eckelmann, Pradeep Kumar Chitrapu Cc: ath10k, linux-wireless On 05/08/2018 11:57 PM, Sebastian Gottschall wrote: > > > Am 09.05.2018 um 08:15 schrieb Sven Eckelmann: >> 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. >>> >>> Tested on QCA9984 with firmware ver 10.4-3.6-00104 >>> Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> >>> --- >>> 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. > 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 -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2] ath10k: support for multicast rate control @ 2018-05-09 14:31 ` Ben Greear 0 siblings, 0 replies; 14+ messages in thread From: Ben Greear @ 2018-05-09 14:31 UTC (permalink / raw) To: Sebastian Gottschall, Sven Eckelmann, Pradeep Kumar Chitrapu Cc: linux-wireless, ath10k On 05/08/2018 11:57 PM, Sebastian Gottschall wrote: > > > Am 09.05.2018 um 08:15 schrieb Sven Eckelmann: >> 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. >>> >>> Tested on QCA9984 with firmware ver 10.4-3.6-00104 >>> Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> >>> --- >>> 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. > 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 -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2] ath10k: support for multicast rate control 2018-05-09 14:31 ` Ben Greear @ 2018-05-10 2:46 ` pradeepc -1 siblings, 0 replies; 14+ messages in thread From: pradeepc @ 2018-05-10 2:46 UTC (permalink / raw) To: Sven Eckelmann; +Cc: Sebastian Gottschall, Ben Greear, ath10k, linux-wireless On 2018-05-09 07:31, Ben Greear wrote: > On 05/08/2018 11:57 PM, Sebastian Gottschall wrote: >> >> >> Am 09.05.2018 um 08:15 schrieb Sven Eckelmann: >>> 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. >>>> >>>> Tested on QCA9984 with firmware ver 10.4-3.6-00104 >>>> Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> >>>> --- >>>> 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. > 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 >> 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2] ath10k: support for multicast rate control @ 2018-05-10 2:46 ` pradeepc 0 siblings, 0 replies; 14+ messages in thread From: pradeepc @ 2018-05-10 2:46 UTC (permalink / raw) To: Sven Eckelmann; +Cc: Ben Greear, linux-wireless, ath10k, Sebastian Gottschall On 2018-05-09 07:31, Ben Greear wrote: > On 05/08/2018 11:57 PM, Sebastian Gottschall wrote: >> >> >> Am 09.05.2018 um 08:15 schrieb Sven Eckelmann: >>> 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. >>>> >>>> Tested on QCA9984 with firmware ver 10.4-3.6-00104 >>>> Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> >>>> --- >>>> 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. > 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 >> 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 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [v2] ath10k: support for multicast rate control 2018-05-08 1:34 ` Pradeep Kumar Chitrapu (?) (?) @ 2018-06-14 14:46 ` Kalle Valo -1 siblings, 0 replies; 14+ messages in thread From: Kalle Valo @ 2018-06-14 14:46 UTC (permalink / raw) To: Pradeep Kumar Chitrapu; +Cc: linux-wireless, ath10k Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> 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. > > Tested on QCA9984 with firmware ver 10.4-3.6-00104 > > Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> > Signed-off-by: Kalle Valo <kvalo@codeaurora.org> 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. -- https://patchwork.kernel.org/patch/10385043/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [v2] ath10k: support for multicast rate control 2018-05-08 1:34 ` Pradeep Kumar Chitrapu ` (2 preceding siblings ...) (?) @ 2018-06-14 14:46 ` Kalle Valo -1 siblings, 0 replies; 14+ messages in thread From: Kalle Valo @ 2018-06-14 14:46 UTC (permalink / raw) To: Pradeep Kumar Chitrapu; +Cc: ath10k, linux-wireless, Pradeep Kumar Chitrapu Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> 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. > > Tested on QCA9984 with firmware ver 10.4-3.6-00104 > > Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> > Signed-off-by: Kalle Valo <kvalo@codeaurora.org> 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. -- https://patchwork.kernel.org/patch/10385043/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2] ath10k: support for multicast rate control 2018-05-08 1:34 ` Pradeep Kumar Chitrapu ` (3 preceding siblings ...) (?) @ 2018-07-30 17:47 ` Kalle Valo -1 siblings, 0 replies; 14+ messages in thread From: Kalle Valo @ 2018-07-30 17:47 UTC (permalink / raw) To: Pradeep Kumar Chitrapu; +Cc: ath10k, linux-wireless, Pradeep Kumar Chitrapu Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> wrote: > 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 <pradeepc@codeaurora.org> > Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Patch applied to ath-next branch of ath.git, thanks. cd93b83ad927 ath10k: support for multicast rate control -- https://patchwork.kernel.org/patch/10385043/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2] ath10k: support for multicast rate control 2018-05-08 1:34 ` Pradeep Kumar Chitrapu ` (4 preceding siblings ...) (?) @ 2018-07-30 17:47 ` Kalle Valo -1 siblings, 0 replies; 14+ messages in thread From: Kalle Valo @ 2018-07-30 17:47 UTC (permalink / raw) To: Pradeep Kumar Chitrapu; +Cc: linux-wireless, ath10k Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> wrote: > 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 <pradeepc@codeaurora.org> > Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Patch applied to ath-next branch of ath.git, thanks. cd93b83ad927 ath10k: support for multicast rate control -- https://patchwork.kernel.org/patch/10385043/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2018-07-30 19:23 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <cebad8674a69761e32a1a882de9a1259657c65d4> 2018-05-08 1:34 ` [PATCH v2] ath10k: support for multicast rate control Pradeep Kumar Chitrapu 2018-05-08 1:34 ` Pradeep Kumar Chitrapu 2018-05-09 6:15 ` Sven Eckelmann 2018-05-09 6:15 ` Sven Eckelmann 2018-05-09 6:57 ` Sebastian Gottschall 2018-05-09 6:57 ` Sebastian Gottschall 2018-05-09 14:31 ` Ben Greear 2018-05-09 14:31 ` Ben Greear 2018-05-10 2:46 ` pradeepc 2018-05-10 2:46 ` pradeepc 2018-06-14 14:46 ` [v2] " Kalle Valo 2018-06-14 14:46 ` Kalle Valo 2018-07-30 17:47 ` [PATCH v2] " Kalle Valo 2018-07-30 17:47 ` Kalle Valo
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.