hi, On 12 December 2016 at 12:05, Martin Blumenstingl <martin.blumenstingl@xxxxxxxxxxxxxx> wrote: > > It seems that there are a few devices out there where the whole EEPROM > is swab16'ed which switches the position of the 1-byte fields > opCapFlags and eepMisc. > those still work fine with the new code, however I had a second patch > in LEDE [0] which results in ath9k_platform_data.endian_check NOT > being set anymore. > that endian_check flag was used before to swab16 the whole EEPROM, to > correct the position of the 1-byte fields again. > Currently we are fixing this in the firmware hotplug script: [1] > This is definitely not a blocker for this series though (if we want to > have a devicetree replacement for "ath9k_platform_data.endian_check" > then I'd work on that within a separate series, but I somewhat > consider these EEPROMs as "broken" so fixing them in > userspace/firmware hotplug script is fine for me) As a reference - the reference driver has been doign this for a while. It attempts to detect the endianness by looking at the 0xa55a signature endian and figuring out which endian the actual contents are in. So just FYI yeah, this is a "thing" for reasons I don't quite know. -adrian > > > Regards, > Martin > > > [0] https://git.lede-project.org/?p=source.git;a=commitdiff;h=a20616863d32d91163043b6657a63c836bd9c5ba > [1] https://git.lede-project.org/?p=source.git;a=commitdiff;h=afa37092663d00aa0abf8c61943d9a1b5558b144
