Hi, > -----Original Message----- > From: Manikanta Pubbisetty <quic_mpubbise@xxxxxxxxxxx> > Sent: Monday, February 27, 2023 06:24 > To: Johannes Berg <johannes@xxxxxxxxxxxxxxxx>; James Prestwood > <prestwoj@xxxxxxxxx>; Marcel Holtmann <marcel@xxxxxxxxxxxx> > Cc: ath11k@xxxxxxxxxxxxxxxxxxx; linux-wireless@xxxxxxxxxxxxxxx; Peer, Ilan > <ilan.peer@xxxxxxxxx> > Subject: Re: [PATCH] wifi: ath11k: Optimize 6 GHz scan time > > On 2/24/2023 3:45 PM, Johannes Berg wrote: > > On Fri, 2023-02-24 at 15:38 +0530, Manikanta Pubbisetty wrote: > >> On 1/10/2023 10:35 PM, James Prestwood wrote: > >>> On Tue, 2023-01-10 at 10:49 +0530, Manikanta Pubbisetty wrote: > >>>> On 12/29/2022 2:52 AM, James Prestwood wrote: > >>>>> Hi Manikanta, > >>>>>> By the way, userspace itself selects the frequencies to scan, not > >>>>>> the driver. > >>>>>> > >>>>>> If we see the split scan implementation in cfg80211, this is the > >>>>>> how it is implemented. If NL80211_SCAN_FLAG_COLOCATED_6GHZ > is > >>>>>> set, it selects all PSC channels and those non-PSC channels where > >>>>>> RNR IE information is found in the legacy scan results. If this > >>>>>> flag is not set, all channels in 6 GHz are included in the scan > >>>>>> freq list. It is upto userspace to decide what it wants. > >>>>> > >>>>> > >>>>> This isn't your problem, but it needs to be said: > >>>>> > >>>>> The nl80211 docs need and update to reflect this behavior (or > >>>>> remove the PSC logic). IMO this is really weird that the kernel > >>>>> selects PSC's based on the co-located flag. The docs don't > >>>>> describe this behavior and the flag's name is misleading (its not > >>>>> SCAN_FLAG_COLOCATED_AND_PSC_6GHZ) :) > >>>>> > >>>> > >>>> Sorry for the late reply, I was on vacation. > >>>> > >>>> What you said make sense. The existing flag should not add PSC > >>>> channels according to the flag description. > >>>> > >>>> We can add another flag something like you pointed out > >>>> SCAN_FLAG_COLOCATED_AND_PSC_6GHZ and include PSC channels if > this > >>>> flag is set. What do you say? > >>> > >>> I'm no authority here, just wanted to point this out. This is > >>> something that would need to be in mac80211 though, not just a specific > driver. > >>> It would be up to the maintainers and would require changing the > >>> behavior of the existing flag, which then changes behavior in > >>> wpa_supplicant/hostapd. So its somewhat intrusive. > >>> > >>> But personally I'd be for it. And just require userspace include > >>> PSC's like any other channels if they need those. > >>> > >> > >> Hi Johannes, > >> > >> What is your opinion on the changes being proposed to the 6 GHz scan > >> in > >> cfg80211 that is being discussed in this thread? > >> > > > > I don't think we can/should change the semantics of an existing flag > > now, but we can certainly update the documentation to match the > > implementation, and add more flags to make it more flexible. > > > > johannes > > Sure, makes sense. I'll make the changes and send them out for review. > Sorry for joining this thread late. I agree that the documentation of the NL80211_SCAN_FLAG_COLOCATED_6GHZ flag can be updated, but FWIW, I want to clarify the intention behind this flag: First, the logic would always scan only the channels requested by user space, so if the PSC channels are not included they would not be scanned. Second, the intention of the NL80211_SCAN_FLAG_COLOCATED_6GHZ flag was to indicate to the kernel that before going to scan the 6GHz channels it should first scan the 2GHz/5GHz bands such that it would retrieve information about the collocated APs, so eventually it would only scan the given PSC channels and the channels on which collocated APs are found (in which case direct probing of these APs is expected). While the PSC channels could have been scanned together with the 2GHz/5GHz channels, since collocated APs might also reside on PSC channels, we wanted to avoid scanning PSC channels twice, so this is why they are scanned only after the scan on legacy bands. Hope this helps, Ilan.
