On Thu, 2017-01-05 at 12:45 -0800, Dmitry Shmidt wrote:

quoted

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?

quoted

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