On Wed, 2017-01-11 at 07:48 +0000, Vamsi, Krishna wrote:
> > -----Original Message-----
>
>
> > > + * @relative_rssi_set: Indicates whether @relative_rssi is set
> > > or not.
> >
> > So you see a use-case for doing a scan with @relative_rssi being
> > zero, right?
>
> Yes. Zero value for relative_rssi is also valid.
Or negative even, I guess?
> > > + * @relative_rssi: Relative RSSI threshold in dB to restrict
> > > scan result
> > > + * reporting in connected state to cases where a matching
> > > BSS is
> >
> > determined
> > > + * to have better RSSI than the current connected BSS.
> > > The relative RSSI
> > > + * threshold values are ignored in disconnected state.
> >
> > The description says "better RSSI" so I suppose it could be typed
> > as u8. The last sentence is intended driver behavior
>
> I like to leave this as s8 only. This will leave more flexibility to
> userspace especially in case of more than two bands in future.
I guess you should reword that - instead of "better" it should say how
this value is applied, as a delta to the current RSSI, and then
reporting the result.
However, I don't understand your comment about this being related to
multiple bands, can you clarify? The relative_rssi just determines the
filter after the adjustment(s) done with rssi_adjust, but how could it
be relevant?
The only use case for relative_rssi being negative would be when you
actually *want* to see slightly worse networks than the one you're
connected to, e.g. to determine if you should use them because they
have better parameters (e.g. HT/VHT or soon HE).
> > > + if (attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI]) {
> > > + request->relative_rssi = nla_get_s8(
> > > + attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_R
> > > SSI]);
> > > + request->relative_rssi_set = true;
> > > + }
> > > +
> > > + if (attrs[NL80211_ATTR_SCHED_SCAN_RSSI_ADJUST]) {
> >
> > Maybe I misread but I thought this attribute to be applicable only
> > if
> > request->relative_rssi_set is true.
>
> @relative_rssi is valid only when @relative_rssi_set is set to true
> and @rssi_adjust is valid only when @relative_rssi is valid. I think
> that is understandable to drivers and there is no need of explicit
> check here.
It wouldn't be problematic to parse the RSSI_ADJUST only when the
others are present though, so that a driver could apply the rssi_adjust
unconditionally (since, if it's not parsed, the delta will be 0.)
johannes