Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <CAKfDRXhVQvJYAiacyMx0sGqrh6L7KR606FaBdh4nhznsKY0TMg@mail.gmail.com>
In-Reply-To: <CAKfDRXhVQvJYAiacyMx0sGqrh6L7KR606FaBdh4nhznsKY0TMg@mail.gmail.com>
From:   Kristian Evensen <kristian.evensen@gmail.com>
Date:   Sun, 21 Jul 2019 15:52:32 +0200
Message-ID: <CAKfDRXhTEAaEjyqMe3qzjJi41SK_N_MDsaDt=hRH+CzChJss=A@mail.gmail.com>
Subject: Re: Problems loading ath9k (ar93xx) calibration data
To:     linux-wireless@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

Hello again,

On Sun, Jul 21, 2019 at 3:10 PM Kristian Evensen
<kristian.evensen@gmail.com> wrote:
> Considering that the next byte has the value 0x1, I suspect the issue
> might be related to endianess. However, I haven't found a way to
> trigger an endianess-conversion when the calibration data is read for
> file. Is there something I am missing or is this not supported?
>
> Could endianess be an explanation for the error I am seeing, or are
> there other things in the calibration data the looks like it could
> cause problems as well?

I took a second look at the ath9k-driver and see that 0x1 is the value
of AR5416_OPFLAGS_11A, which sets the CAP_5GHz flag. My card is only
2.4 GHz, so then I guess the endianess-theory was wrong.

BR,
Kristian