Re: [PATCH 09/13] cfg80211: Save the regulatory domain when setting custom regulatory

[Nicolas Cavallari <Nicolas.Cavallari@green-communications.fr>]

On 11/10/2021 12:51, Kalle Valo wrote:
> Nicolas Cavallari <Nicolas.Cavallari@green-communications.fr> writes:
> 
>> On 29/11/2020 16:30, Luca Coelho wrote:
>>> From: Ilan Peer <ilan.peer@intel.com>
>>>
>>> When custom regulatory was set, only the channels setting was updated, but
>>> the regulatory domain was not saved. Fix it by saving it.
>>>
>>> Signed-off-by: Ilan Peer <ilan.peer@intel.com>
>>> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
>>> ---
>>>    net/wireless/reg.c | 8 ++++++++
>>>    1 file changed, 8 insertions(+)
>>>
>>> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
>>> index a04fdfb35f07..094492b62f8a 100644
>>> --- a/net/wireless/reg.c
>>> +++ b/net/wireless/reg.c
>>> @@ -2547,6 +2547,7 @@ static void handle_band_custom(struct wiphy *wiphy,
>>>    void wiphy_apply_custom_regulatory(struct wiphy *wiphy,
>>>    				   const struct ieee80211_regdomain *regd)
>>>    {
>>> +	const struct ieee80211_regdomain *new_regd, *tmp;
>>>    	enum nl80211_band band;
>>>    	unsigned int bands_set = 0;
>>>    @@ -2566,6 +2567,13 @@ void wiphy_apply_custom_regulatory(struct
>>> wiphy *wiphy,
>>>    	 * on your device's supported bands.
>>>    	 */
>>>    	WARN_ON(!bands_set);
>>> +	new_regd = reg_copy_regd(regd);
>>> +	if (IS_ERR(new_regd))
>>> +		return;
>>> +
>>> +	tmp = get_wiphy_regdom(wiphy);
>>> +	rcu_assign_pointer(wiphy->regd, new_regd);
>>> +	rcu_free_regdom(tmp);
>>>    }
>>>    EXPORT_SYMBOL(wiphy_apply_custom_regulatory);
>>>    
>>>
>>
>> Hello,
>>
>> This patch somehow appears to break ath9k's eeprom hints and restrict
>> it to the world regulatory domain on v5.12.10.
>>
>> ath9k calls wiphy_apply_custom_regulatory() with its own kind of world
>> regulatory domain, before it decodes hints from the eeprom and uses
>> regulatory_hint() to request a specific alpha2.
>>
>> With this patch, applying the hint fails because wiphy->regd is already set.
>> If i revert this patch, ath9k works again.
> 
> I have lost track, is this regression fixed now or is it sill
> unresolved?

I admit i forgot about it after reverting the patch and haven't tried a new 
kernel with ath9k since then, but from a quick glance, the code hasn't changed. 
I'll try a new kernel tomorrow.