On Thu, Sep 27, 2012 at 11:13 AM, Johannes Berg
<johannes@xxxxxxxxxxxxxxxx> wrote:
> On Tue, 2012-09-25 at 15:49 -0700, Sam Leffler wrote:
>> These add per-scan request controls for optional behaviours we've found
>> useful (they've been in Chrome OS for a long time). A patch for iw will
>> follow separately and the mods for wpa_supplicant are in our repo and
>> I'll push them to Jouni if these are accepted.
>>
>> Sam Leffler (3):
>> {nl,cfg}80211: add a flags word to scan requests
>> mac80211: add support for tx to abort scan requests
>> cfg80211: add support for flushing old scan results
>
> I like the flushing one, but I'm not so sure about the TX abort thing.
> How do you suggest to handle that when scanning is offloaded to the
> driver and/or firmware? Especially given that multi-channel is going to
> require a firmware implementation, I'm not sure how to achieve good
> behaviour across the different implementations.
>
> Maybe it'd be worthwhile to go for a more generic approach, marking
> scans as "low priority" or "high priority" or similar, and then
> implementing such behaviour based on such settings? Our device for
> example has a notion of "background scan" vs. "forced scan", which
> behave differently in the firmware, and it would be useful to be able to
> use these different behaviours. However, I can't say that "TX abort"
> would be a guaranteed scan behaviour for a "background scan".
>
we also have some "urgency" option in our hw scan, but we currently
never use it (not really sure when it should be used... maybe for
roaming on beacon loss?)
the TX abort is relevant mainly for sw scan.
i'm not sure we really want to couple it with scan priority, though.
otoh, userspace doesn't really care (or know) if we use sw or hw scan,
so configuring it all with a single "scan priority" option does make
sense.
Eliad.
--
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
