On Wed, Dec 07, 2016 at 09:03:23PM +0100, Arend Van Spriel wrote: > On 7-12-2016 10:33, Vamsi, Krishna wrote: > >> -----Original Message----- > >> From: Johannes Berg [mailto:johannes@xxxxxxxxxxxxxxxx] > > > >> What about Arend's comment regarding this functionality overlapping with the > >> BSS selection offload configuration? > >> > >> Do you think there's any ability to share attributes/functionality? > > > > Hi Johannes, > > > > I think the later comment from Luca on this which I pasted below is more agreeable. > > > > Yes, similar but not quite the same. The existing case is for finding BSSs that are worth waking the host up for (while disconnected), so it needs to be better than the RSSI passed (absolute number). Now this is about relative RSSI as compared to the current connection, so RELATIVE_RSSI is different than RSSI and I think the same attribute should not be used, to avoid confusion. > > I noticed the response from Luca, but did not get back on this. I know > it is not the same, but what I meant is whether we could extend it so it > also covers your scenario. I'm not sure I see the point of trying to avoid the new RELATIVE_RSSI attribute. We need to clearly specify that this new constraint is indeed for relative comparison against the currently connected BSS. As far as your second email is concerned, it might make more sense to use the existing NL80211_ATTR_BSS_SELECT instead of the new NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF since they cover very similar purpose in defining RSSI preference between bands. We can take a look at doing so. One thing to be a careful about this is in what claims there are about using NL80211_ATTR_BSS_SELECT for capability indication in GET_WIPHY. I guess we can leave that as-is to apply for _CONNECT and the new EXT_FEATURE flag we are adding for sched_scan applies for this attribute in SCHED_SCAN. -- Jouni Malinen PGP id EFC895FA
