On Thu, 2017-01-05 at 12:45 -0800, Dmitry Shmidt wrote:
>
> > Oh, then again, maybe you're thinking of full-MAC devices - does a
> > roam/autojoin scan really already *imply* a new connection? And if
> > so, do we have to do it that way, or can we remove that type of
> > action and make a connection decision in higher layers, so it's
> > really the same as "report when suitable results are found"?
>
> We need to consider case when FW may do some actions like connection
> during roaming/autojoin.
Ok. I was unsure if that was happening. So you're saying that the scan
parameters are determined by the host, and the scan is triggered from
there, but the action (like roaming) is taken by the firmware?
How does that differ to
1) the scan being started by the firmware, possibly based on the BSS
selection configuration Arend added?
2) the scan result being reported to the host, and BSS selection done
there?
> It depends how we want to make it flexible. For example we
> may allow to FW to report even usual scan results not one by one
> but as a chunk.
Firmware can do that, but is there any point in doing that in the
cfg80211 API? If it properly has full results, the driver can always
unbundle them and call the report function for each BSS and everything
should work just fine, no?
> > There's a bit more complication wrt. the level of detail in results
> > though - sometimes the result may include all IEs (normal/sched
> > scan), sometimes it may not ("history scan") - are we sure we
> > really only need one new get_scan_results()?
>
> Maybe not - it is possible I missed something.
I was hoping you could clarify the requirements :-)
> Also looking at our
> conversation I think we should consider separate command pair
> for history scan.
Perhaps, yes. Although perhaps having it triggered through the same
(new or extended) command, but results reported depending on the
"report type" would make sense. I think we need to clarify the exact
requirements before we make that call.
johannes
