From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] [PATCH v2 0/7] ath9k: EEPROM swapping improvements
Date: Sat, 17 Dec 2016 15:40:07 +0100 [thread overview]
Message-ID: <CAFBinCCmTSAQwZ1Gff=NVuGc5s4_i7k9oqBfB6XnQae_zeJ9gg@mail.gmail.com> (raw)
In-Reply-To: <CAJ-Vmo=3zox7QkFUA-3yxtvSTzPT4GiFkoOUU3cPTXSN4xV8vQ@mail.gmail.com>
Hi Adrian,
On Wed, Dec 14, 2016 at 7:45 AM, Adrian Chadd <adrian@freebsd.org> wrote:
> hi,
>
> On 12 December 2016 at 12:05, Martin Blumenstingl
> <martin.blumenstingl@googlemail.com> wrote:
>
>>
>> It seems that there are a few devices out there where the whole EEPROM
>> is swab16'ed which switches the position of the 1-byte fields
>> opCapFlags and eepMisc.
>> those still work fine with the new code, however I had a second patch
>> in LEDE [0] which results in ath9k_platform_data.endian_check NOT
>> being set anymore.
>> that endian_check flag was used before to swab16 the whole EEPROM, to
>> correct the position of the 1-byte fields again.
>> Currently we are fixing this in the firmware hotplug script: [1]
>> This is definitely not a blocker for this series though (if we want to
>> have a devicetree replacement for "ath9k_platform_data.endian_check"
>> then I'd work on that within a separate series, but I somewhat
>> consider these EEPROMs as "broken" so fixing them in
>> userspace/firmware hotplug script is fine for me)
>
> As a reference - the reference driver has been doign this for a while.
> It attempts to detect the endianness by looking at the 0xa55a
> signature endian and figuring out which endian the actual contents are
> in.
>
> So just FYI yeah, this is a "thing" for reasons I don't quite know.
on all devices I have seen so far (all customer devices, no
development boards) these two magic bytes *can* be used to detect the
endianness of the data that is written to the PCI memory (and thus
whether swapping of that data is required or not).
however, there are many devices (roughly 50% of the ones I've seen)
where the magic bytes cannot be used to swap the actual EEPROM (=
calibration) data because they are "inverted". reading the eepMisc
byte works fine on all devices I've seen so far *if* the manufacturer
did not swab16 all data (PCI memory and EEPROM data).
on the other hand you are right: all four devices which were broken
had the correct magic bytes at the start, but as long as this is not
the case for all devices we cannot use it without some feature-flag.
as an (unrelated) side-note: I've also some EEPROMs where the length
matches neither the "magic bytes endianness" nor the "eepMisc
endianness". I consider these broken as well, but fortunately ath9k
has a fallback for this issue.
Regards,
Martin
next prev parent reply other threads:[~2016-12-17 14:40 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-21 14:49 [ath9k-devel] [PATCH 0/5] ath9k: EEPROM swapping improvements Martin Blumenstingl
2016-08-21 14:49 ` [ath9k-devel] [PATCH 1/5] ath9k: Add a #define for the EEPROM "eepmisc" endianness bit Martin Blumenstingl
2016-08-22 11:42 ` Arnd Bergmann
2016-08-21 14:49 ` [ath9k-devel] [PATCH 2/5] ath9k: Set the "big endian" bit of the AR9003 EEPROM templates Martin Blumenstingl
2016-08-22 11:47 ` Arnd Bergmann
2016-08-22 11:56 ` Martin Blumenstingl
2016-08-22 15:31 ` Arnd Bergmann
2016-08-22 20:31 ` Martin Blumenstingl
2016-08-21 14:49 ` [ath9k-devel] [PATCH 3/5] ath9k: Add an eeprom_ops callback for retrieving the eepmisc value Martin Blumenstingl
2016-08-21 14:49 ` [ath9k-devel] [PATCH 4/5] ath9k: Make the EEPROM swapping check use the eepmisc register Martin Blumenstingl
2016-08-21 14:49 ` [ath9k-devel] [PATCH 5/5] ath9k: Make EEPROM endianness swapping configurable via devicetree Martin Blumenstingl
2016-08-22 11:52 ` Arnd Bergmann
2016-08-28 21:10 ` Martin Blumenstingl
2016-08-29 12:10 ` Arnd Bergmann
2016-08-29 19:45 ` Martin Blumenstingl
2016-08-29 21:25 ` Arnd Bergmann
2016-08-29 22:07 ` Martin Blumenstingl
2016-08-30 7:57 ` Arnd Bergmann
2016-10-02 22:29 ` [ath9k-devel] [PATCH v2 0/7] ath9k: EEPROM swapping improvements Martin Blumenstingl
2016-10-02 22:29 ` [ath9k-devel] [PATCH v2 1/7] ath9k: Add a #define for the EEPROM "eepmisc" endianness bit Martin Blumenstingl
2016-10-02 22:29 ` [ath9k-devel] [PATCH v2 2/7] ath9k: indicate that the AR9003 EEPROM template values are little endian Martin Blumenstingl
2016-10-02 22:29 ` [ath9k-devel] [PATCH v2 3/7] ath9k: Add an eeprom_ops callback for retrieving the eepmisc value Martin Blumenstingl
2016-10-02 22:29 ` [ath9k-devel] [PATCH v2 4/7] ath9k: replace eeprom_param EEP_MINOR_REV with get_eeprom_rev Martin Blumenstingl
2016-10-02 22:29 ` [ath9k-devel] [PATCH v2 5/7] ath9k: consistently use get_eeprom_rev(ah) Martin Blumenstingl
2016-10-02 22:29 ` [ath9k-devel] [PATCH v2 6/7] ath9k: Make the EEPROM swapping check use the eepmisc register Martin Blumenstingl
2016-10-02 22:29 ` [ath9k-devel] [PATCH v2 7/7] ath9k: define all EEPROM fields in Little Endian format Martin Blumenstingl
2016-10-12 13:18 ` [ath9k-devel] [PATCH v2 0/7] ath9k: EEPROM swapping improvements Kalle Valo
2016-11-25 15:06 ` Valo, Kalle
2016-11-25 23:49 ` Martin Blumenstingl
2016-12-12 20:05 ` Martin Blumenstingl
2016-12-13 12:03 ` Valo, Kalle
2016-12-14 6:45 ` Adrian Chadd
2016-12-17 14:40 ` Martin Blumenstingl [this message]
2016-12-15 8:34 ` Valo, Kalle
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='CAFBinCCmTSAQwZ1Gff=NVuGc5s4_i7k9oqBfB6XnQae_zeJ9gg@mail.gmail.com' \
--to=martin.blumenstingl@googlemail.com \
--cc=ath9k-devel@lists.ath9k.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 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 read-only IMAP folder(s) and NNTP newsgroup(s).