Re: [PATCH v2] ath10k: support for multicast rate control

[pradeepc]

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

Re: [PATCH 0/3] Add support for ftm responder configuration

[pradeepc]

On 2018-08-15 02:04, Johannes Berg wrote:

On Tue, 2018-08-14 at 17:30 -0700, Pradeep Kumar Chitrapu wrote:
Currently ftm_responder parameter in hostapd.conf is only used for 
fine
timing measurement (FTM) capability advertisement and actual control 
of
the functionality is with low-level device/driver. This leads to 
confusion
to the user when the capability advertisement is different from actual 
FTM

responder functionality.

For example, FTM responder capability advertisement is set to 
'disabled',
which would imply that AP must not respond to FTM requests, but user 
sees
AP still responding to FTM requests, as the functionality is enabled 
in

the driver.



Hi Johannes,
Thanks for the review..


All you describe above is really a driver bug - it shouldn't have
enabled it to start with?


Sure.. But isn't it justifiable for drivers/firmware choosing to enable
ftm responder by default when there is no way for userspace to specify 
this

parameter?



The patch set allows userspace to configure FTM responder 
functionality

with the addition of new Netlink attribute NL80211_ATTR_FTM_RESPONDER
and also adds extended feature flag for the drivers to advertise the
support. Sending '0' to disable FTM responder would imply AP does not
respond to FTM requests and sending '1' to enable FTM responder would
imply that AP responds to all FTM requests.


This makes sense anyway. Funny you should post this within hours of me
doing the same, basically.

Sorry, I missed your patches before posting mine :)



I have no objection to your approach, though I guess it'd be nice if 
you

could take a look at the statistics I have exposed and see if those
makes sense or if additional ones are desirable for you, and then we 
can

combine the work that way, i.e. have your configuration and our stats?


I looked at the patch you posted and this makes sense. I will try to 
align

ath10k driver changes with your approach.

Thanks
Pradeep


johannes


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

Re: [PATCH 1/3] nl80211: add support to configure FTM responder functionality

[pradeepc]

On 2018-08-15 05:09, Johannes Berg wrote:

On Tue, 2018-08-14 at 17:30 -0700, Pradeep Kumar Chitrapu wrote:


+   int ftm_responder;


bool

+ * @NL80211_ATTR_FTM_RESPONDER: attribute which user-space can 
include in
+ *	%NL80211_CMD_START_AP to enable(1) or disable(0) fine timing 
measurement
+ *	(FTM) responder functionality.  If not set, it means don't care 
and

+ * the device will decide what to use.


Why 0/1 instead of a flag attribute?
Using FLAG attribute may create uncertainty to userspace especially when 
flag attribute
is not set and the driver supports capability, instead of 
assuming/relying on the default

behavior of driver/firmware.



Also, I think you need the attributes (LCI/Civic location)?

johannes


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

Re: [PATCH] ath10k:add support for multicast rate control

[pradeepc]

On 2018-04-12 01:00, Sven Eckelmann wrote:

On Mittwoch, 11. April 2018 21:04:46 CEST Pradeep Kumar Chitrapu wrote:

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

[...]


+   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);
 }




I see two major problems here without checking the actual 
implementation

details:

* hw_value is incorrect for a couple of devices. Some devices use a 
different
  mapping when they receive rates inforamtion (hw_value) then the ones 
you use
  for the mcast/bcast/beacon rate setting. I've handled in my POC patch 
like

  this:

+   if (ath10k_mac_bitrate_is_cck(sband->bitrates[i].bitrate)) {
+   preamble = WMI_RATE_PREAMBLE_CCK;
+
+   /* QCA didn't use the correct rate values for CA99x0
+* and above (ath10k_g_rates_rev2)
+*/
+   switch (sband->bitrates[i].bitrate) {
+   case 10:
+   hw_value = ATH10K_HW_RATE_CCK_LP_1M;
+   break;
+   case 20:
+   hw_value = ATH10K_HW_RATE_CCK_LP_2M;
+   break;
+   case 55:
+   hw_value = ATH10K_HW_RATE_CCK_LP_5_5M;
+   break;
+   case 110:
+   hw_value = ATH10K_HW_RATE_CCK_LP_11M;
+   break;
+   }
+   } else {
+   preamble = WMI_RATE_PREAMBLE_OFDM;
+   }



Isn't this already fixed in https://patchwork.kernel.org/patch/9150145/ 
?



* bcast + mcast (+ mgmt) have to be set separately


Can you please let me know why this would be necessary?
Although I see minstrel rate control is currently seems using the 
mcast_rate
setting to set MGMT/BCAST/MCAST rates, will this not be misleading to 
user

passed value with 'iw set mcast_rate' for MGMT traffic as well?



I have attached my POC patch (which I was using for packet loss based 
mesh
metrics) and to work around (using debugfs) the silly mgmt vs. 
mcast/bcast

settings of the QCA fw for APs.

Many of the information came from Ben Greears ath10k-ct driver
https://github.com/greearb/ath10k-ct

Kind regards,
Sven


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