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 -- 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
