All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Halasa <khc@pm.waw.pl>
To: "Luis R. Rodriguez" <mcgrof@gmail.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: CRDA and ath5k with no country code in EEPROM
Date: Tue, 30 Mar 2010 22:13:51 +0200	[thread overview]
Message-ID: <m3r5n1o9ds.fsf@intrepid.localdomain> (raw)
In-Reply-To: <43e72e891003301140p850093aya4ea6e1951e7ab9c@mail.gmail.com> (Luis R. Rodriguez's message of "Tue, 30 Mar 2010 11:40:08 -0700")

"Luis R. Rodriguez" <mcgrof@gmail.com> writes:

>> Software (the official Atheros driver, to be precise) says 0 isn't
>> exactly US.
>> Hardware (card) manufacturer says 0 isn't US.
>
> Would it make you happy if I send a patch to clarify that?

That would fix a good part of the problem, yes. TIA.

> I've indicated that your card is already working as it was designed.

But that's not the case.

The Atheros _chips_ are probably working as designed. The card(s) does
not, since it was designed for European market, and its designer
confirms this. Yet, by default, this card (+ driver) enables channels
which should be disabled in Europe, and disables others, which should be
available.

This is caused by interaction between two pieces - the driver and the
card. Most probably each one of them, alone, is not at fault.

> The EEPROM is not something that was designed for end users to modify.

Though I'm not end user, I will leave it for others to modify, no
problem. I only need a proof (such as the driver printing "US") it
should be modified.

> Who programmed your EEPROM choose that for a reason, and only they and
> as per Atheros's documentation would know what the goal was,

and those who were told about it. The stated goal is known, and I assume
the calibration data is available as well (I don't have these cards
physically ATM).

> If you want to muck with the EEPROM/code for regulatory compliance
> that is up to you and that is simply not supported due to a few
> things. One of them is calibration data which may or not be available
> for the region you would choose blindly. Properly enabling users to
> change their regulatory domain at their own whim really requires more
> involvement, sure you'd be able to use some additional channels but it
> by no means would mean that they are in compliance or that the EIRP
> you use hits the actual desired target. The important part really is
> compliance.

Precisely. To be compliant I have to restrict usage to a specific set of
frequencies. Unfortunately it's a different set than the one in US.

> The regulatory code on for the Atheros drivers enables usage only of
> the channels dictated by the EEPROM and what we in software match that
> EEPROM code to tables in software. This is by design. The Linux
> regulatory framework allows you to further restrict the device further
> but for Atheros cards if you change countries you will not get new
> channels if your original programmed regulatory domain does not allow
> for it.

Yes, and it fits the needs nicely - if the card manufacturer's idea
about meaning of the EEPROM matches the driver.
-- 
Krzysztof Halasa

  reply	other threads:[~2010-03-30 20:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-28 20:52 CRDA and ath5k with no country code in EEPROM Krzysztof Halasa
2010-03-28 23:45 ` Luis R. Rodriguez
2010-03-29 19:15   ` Krzysztof Halasa
2010-03-29 19:22     ` Luis R. Rodriguez
2010-03-29 19:49       ` Krzysztof Halasa
2010-03-29 19:56         ` Luis R. Rodriguez
2010-03-29 20:48           ` Krzysztof Halasa
2010-03-29 22:00             ` Luis R. Rodriguez
2010-03-30 11:41               ` Krzysztof Halasa
2010-03-30 16:28                 ` Luis R. Rodriguez
2010-03-30 18:21                   ` Krzysztof Halasa
2010-03-30 18:40                     ` Luis R. Rodriguez
2010-03-30 20:13                       ` Krzysztof Halasa [this message]
2010-03-30 18:49                     ` Christian Lamparter
2010-03-30 18:52                       ` Luis R. Rodriguez
2010-03-30 20:33                       ` Krzysztof Halasa
2010-03-30 22:07                         ` Luis R. Rodriguez
2010-03-31  0:26                           ` Krzysztof Halasa
2010-03-30 22:11                         ` Christian Lamparter
2010-03-30  6:42             ` Holger Schurig
2010-03-30 11:46               ` Krzysztof Halasa
2010-03-29 20:04         ` Christian Lamparter
2010-03-29 20:54           ` Krzysztof Halasa
2010-03-29 21:57           ` Luis R. Rodriguez

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=m3r5n1o9ds.fsf@intrepid.localdomain \
    --to=khc@pm.waw.pl \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mcgrof@gmail.com \
    /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.