linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Drake <dsd@gentoo.org>
To: linux-wireless@vger.kernel.org
Subject: mac80211 regulatory domain confusion
Date: Sat, 02 Jun 2007 17:10:31 -0400	[thread overview]
Message-ID: <4661DCC7.7090907@gentoo.org> (raw)

One of the items preventing us moving zd1211rw to mac80211 is the lack
of regulatory domain support in zd1211rw-mac80211.

In the softmac driver, we read the regulatory domain code out of the
EEPROM, and look it up in a driver-supplied "allowed channels" table,
and base future decisions from that.

The current mac80211 port appears to allow all channels everywhere.

I've seen the patch titled "d80211: Allow drivers to configure default
regulatory domain". This is a confusing - if the driver sets the
IEEE80211_HW_DEFAULT_REG_DOMAIN_CONFIGURED flag, then
ieee80211_init_client is not called?

If ieee80211_init_client is all about applying a default regulatory
domain to some internal structures, perhaps it should be renamed. If
it's about, say, initializing a wireless client device, perhaps the
check for default regdomain logic should be moved into that function.

Even after reading the discussion following that patch, I'm confused as
to what the driver should be doing and what the stack should be doing.
The ZD1211 hardware is capable of communicating on all channels, but the
software is what enforces the regdomain restrictions.

James Ketrenos wrote:
> "regdomains" are not static maps; they evolve over time as
> governments change their regulations.  The channels and features
> supported by hardware is static based on what the device was
> certified for.

So, this suggests that zd1211rw should be reading the EEPROM, looking up 
allowable channels, and formulating the ieee80211_hw_mode structures 
based on the results.

If we do that, should we also be setting the 
IEEE80211_HW_DEFAULT_REG_DOMAIN_CONFIGURED flag? From the description of 
the flag, it sounds like we should:

/* Channels are already configured to the default regulatory domain
  * specified in the device's EEPROM */

We would then bypass various logic in ieee80211_unmask_channel(), but it 
seems to me that the logic there should be being applied regardless of 
whether the driver suggested a regdomain or not. That function is also 
confusing in that it refers to "the firmware" -- whose firmware?

Daniel

             reply	other threads:[~2007-06-02 21:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-02 21:10 Daniel Drake [this message]
2007-06-04 22:43 ` mac80211 regulatory domain confusion Luis R. Rodriguez
2007-06-04 23:08   ` Michael Wu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4661DCC7.7090907@gentoo.org \
    --to=dsd@gentoo.org \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).