From: Arnd Bergmann <arnd@arndb.de>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] [PATCH v4 1/3] Documentation: dt: net: add ath9k wireless device binding
Date: Mon, 11 Jul 2016 00:01:05 +0200 [thread overview]
Message-ID: <1877260.9mAQ7eY9me@wuerfel> (raw)
In-Reply-To: <CAFBinCBbzMM0Pz8s444YE+NSN+035+o8PtNBoUn4v8yPMzG9Mw@mail.gmail.com>
On Sunday, July 10, 2016 10:54:50 PM CEST Martin Blumenstingl wrote:
> On Sun, Jul 10, 2016 at 10:52 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Sunday, July 10, 2016 1:28:32 AM CEST Martin Blumenstingl wrote:
> >> +- qca,check-eeprom-endianness: When enabled, the driver checks if the
> >> + endianness of the EEPROM (based on the two
> >> + magic bytes at the start of the EEPROM)
> >> + matches the host system's native endianness.
> >> + The data will be swapped accordingly if there
> >> + is a mismatch.
> >> + Leaving this disabled means that the EEPROM
> >> + data will be interpreted in the system's
> >> + native endianness, regardless of the magic
> >> + bytes.
> >> + Enable this option only when the magic bytes
> >> + are known to indicate the correct endianness
> >> + of the EEPROM data, because otherwise the
> >> + EEPROM data may be swapped and thus may be
> >> + parsed incorrectly.
> >
> > Defining properties in terms of "native" endianess is usually not a good
> > idea, as some architectures (ARMv6+, PowerPC, ...) allow running either
> > big-endian or little-endian without changing the endianess of device
> > registers in the process.
> >
> > It's better to document the property as defaulting to a specific endianess
> > unless you have an override or the autodetection flag, regardless of
> > the CPU endianess.
> ath9k reads the data from the EEPROM into memory. With that property
> disabled ath9k simply assumes that the endianness of the values in the
> EEPROM are having the correct endianness for the host system (in other
> words: no swap is being applied).
> I am not sure I understand you correctly, but isn't what you are
> explaining an issue in the ath9k code, rather than in this
> documentation?
I looked at the code more to find that out now, but I'm more confused
now, as the eeprom seems to be read as a byte stream, and the endianess
conversion that the driver performs is not on the data values in it,
but seems to instead swap the bytes in each 16-bit word, regardless
of the contents (the values inside of the byte stream are always
interpreted as big-endian). Is that a correct observation?
What I see in ath_pci_eeprom_read() is that the 16-bit words are taken
from the lower 16 bit of the little-endian AR_EEPROM_STATUS_DATA
register. As this is coming from a PCI register, it must have a device
specific endianess that is identical on all CPUs, so in the description
above, mentioning CPU endianess is a bit confusing. I could not find
the code that does the conditional byteswap, instead this function
static bool ar9300_eeprom_read_byte(struct ath_hw *ah, int address,
u8 *buffer)
{
u16 val;
if (unlikely(!ath9k_hw_nvram_read(ah, address / 2, &val)))
return false;
*buffer = (val >> (8 * (address % 2))) & 0xff;
return true;
}
evidently assumes that the lower 8 bit of the 16-bit data from PCI
come first, i.e. it byteswaps on big-endian CPUs to get the bytestream
back into the order in which it is stored in the EEPROM.
Interestingly, this also seems to happen for ath_ahb_eeprom_read()
even though on that one the value does not get swapped by the bus
accessor, so presumably big-endian machines with a ahb based ath9k
store their eeprom byte-reversed?
Arnd
next prev parent reply other threads:[~2016-07-10 22:01 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-24 12:34 [ath9k-devel] [RFC v3] ath9k: add devicetree support to ath9k Martin Blumenstingl
2016-06-24 12:34 ` [ath9k-devel] [PATCH RFC v3 1/3] Documentation: dt: net: add ath9k wireless device binding Martin Blumenstingl
2016-06-27 0:20 ` Julian Calaby
2016-06-27 9:49 ` Kalle Valo
2016-06-24 12:34 ` [ath9k-devel] [PATCH v3 2/3] ath9k: add a helper to get the string representation of ath_bus_type Martin Blumenstingl
2016-06-27 10:26 ` Felix Fietkau
2016-06-29 22:37 ` Martin Blumenstingl
2016-06-24 12:34 ` [ath9k-devel] [PATCH RFC v3 3/3] ath9k: parse the device configuration from an OF node Martin Blumenstingl
2016-06-25 12:01 ` Christian Lamparter
2016-06-25 15:08 ` Martin Blumenstingl
2016-06-25 19:26 ` Christian Lamparter
2016-06-26 23:38 ` Martin Blumenstingl
2016-07-07 1:03 ` Luis R. Rodriguez
2016-07-09 23:28 ` [ath9k-devel] [PATCH v4 0/3] add devicetree support to ath9k Martin Blumenstingl
2016-07-09 23:28 ` [ath9k-devel] [PATCH v4 1/3] Documentation: dt: net: add ath9k wireless device binding Martin Blumenstingl
2016-07-10 20:52 ` Arnd Bergmann
2016-07-10 20:54 ` Martin Blumenstingl
2016-07-10 22:01 ` Arnd Bergmann [this message]
2016-07-11 21:21 ` Martin Blumenstingl
2016-07-14 12:33 ` Arnd Bergmann
2016-07-13 7:02 ` Kalle Valo
2016-07-13 7:47 ` Arnd Bergmann
2016-07-09 23:28 ` [ath9k-devel] [PATCH v4 2/3] ath9k: add a helper to get the string representation of ath_bus_type Martin Blumenstingl
2016-07-09 23:28 ` [ath9k-devel] [PATCH v4 3/3] ath9k: parse the device configuration from an OF node Martin Blumenstingl
2016-07-10 0:32 ` Bjørn Mork
2016-07-10 9:28 ` Oleksij Rempel
2016-07-10 20:56 ` Martin Blumenstingl
2016-08-21 14:31 ` [ath9k-devel] [PATCH v5 0/3] add devicetree support to ath9k Martin Blumenstingl
2016-08-21 14:31 ` [ath9k-devel] [PATCH v5 1/3] Documentation: dt: net: add ath9k wireless device binding Martin Blumenstingl
2016-08-22 9:08 ` Arnd Bergmann
2016-08-28 20:51 ` Martin Blumenstingl
2016-08-29 12:12 ` Arnd Bergmann
2016-08-21 14:31 ` [ath9k-devel] [PATCH v5 2/3] ath9k: add a helper to get the string representation of ath_bus_type Martin Blumenstingl
2016-08-21 14:31 ` [ath9k-devel] [PATCH v5 3/3] ath9k: parse the device configuration from an OF node Martin Blumenstingl
2016-09-06 21:46 ` [ath9k-devel] [PATCH v6 0/3] add devicetree support to ath9k Martin Blumenstingl
2016-09-06 21:46 ` [ath9k-devel] [PATCH v6 1/3] Documentation: dt: net: add ath9k wireless device binding Martin Blumenstingl
2016-09-09 7:48 ` Oleksij Rempel
2016-09-09 20:57 ` Martin Blumenstingl
2016-09-13 7:28 ` Oleksij Rempel
2016-09-16 12:45 ` Rob Herring
2016-09-18 21:51 ` Martin Blumenstingl
2016-09-16 12:55 ` Rob Herring
2016-09-06 21:46 ` [ath9k-devel] [PATCH v6 2/3] ath9k: add a helper to get the string representation of ath_bus_type Martin Blumenstingl
2016-09-06 21:46 ` [ath9k-devel] [PATCH v6 3/3] ath9k: parse the device configuration from an OF node Martin Blumenstingl
2016-10-02 21:47 ` [ath9k-devel] [PATCH v7 0/3] add devicetree support to ath9k Martin Blumenstingl
2016-10-02 21:47 ` [ath9k-devel] [PATCH v7 1/3] Documentation: dt: net: add ath9k wireless device binding Martin Blumenstingl
2016-10-07 12:17 ` [ath9k-devel] [v7, " Kalle Valo
2016-10-09 1:29 ` [ath9k-devel] [PATCH v7 " Rob Herring
2016-10-09 9:54 ` Martin Blumenstingl
2016-10-02 21:47 ` [ath9k-devel] [PATCH v7 2/3] ath9k: add a helper to get the string representation of ath_bus_type Martin Blumenstingl
2016-10-02 21:47 ` [ath9k-devel] [PATCH v7 3/3] ath9k: parse the device configuration from an OF node Martin Blumenstingl
2016-10-16 20:59 ` [ath9k-devel] [PATCH v8 0/3] add devicetree support to ath9k Martin Blumenstingl
2016-10-16 20:59 ` [ath9k-devel] [PATCH v8 1/3] Documentation: dt: net: add ath9k wireless device binding Martin Blumenstingl
2016-10-18 15:31 ` Rob Herring
2016-11-15 14:56 ` [ath9k-devel] [v8, " Kalle Valo
2016-10-16 20:59 ` [ath9k-devel] [PATCH v8 2/3] ath9k: add a helper to get the string representation of ath_bus_type Martin Blumenstingl
2016-10-16 20:59 ` [ath9k-devel] [PATCH v8 3/3] ath9k: parse the device configuration from an OF node Martin Blumenstingl
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=1877260.9mAQ7eY9me@wuerfel \
--to=arnd@arndb.de \
--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 NNTP newsgroup(s).