Re: [PATCH 1/2 v5] cfg80211: Add new wireless regulatory infrastructure

Re: [PATCH 1/2 v5] cfg80211: Add new wireless regulatory infrastructure

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1865 bytes --]

On Fri, 2008-09-05 at 12:43 -0700, Luis R. Rodriguez wrote:
> This adds the new wireless regulatory infrastructure. The
> main motiviation behind this was to centralize regulatory
> code as each driver was implementing their own regulatory solution,
> and to replace the initial centralized code we have where:
> 
> * only 3 regulatory domains are supported: US, JP and EU
> * regulatory domains can only be changed through a module parameter
> * all rules are built statically in the kernel
> 
> We now have support for regulatory domains for many countries
> and regulatory domains are now queried through a userspace agent
> (CRDA) through udev allowing distributions to update regulatory rules
> without updating the kernel. Updates on regulatory rules can
> now be left as an independent effort.
> 
> Each driver can regulatory_hint() a regulatory domain
> based on either their EEPROM mapped regulatory domain value to a
> respective ISO/IEC 3166-1 country code or pass an internally built
> regulatory domain. We also add support to let the user set the
> regulatory domain through userspace in case of faulty EEPROMs to
> further help compliance.
> 
> Support for world roaming will be added soon for cards capable of
> this.
> 
> For more information see:
> 
> http://wireless.kernel.org/en/developers/Regulatory/CRDA
> 
> For now we leave an option to enable the old module parameter,
> ieee80211_regdom, and to build the 3 old regdomains statically
> (US, JP and EU). This option is CONFIG_WIRELESS_OLD_REGULATORY.
> These old static definitions and the module parameter is being
> scheduled for removal for 2.6.29.
> 
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>

Looks fine to me now, as far as I've looked, I guess there'll be some
odd fixes required etc. but we can figure that out.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/2 v5] cfg80211: Add new wireless regulatory infrastructure

[Marcel Holtmann]

Hi Luis,

> This adds the new wireless regulatory infrastructure. The
> main motiviation behind this was to centralize regulatory
> code as each driver was implementing their own regulatory solution,
> and to replace the initial centralized code we have where:
> 
> * only 3 regulatory domains are supported: US, JP and EU
> * regulatory domains can only be changed through a module parameter
> * all rules are built statically in the kernel
> 
> We now have support for regulatory domains for many countries
> and regulatory domains are now queried through a userspace agent
> (CRDA) through udev allowing distributions to update regulatory rules
> without updating the kernel. Updates on regulatory rules can
> now be left as an independent effort.

can we get a small document in Documentation/ that describes what has to
be done for CRDA. That would help to ease the adaption and would allow
us to point people to it. Nothing fancy, but some quick notes where to
find it and what to put where.

> Each driver can regulatory_hint() a regulatory domain
> based on either their EEPROM mapped regulatory domain value to a
> respective ISO/IEC 3166-1 country code or pass an internally built
> regulatory domain. We also add support to let the user set the
> regulatory domain through userspace in case of faulty EEPROMs to
> further help compliance.

Do we have an example for all the possible ways? I think about something
to help driver maintainers to move over and use the infrastructure the
right way.

Regards

Marcel

Re: [PATCH 1/2 v5] cfg80211: Add new wireless regulatory infrastructure

[Luis R. Rodriguez]

On Fri, Sep 05, 2008 at 07:33:14PM -0700, Marcel Holtmann wrote:
> can we get a small document in Documentation/ that describes what has to
> be done for CRDA. That would help to ease the adaption and would allow
> us to point people to it. Nothing fancy, but some quick notes where to
> find it and what to put where.

Sure, I'm putting this together now.

> > Each driver can regulatory_hint() a regulatory domain
> > based on either their EEPROM mapped regulatory domain value to a
> > respective ISO/IEC 3166-1 country code or pass an internally built
> > regulatory domain. We also add support to let the user set the
> > regulatory domain through userspace in case of faulty EEPROMs to
> > further help compliance.
> 
> Do we have an example for all the possible ways? I think about something
> to help driver maintainers to move over and use the infrastructure the
> right way.

The only case I didn't test was the case for Intel's drivers, all other
drivers would use regulatory_hint() based on an alpha2 and that worked
swell. I found some issues with the case of providing a built regulatory
domain so I'm updating it now and am also updating some other parts of the
code for the old regulatory infrastructure, it seems there were a few
obvious issues we didn't catch there yet.

I hope to have the new doc for you with a few fixes and an example as to
what Intel drivers can do soon. I was hoping to get it all done by today but
that didn't happen.

  Luis