All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Buesch <mb@bu3sch.de>
To: Uli Kunitz <kune@deine-taler.de>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	Daniel Drake <dsd@gentoo.org>,
	Holden Karau <holden@pigscanfly.ca>,
	zd1211-devs@lists.sourceforge.net, linville@tuxdriver.com,
	netdev <netdev@vger.kernel.org>,
	linux-kernel@vger.kernel.org, holdenk@xandros.com
Subject: Re: [PATCH] wireless-2.6 zd1211rw check against regulatory domain rather than hardcoded value of 11
Date: Wed, 1 Nov 2006 00:48:02 +0100	[thread overview]
Message-ID: <200611010048.03126.mb@bu3sch.de> (raw)
In-Reply-To: <454683D1.4030200@deine-taler.de>

On Monday 30 October 2006 23:59, Uli Kunitz wrote:
> Johannes Berg wrote:
> >> I'm not so sure about this. This patching might be US-specific and we 
> >> cannot simply apply the setting for top channel of another domain 
> >> instead of channel 11. One option would be to set the value only under 
> >> the US regulatory domain.
> > 
> > ??
> > What the patch does is replace the top channel which is hardcoded to 11
> > by the top channel given by the current regulatory domain. How can that
> > be wrong? Except that you may want to init the regulatory domain from
> > the EEPROM but I'm not sure how the ieee80211 code works wrt. that.
> > 
> > johannes
> 
> The problem is not so much that I don't trust the geo code, but whether
> setting the register to that band-edge value for a higher channel is
> the right thing to do. It looks like that this is a hack for FFC
> compliance. Therefore I suggest to patch CR128 only
> for the US regulatory domain.
> 
> Here is the code from the GPL vendor driver (zdhw.c):
> 
>     if (pObj->HWFeature & BIT_21)  //6321 for FCC regulation, enabled HWFeature 6M band edge bit (for AL2230, AL2230S)
>      {
>          if (ChannelNo == 1 || ChannelNo == 11)  //MARK_003, band edge, these may depend on PCB layout
>          {
>              pObj->SetReg(reg, ZD_CR128, 0x12);
>              pObj->SetReg(reg, ZD_CR129, 0x12);
>              pObj->SetReg(reg, ZD_CR130, 0x10);
>              pObj->SetReg(reg, ZD_CR47, 0x1E);
>          }
>          else //(ChannelNo 2 ~ 10, 12 ~ 14)
>          {
>              pObj->SetReg(reg, ZD_CR128, 0x14);
>              pObj->SetReg(reg, ZD_CR129, 0x12);
>              pObj->SetReg(reg, ZD_CR130, 0x10);
>              pObj->SetReg(reg, ZD_CR47, 0x1E);
>          }
>      }
> 
> The patch from Holden would set ZD_CR128 to 0x12 for the highest channel,
> which would not reflect the logic of the vendor driver.

I think the real question is: What does this "band edge" bit actually do?
Did you notice any difference when setting it? Does TX power in/decrease?
Did you see differences in the physical range (max distance from the AP
for which you're still able to connect).
I don't know what channel 1 and 11 have in common. Why don't we set the
bit for channel 14? Isn't that an "edge", too?

-- 
Greetings Michael.

  parent reply	other threads:[~2006-10-31 23:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-23 18:21 [PATCH] wireless-2.6 zd1211rw check against regulatory domain rather than hardcoded value of 11 Holden Karau
2006-10-23 22:57 ` Daniel Drake
2006-10-24 14:09   ` Holden Karau
2006-10-24 15:09     ` Daniel Drake
2006-10-24 15:09       ` Daniel Drake
2006-10-29 15:42       ` Uli Kunitz
2006-10-29 15:42         ` Uli Kunitz
2006-10-30  8:42         ` Johannes Berg
2006-10-30 17:49           ` Holden Karau
2006-10-30 22:59           ` Uli Kunitz
2006-10-31 14:26             ` Holden Karau
2006-10-31 23:48             ` Michael Buesch [this message]
2006-11-01  1:34               ` Daniel Drake

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=200611010048.03126.mb@bu3sch.de \
    --to=mb@bu3sch.de \
    --cc=dsd@gentoo.org \
    --cc=holden@pigscanfly.ca \
    --cc=holdenk@xandros.com \
    --cc=johannes@sipsolutions.net \
    --cc=kune@deine-taler.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=netdev@vger.kernel.org \
    --cc=zd1211-devs@lists.sourceforge.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.