Re: [PATCH 12/19] wilc: add wilc_wfi_cfgoperations.c

[<Adham.Abozaeid@microchip.com>]

On 10/09/2018 10:15 AM, Adham Abozaeid wrote:
> 
> 
> On 10/09/2018 12:55 AM, Johannes Berg wrote:
>> On Tue, 2018-10-09 at 04:23 +0000, Adham.Abozaeid@microchip.com wrote:
>>>
>>>> I don't know what you need the shadow stuff for, but you should remove
>>>> it anyway, and use the cfg80211 functionality instead. If not
>>>> sufficient, propose patches to improve it?
>>>
>>> The point behind using a shadow buffer was to keep the scan results
>>> consistent between consecutive scans, and smooth out the cases where
>>> an AP isn't found momentarily during scanning.
>>> In this implementation, APs found during scanning are added to the
>>> shadow list, and removed if not found again for a period of time.
>>>
>>> I'm not much in favour of this implementation neither since it
>>> complicates the driver's logic, but it was serving the purpose.
>>
>> You really should remove it - cfg80211 *and* wpa_s already do this if
>> required.
>>
>> johannes
>>
> 
> Thanks Johannes for the tip. I did some research, and I believe you are
> referring to using bss_expire_age and bss_expire_count.
> We'll go ahead and remove that.


Johannes, shadow buffer has 2 more usage that I missed in my first email:
1- It keeps a copy of scan results to be able to auto-select from if the cfg80211 didn't supply a specific bssid in cfg's connect request (struct cfg80211_connect_params).
In this case the driver will select a network that matches the ssid, while having the highest rssi.
2- It keeps network parameters that the device will need to connect to a network, since the device doesn't keep the scan results internally.
These parameters are stored in struct join_bss_param, and passed to the device  when a connect request is received.
Some of these parameters can be extracted from cfg's cfg80211_connect_params (like cap_info.. etc), but others (like bssid, beacon period.. etc) are still required.

I think I can remove the functionality where it keeps older networks that didn't appear in the latest scan results, and let cfg take care of that, but will still need it to keep a copy of the latest scan results.
Let me know what you think.


Thanks,
Adham