>On 15/01/2020, Orr Mazor <orr.mazor@xxxxxxxxxxx> wrote:
>> In case no one is occupying a wiphy, all past regulatory data will be
>> lost as a result of reset to world reg domain.
>>
>> This includes any channel that is currently in NOP time as well as in
>> AVAILABLE state.
>>
>> This means that after detecting a radar on a channel the user might be
>> able to simply reset hostapd and get back to that channel, this is a
>> major issue.
>>
>> To solve this I have added a check before doing any resets.
>>
>> If the user (for example: hostapd) asks for a regdomain and we are
>> already in that regdomain, than we shouldn't reset that regdomain in
>> case of wiphy disconnection (for example: hostapd reset or killed).
>>
>> That way the regulatory data will be saved as long as we are in the
>> same regdomain.
>>
>> Since in that case we will anyway get back to the same regdomain the
>> only difference is we will now save the regulatory data, won't lose
>> it, and as a result won't get back to a channel that a radar was
>> detected on until NOP will be finished, as should be.
>>
>> Signed-off-by: Orr Mazor <Orr.Mazor@xxxxxxxxxxx>
>> ---
>> net/wireless/reg.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/net/wireless/reg.c b/net/wireless/reg.c index
>> d18cc05061a0..5049c487950b 100644
>> --- a/net/wireless/reg.c
>> +++ b/net/wireless/reg.c
>> @@ -3180,6 +3180,16 @@ static void restore_regulatory_settings(bool
>> reset_user, bool cached)
>> }
>> spin_unlock(®_indoor_lock);
>>
>> + /* If the user asks for a regdomain and we are
>> + * already in that regdomain, than we shouldn't reset
>> + * the regdomain in the case of wiphy disconnection.
>> + */
>> + if (cached && !reset_user &&
>> + (!IS_ERR_OR_NULL(cfg80211_user_regdom)) &&
>> + (!regdom_changes(cfg80211_user_regdom->alpha2))) {
>> + return;
>> + }
>> +
>> reset_regdomains(true, &world_regdom);
>> restore_alpha2(alpha2, reset_user);
>>
>> --
>> 2.17.1
>>
>>
>
>Which device have you tested this on?
Hi Tom,
I have tested this on mac80211_hwsim and on a intel proprietary device.
The issue (before the patch) is seen in both, and the patch solves it in both.
BR,
Orr
