From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Date: Sun, 10 Jul 2016 22:52:03 +0200 Subject: [ath9k-devel] [PATCH v4 1/3] Documentation: dt: net: add ath9k wireless device binding In-Reply-To: <20160709232834.31654-2-martin.blumenstingl@googlemail.com> References: <20160624123430.4097-1-martin.blumenstingl@googlemail.com> <20160709232834.31654-1-martin.blumenstingl@googlemail.com> <20160709232834.31654-2-martin.blumenstingl@googlemail.com> Message-ID: <1746957.vJhcHQMZVi@wuerfel> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org 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. Arnd