On 9-1-2017 11:45, Johannes Berg wrote:
> 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?
Currently, the BSS selection configuration is used in CMD_CONNECT. It
can probably be used for scanning as well. The presence of the attribute
would indicate the scan may result in a roam or connect event.
> 2) the scan result being reported to the host, and BSS selection done
> there?
Not sure if we need to consider this one, do we?
>> 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?
Agree.
>>> 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.
Leaning towards single initiate command and a notification and results
command per "report type".
Regards,
Arend
