linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: kvalo@codeaurora.org, ath9k-devel@qca.qualcomm.com,
	linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org,
	devicetree@vger.kernel.org, robh+dt@kernel.org,
	mark.rutland@arm.com, chunkeey@googlemail.com, nbd@nbd.name
Subject: Re: [PATCH 5/5] ath9k: Make EEPROM endianness swapping configurable via devicetree
Date: Mon, 22 Aug 2016 13:52:07 +0200	[thread overview]
Message-ID: <2303906.Xe1WvCfP0V@wuerfel> (raw)
In-Reply-To: <20160821144906.30984-6-martin.blumenstingl@googlemail.com>

On Sunday, August 21, 2016 4:49:06 PM CEST Martin Blumenstingl wrote:
> +- qca,check-eeprom-endianness: When enabled, the driver checks if the
> +                               endianness of the EEPROM (using two checks,
> +                               one is based on the two magic bytes at the
> +                               start of the EEPROM and a second one which
> +                               relies on a flag within the EEPROM data)
> +                               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 always be interpreted in the
> +                               system's native endianness.
> +                               Enable this option only when the EEPROMs
> +                               endianness identifiers are known to be
> +                               correct, because otherwise the EEPROM data
> +                               may be swapped and thus interpreted
> +                               incorrectly.

The property should not describe the driver behavior, but instead
describe what the hardware is like.

A default of "system's native endianess" should not be specified
in a binding, as the same DTB can be used with both big-endian or
little-endian kernels on some architectures (ARM and PowerPC among
others), so disabling the property means that it is guaranteed to
be broken on one of the two.

If we have no reliable way to check the endianess in all combinations,
could we have two properties "eeprom-big-endian" and
"eeprom-little-endian" and mandate that one of them is always used
when discovering the device using DT?

	Arnd

  reply	other threads:[~2016-08-22 11:52 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-21 14:49 [PATCH 0/5] ath9k: EEPROM swapping improvements Martin Blumenstingl
2016-08-21 14:49 ` [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 ` [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 ` [PATCH 3/5] ath9k: Add an eeprom_ops callback for retrieving the eepmisc value Martin Blumenstingl
2016-08-21 14:49 ` [PATCH 4/5] ath9k: Make the EEPROM swapping check use the eepmisc register Martin Blumenstingl
2016-08-21 14:49 ` [PATCH 5/5] ath9k: Make EEPROM endianness swapping configurable via devicetree Martin Blumenstingl
2016-08-22 11:52   ` Arnd Bergmann [this message]
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 ` [PATCH v2 0/7] ath9k: EEPROM swapping improvements Martin Blumenstingl
2016-10-02 22:29   ` [PATCH v2 1/7] ath9k: Add a #define for the EEPROM "eepmisc" endianness bit Martin Blumenstingl
2016-10-02 22:29   ` [PATCH v2 2/7] ath9k: indicate that the AR9003 EEPROM template values are little endian Martin Blumenstingl
2016-10-02 22:29   ` [PATCH v2 3/7] ath9k: Add an eeprom_ops callback for retrieving the eepmisc value Martin Blumenstingl
2016-10-02 22:29   ` [PATCH v2 4/7] ath9k: replace eeprom_param EEP_MINOR_REV with get_eeprom_rev Martin Blumenstingl
2016-10-02 22:29   ` [PATCH v2 5/7] ath9k: consistently use get_eeprom_rev(ah) Martin Blumenstingl
2016-10-02 22:29   ` [PATCH v2 6/7] ath9k: Make the EEPROM swapping check use the eepmisc register Martin Blumenstingl
2016-10-02 22:29   ` [PATCH v2 7/7] ath9k: define all EEPROM fields in Little Endian format Martin Blumenstingl
2016-10-12 13:18   ` [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
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=2303906.Xe1WvCfP0V@wuerfel \
    --to=arnd@arndb.de \
    --cc=ath9k-devel@lists.ath9k.org \
    --cc=ath9k-devel@qca.qualcomm.com \
    --cc=chunkeey@googlemail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=martin.blumenstingl@googlemail.com \
    --cc=nbd@nbd.name \
    --cc=robh+dt@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 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).