| Message ID | 20180710094448.13201-1-sven.eckelmann@openmesh.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
Sven Eckelmann <sven.eckelmann@openmesh.com> writes: > The QCA4019 hw1.0 firmware 10.4-3.2.1-00050 and 10.4-3.5.3-00053 (and most > likely all other) seem to ignore the WMI_CHAN_FLAG_DFS flag during the > scan. This results in transmission (probe requests) on channels which are > not "available" for transmissions. > > Since the firmware is closed source and nothing can be done from our side > to fix the problem in it, the driver has to work around this problem. The > WMI_CHAN_FLAG_PASSIVE seems to be interpreted by the firmware to not > scan actively on a channel unless an AP was detected on it. Simple probe > requests will then be transmitted by the STA on the channel. > > ath10k must therefore also use this flag when it queues a radar channel for > scanning. This should reduce the chance of an active scan when the channel > might be "unusable" for transmissions. > > Fixes: e8a50f8ba44b ("ath10k: introduce DFS implementation") > Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> You didn't CC linux-wireless so I don't see this in patchwork. Can you resend, please?
On Donnerstag, 26. Juli 2018 16:47:00 CEST Kalle Valo wrote: [...] > > Fixes: e8a50f8ba44b ("ath10k: introduce DFS implementation") > > Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> > > You didn't CC linux-wireless so I don't see this in patchwork. Can you > resend, please? In that case, you should maybe think about stopping the ath10k patchwork: https://patchwork.kernel.org/patch/10516691/ Kind regards, Sven
Sven Eckelmann <sven.eckelmann@openmesh.com> writes: > On Donnerstag, 26. Juli 2018 16:47:00 CEST Kalle Valo wrote: > [...] >> > Fixes: e8a50f8ba44b ("ath10k: introduce DFS implementation") >> > Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> >> >> You didn't CC linux-wireless so I don't see this in patchwork. Can you >> resend, please? > > In that case, you should maybe think about stopping the ath10k patchwork: > https://patchwork.kernel.org/patch/10516691/ Sure, but how to do that? I can't find any functionality from the UI. And I don't want to fully delete it as lots of old emails refer to it.
On Donnerstag, 26. Juli 2018 17:22:31 CEST Kalle Valo wrote: > Sven Eckelmann <sven.eckelmann@openmesh.com> writes: > > > On Donnerstag, 26. Juli 2018 16:47:00 CEST Kalle Valo wrote: > > [...] > >> > Fixes: e8a50f8ba44b ("ath10k: introduce DFS implementation") > >> > Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> > >> > >> You didn't CC linux-wireless so I don't see this in patchwork. Can you > >> resend, please? > > > > In that case, you should maybe think about stopping the ath10k patchwork: > > https://patchwork.kernel.org/patch/10516691/ > > Sure, but how to do that? I can't find any functionality from the UI. > And I don't want to fully delete it as lots of old emails refer to it. Yes, this is a problem. Kind regards, Sven
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 541bc1c4b2f7..ad975beae6dc 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -3085,6 +3085,13 @@ static int ath10k_update_channel_list(struct ath10k *ar) passive = channel->flags & IEEE80211_CHAN_NO_IR; ch->passive = passive; + /* the firmware is ignoring the "radar" flag of the + * channel and is scanning actively using Probe Requests + * on "Radar detection"/DFS channels which are not + * marked as "available" + */ + ch->passive |= ch->chan_radar; + ch->freq = channel->center_freq; ch->band_center_freq1 = channel->center_freq; ch->min_power = 0;
The QCA4019 hw1.0 firmware 10.4-3.2.1-00050 and 10.4-3.5.3-00053 (and most likely all other) seem to ignore the WMI_CHAN_FLAG_DFS flag during the scan. This results in transmission (probe requests) on channels which are not "available" for transmissions. Since the firmware is closed source and nothing can be done from our side to fix the problem in it, the driver has to work around this problem. The WMI_CHAN_FLAG_PASSIVE seems to be interpreted by the firmware to not scan actively on a channel unless an AP was detected on it. Simple probe requests will then be transmitted by the STA on the channel. ath10k must therefore also use this flag when it queues a radar channel for scanning. This should reduce the chance of an active scan when the channel might be "unusable" for transmissions. Fixes: e8a50f8ba44b ("ath10k: introduce DFS implementation") Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> --- Cc: Simon Wunderlich <simon.wunderlich@openmesh.com> Cc: Marek Puzyniak <marek.puzyniak@tieto.com> --- drivers/net/wireless/ath/ath10k/mac.c | 7 +++++++ 1 file changed, 7 insertions(+)