Re: [RFC] ath9k's regulatory domain code changes (for ar9170)

["Luis R. Rodriguez" <lrodriguez@atheros.com>]

On Tue, Mar 24, 2009 at 11:59:37AM -0700, Bob Copeland wrote:
> On Tue, Mar 24, 2009 at 2:38 PM, Christian Lamparter <chunkeey@web.de> wrote:
> > Hi Luis,
> >
> > This is more or less what I need from ath9k's regulatory domain code.
> > What's your opinion? Would you accept the changes, or do you see
> > a potential conflict/problem with the design?
> 
> FWIW I had done a small bit of rework for sharing with ath5k, and
> Luis has those patches now in somewhat better shape.  The last
> patch set I made is here:
> 
> http://bobcopeland.com/kernel/wl/20090309/

I rebased these on top of the latest wl, and slightly modified them
to apply cleanly with checkpatch and I think I had a few very minor changes.
You can find the latest here:

http://bombadil.infradead.org/~mcgrof/patches/ath5k/ath5k-reg.patch.txt

I thought I was going to be able to work on this last week but that wasn't the
case and it seems I won't get to it this week either. Do any of you guys have
time to pick it up? Only change I'd recommend is to first make ath5k use a
small set of channels as ath9k and ar9170 has, then you can actually debug
regulatory stuff using iw by calling 'iw list' and checking the channel info.
I was going to start with that but saw its a little pain. Essentially the way
I'd do it is to modify ath5k_setup_bands() to remove the channel hw specific
settings and move that stuff to a routine which can be called dynamically upon
channel change (IEEE80211_CONF_CHANGE_CHANNEL) through the mac80211 config
callback. In ath9k we do this with the ath9k_update_ichannel(). The idea
was to eventually condense that down to a ath9k_update_ht_mode() as I think
that's all that would be required. But do do that we'd need to slowly completley
remove ath9k_channel. That's a bit of a challenge, provided you want to make
sure everything else works. But anyway that should give you an idea of where
I was heading if you want to try something similar for ath5k.

Technically speaking it'd be even nice to not have to compute this upon channel
change so that way we save time during a channel change, but that again is a nice
challenge. For example it'd be hot of we wouldn't have to compute the hw value for
the frequency on ath9k every single time as its a static value.

Anyway that's my feedback.

  Luis