Re: [PATCH] rt2x00: Provide regulatory hint with rt2500pci/usb

[Gertjan van Wingerde <gwingerde@kpnplanet.nl>]

On 01/06/09 22:51, Ivo van Doorn wrote:
> On Tuesday 06 January 2009, Luis R. Rodriguez wrote:
>    
>> On Tue, Jan 06, 2009 at 12:39:34PM -0800, Gertjan van Wingerde wrote:
>>      
>>> On 01/06/09 18:47, Ivo van Doorn wrote:
>>>        
>>>> On Tuesday 06 January 2009, Luis R. Rodriguez wrote:
>>>>
>>>>          
>>>>> On Tue, Jan 06, 2009 at 09:32:20AM -0800, Ivo van Doorn wrote:
>>>>>
>>>>>            
>>>>>>>>> 2. I'm still puzzled how to handle the two different values that the EEPROM has, namely one for the bg band and one for the a band. I've handled it by registering the one associated with the configured band, but that seems to be unlikely to be correct. I still haven't found a better way to handle this.
>>>>>>>>>
>>>>>>>>>                    
>>>>>>>> Because of this I hadn't looked very deep into rt61 and rt73 yet.
>>>>>>>>
>>>>>>>>
>>>>>>>>                  
>>>>>>>>> The problem isn't there for the bits that Ivo sent, as the rt2500 devices don't support the a band.
>>>>>>>>>
>>>>>>>>>                    
>>>>>>>> For rt2500pci and rt2500usb there are chipsets which support 5GHz (they are rare, but they do exist),
>>>>>>>> comments for the Ralink drivers indicate they simply didn't add the regulatory domain definitions yet.
>>>>>>>>
>>>>>>>>                  
>>>>>>> Based on the documentation from the EEPROM for all devices I read that its recommended
>>>>>>> that the EEPROM *not be relied on for the regulatory domain*, instead it recommends the
>>>>>>> windows registry be used.
>>>>>>>
>>>>>>> Based on tests for the devices with only one band, do are you seeing an actual regulatory
>>>>>>> domain in the EEPROM?
>>>>>>>
>>>>>>>                
>>>>>> I have to check, but I don't think I have any hardware with valid domain values.
>>>>>>
>>>>>>
>>>>>>              
>>>>>>> To deal with the issue of having two separate EEPROM values for a regulatory domain
>>>>>>> and since the documentation indicates to not rely on it I would advise to allow users
>>>>>>> to be compliant by selecting the country they are in. wpa_supplicant has support for
>>>>>>> selecting country now, and so does iw. Eventually I see Network Manager letting users
>>>>>>> select the country. But you guys are the maintainers and developers so you will know
>>>>>>> better.
>>>>>>>
>>>>>>>                
>>>>>> Well it is fine with me,  understood from earlier discussion that it was advised that drivers
>>>>>> attempted to set the domain if they could. Hence the reason I had added reading the EEPROM
>>>>>> for domain values to the TODO list. But it is true that it is quite rare that there are valid values
>>>>>> for it. So it would be fine with me by letting the user handle it completely.
>>>>>>
>>>>>>              
>>>>> I see -- well if there are *some* cards that do have valid EEPROM values then it seems worth it
>>>>> to do the actual regulatory_hint(), for dual band cards you can probably just not support it. But
>>>>> its up to you guys. Just my advice based on the documentation I have read so far.
>>>>>
>>>>>            
>>>> Ok.
>>>>
>>>> Gertjan, do you know if there is any hardware with valid GEO data in the EEPROM?
>>>>
>>>>          
>>> As mentioned in my previous email, I do have devices that have valid GEO
>>> data in the EEPROM. So, we should be able to use that.
>>> Also, for the dual band cards, it does seem that at least the numerical
>>> values are similar for both bands (although I'm not sure that same
>>> numerical values means same regulatory domain). This is at least the
>>> case on all the cards that I own.
>>>        
>> If that's the case and since dual band cards will most likely have 2ghz support
>> why not just provide regulatory_hint() based on the 2ghz band all the time?
>>      
>
> Sounds like the most reasonable solution to me as well.

I had a *slightly* more sophisticated model in mind: Check for dual-band 
devices whether the EEPROM values match. If they do, provide the 
regulatory_hint(), if they don't then just log an error, stating that 
the EEPROM cannot make up its mind in which geography it belongs. Just 
to prevent some unexpected behavior for devices that don't have sane 
EEPROM values.

However, that is all based on the assumption that we can match the 
numerical values of the two band geography domains. So far I haven't 
been able to establish that, and, moreover, the a-band field allows for 
values 0-10 where the bg-band field allows for values 0-7. So, we have 
to start matching these values against their defined allowed channels, 
and against the regulatory definitions, to see if we can actually match 
the values.

---
Gertjan