On Sat, 2012-06-09 at 10:09 +0200, Johannes Berg wrote: > On Thu, 2012-06-07 at 12:18 -0700, Pedersen, Thomas wrote: > > On Thu, Jun 07, 2012 at 09:53:20PM +0300, Kalle Valo wrote: > > > On 06/07/2012 09:38 PM, Pedersen, Thomas wrote: > > > >>> + WIPHY_FLAG_SUPPORTS_RSSI_SCAN = BIT(22), > > > >>> > > }; > > > >> > > > > >> > Is this flag really needed? For me this looks like an optimisation more > > > >> > than a functional change. If the driver supports this, that's great and > > > >> > we can save some power. But if the driver does not support it does it > > > >> > really make any difference for the user space? Would user space act > > > >> > differently if this feature is not supported by the driver? > > > > > > > > Well, this allows cfg80211 to return an error if this feature is > > > > requested but not supported by the driver / fw. > > > > > > But do we want to return an error when the driver doesn't support this? > > > I was thinking that driver should just ignore the attribute in that case > > > and let user space filter the results. > > > > > > Kalle > > > > Sure, we can just let userspace unconditionally filter the results when > > we do something like: > > > > iw wlan0 scan rssi -40 > > > > Johannes, does this look OK to you? > > I don't see a need to filter in iw, but I agree with Kalle that we > shouldn't impose any restrictions on a performance optimisation. Yeah, I also agree that the flag is probably unnecessary. We can't prevent results that are below the threshold anyway, because results from other scans might be cached in the scan results. So the userspace must always be ready to receive results that need to be dropped. -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
