On Sun, Jul 10, 2016 at 10:52 PM, Arnd Bergmann <arnd@xxxxxxxx> 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? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
