linux-wireless.vger.kernel.org archive mirror
 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: Mon, 29 Mar 2010 21:49:59 +0200	[thread overview]
Message-ID: <m339zizz4o.fsf@intrepid.localdomain> (raw)
In-Reply-To: <43e72e891003291222n5e72a0a5m31dddf2bbf6e06ab@mail.gmail.com> (Luis R. Rodriguez's message of "Mon, 29 Mar 2010 12:22:59 -0700")

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

>> I'm not sure how the modified regulatory.bin could work, though:
>> I really don't want to use restricted frequencies etc. when the
>> regulatory domain is set to US (i.e. when operating in USA), I only want
>> to use the extra channels etc. when in e.g. Europe.
>
> I agree with that wishful thinking, however current legislation does
> now allow for dynamic enabling of frequencies on devices certified
> under part 15 rules. We can likely work towards changing the
> legislation for this but that's something I haven't seen many
> companies willing to lobby for. We'd need a big company to help with
> this lobby.

But... isn't the modifying of the regulatory.bin (the US part of it)
to include channels valid in e.g. Europe breaking the (US) rules? I'm
not asking you for a legal advice binding Atheros as the manufacturer in
the USA, I'm asking how to enable the user to be technically compliant
here in Europe where the hardware is sold, and also in the USA if the
user gets there and sets the regdomain (and elsewhere in the world, in
fact).

Modifying regulatory.bin doesn't seem to help here, does it?

>> A driver modification to ignore the default restrictions (while obeying
>> the regulatory.bin, on a 0-country cards only, of course) - that would
>> work.
>
> And it would also make our drivers break regulatory rules. We're not
> going to do that on Linux because proving that we can be responsible
> is in fact what does allow us to get proper vendor support for 802.11
> drivers.

I'm not asking you to do that, I only need to know if it's the correct
(and only?) way of fixing this problem (while still providing
compliance of the whole device). Fortunately I'm not responsible for the
legalities.


The other thing is the meaning of country=0 in case of Mikrotik cards
(and maybe others). Perhaps they should get them back. I wonder if
their drivers break the FCC rules, allowing "0" (=US) cards to use
channels restricted in the US.
-- 
Krzysztof Halasa

  reply	other threads:[~2010-03-29 19:50 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 [this message]
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
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=m339zizz4o.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 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).