[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87woe5aehr.fsf@kamboji.qca.qualcomm.com>
Date: Wed, 18 Sep 2019 17:03:12 +0300
From: Kalle Valo <kvalo@...eaurora.org>
To: Brian Norris <briannorris@...omium.org>
Cc: Wen Gong <wgong@...eaurora.org>,
linux-wireless <linux-wireless@...r.kernel.org>,
Linux Kernel <linux-kernel@...r.kernel.org>,
ath10k@...ts.infradead.org
Subject: Re: [PATCH v3] ath10k: support NET_DETECT WoWLAN feature
Brian Norris <briannorris@...omium.org> writes:
> Since Wen has once again suggested I use this patch in other forums,
> I'll ping here to note:
>
> On Wed, Nov 14, 2018 at 2:59 PM Brian Norris <briannorris@...omium.org> wrote:
>> You've introduced a regression in 4.20-rc1:
>
> This regression still survives in the latest tree. Is it fair to just
> submit a revert?
Your description about the problem from an earlier email:
"It seems like youre enabling SCHED_SCAN support? But you're not
adding the NL80211_FEATURE_SCHED_SCAN_RANDOM_MAC_ADDR feature flag.
So it puts us in a tough place on using randomization -- we either
can't trust the FEATURE flags, or else we can't use both SCHED_SCAN
and scan randomization."
So essentially the problem is that with firmwares supporting both
WMI_SERVICE_NLO and WMI_SERVICE_SPOOF_MAC_SUPPORT ath10k enables
NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR, but
NL80211_FEATURE_SCHED_SCAN_RANDOM_MAC_ADDR is not enabled which is
inconsistent from user space point of view. Is my understanding correct?
Wen, can you enable NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR? Does firmware
support that?
If that's not possible, one workaround might to be to not enable
NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR if firmware supports
WMI_SERVICE_NLO, but of course that would suck big time.
Here's the full context in case someone is interested:
https://patchwork.kernel.org/patch/10567005/
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Powered by blists - more mailing lists