From: Kalle Valo <kvalo@codeaurora.org>
To: Brian Norris <briannorris@chromium.org>
Cc: linux-wireless <linux-wireless@vger.kernel.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
ath10k@lists.infradead.org, Wen Gong <wgong@codeaurora.org>
Subject: Re: [PATCH v3] ath10k: support NET_DETECT WoWLAN feature
Date: Wed, 18 Sep 2019 17:03:12 +0300 [thread overview]
Message-ID: <87woe5aehr.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <CA+ASDXMh7vdfkA5jtJqWEU-g-4Ta5Xvy046zujyASZcESCGhAQ@mail.gmail.com> (Brian Norris's message of "Tue, 17 Sep 2019 09:32:52 -0700")
Brian Norris <briannorris@chromium.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@chromium.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
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@codeaurora.org>
To: Brian Norris <briannorris@chromium.org>
Cc: Wen Gong <wgong@codeaurora.org>,
linux-wireless <linux-wireless@vger.kernel.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
ath10k@lists.infradead.org
Subject: Re: [PATCH v3] ath10k: support NET_DETECT WoWLAN feature
Date: Wed, 18 Sep 2019 17:03:12 +0300 [thread overview]
Message-ID: <87woe5aehr.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <CA+ASDXMh7vdfkA5jtJqWEU-g-4Ta5Xvy046zujyASZcESCGhAQ@mail.gmail.com> (Brian Norris's message of "Tue, 17 Sep 2019 09:32:52 -0700")
Brian Norris <briannorris@chromium.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@chromium.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
next prev parent reply other threads:[~2019-09-18 14:03 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-16 6:48 [PATCH v3] ath10k: support NET_DETECT WoWLAN feature Wen Gong
2018-08-16 6:48 ` Wen Gong
2018-09-04 9:15 ` Kalle Valo
2018-09-04 9:15 ` Kalle Valo
2018-09-04 11:18 ` [EXTERNAL] " Wen Gong
2018-09-04 11:18 ` Wen Gong
2018-09-04 11:43 ` Kalle Valo
2018-09-04 11:43 ` Kalle Valo
2018-09-05 2:51 ` Wen Gong
2018-09-05 2:51 ` Wen Gong
2018-10-12 15:37 ` Kalle Valo
2018-10-12 15:37 ` Kalle Valo
2018-10-13 17:18 ` Kalle Valo
2018-10-13 17:18 ` Kalle Valo
2018-11-14 22:59 ` Brian Norris
2018-11-14 22:59 ` Brian Norris
2019-09-17 16:32 ` Brian Norris
2019-09-17 16:32 ` Brian Norris
2019-09-18 14:03 ` Kalle Valo [this message]
2019-09-18 14:03 ` Kalle Valo
2019-09-20 0:52 ` Brian Norris
2019-09-20 0:52 ` Brian Norris
2019-09-20 2:55 ` Wen Gong
2019-09-20 2:55 ` Wen Gong
2019-09-20 7:32 ` Kalle Valo
2019-09-20 7:32 ` Kalle Valo
2019-09-20 9:37 ` Wen Gong
2019-09-20 9:37 ` Wen Gong
2019-10-03 0:58 ` Brian Norris
2019-10-03 0:58 ` Brian Norris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87woe5aehr.fsf@kamboji.qca.qualcomm.com \
--to=kvalo@codeaurora.org \
--cc=ath10k@lists.infradead.org \
--cc=briannorris@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=wgong@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.