From: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com>
To: "Michał Kazior" <kazikcz@gmail.com>
Cc: Adrian Chadd <adrian@freebsd.org>, linux-wireless@vger.kernel.org
Subject: Re: [PATCH v2] ath: sanitize 0xFFFF regdomain
Date: Thu, 28 Feb 2013 15:10:21 -0800 [thread overview]
Message-ID: <CAB=NE6VBLQTtcT6rAQ===GFxSai6-+O=Ms7mMRhG4mB0pAc3Qw@mail.gmail.com> (raw)
In-Reply-To: <CABvG-CWsvuJzMp06BitK1RGF55WJjZ8O4H58=VRpMcX27362RA@mail.gmail.com>
On Wed, Feb 27, 2013 at 10:52 PM, Michał Kazior <kazikcz@gmail.com> wrote:
> On 28 February 2013 03:43, Adrian Chadd <adrian@freebsd.org> wrote:
>> Have you verified that the rest of the EEPROM contents are vailid?
>
> I have not. How can I do that?
The module would have done this upon initialization, this is done
during hw init, prior to reg init. The EEPROM callback fill_eeprom()
does this for the different families. To be clear ath9k_hw_init() gets
called prior to ath_regd_init().
I'll note for the record that regardless of what is decided if the
card came from a device designed as an AP the AP manufacturer intended
for that card to stay with that AP, and as per our support team the AP
design / manufacturer could end up programming whatever into the
EEPROM / OTP, and their support for that device would be intended with
their own solution.
Supporting 0x64 for this regdomain that some random AP manufacturer
used should be OK though but note that we can't support it.
Luis
prev parent reply other threads:[~2013-02-28 23:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-27 19:09 [PATCH v2] ath: sanitize 0xFFFF regdomain Michal Kazior
2013-02-28 2:43 ` Adrian Chadd
2013-02-28 6:52 ` Michał Kazior
2013-02-28 23:10 ` Luis R. Rodriguez [this message]
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='CAB=NE6VBLQTtcT6rAQ===GFxSai6-+O=Ms7mMRhG4mB0pAc3Qw@mail.gmail.com' \
--to=mcgrof@qca.qualcomm.com \
--cc=adrian@freebsd.org \
--cc=kazikcz@gmail.com \
--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 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.