Re: [ath9k-devel] [RFC] ath9k: Simplify and fix eeprom endianness swapping
On Thu, Oct 15, 2015 at 12:33 AM, Martin Blumenstinglwrote: > I have tested my patch on a single AR9227 device and there it's > working fine. It would be great if more people would give this a go > before merging this patch. I have just tested it on a second AR9227 device which uses the "other swapped" EEPROM format. Unfortunately my patch seems to break that, so please do not merge it for now. I will send an updated patch once I have sorted this out. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [RFC] ath9k: Simplify and fix eeprom endianness swapping
ath9k has some code which is supposed to adjust the endianness of the eeprom's contents in case it does not match the CPU endianness. However, it seems that this code was only working properly for chips that used eeprom_def. I personally have a device with an AR9227 chipset which uses an eeprom with "incorrect endianness". Feeding ath9k with this eeprom results in "no band has been marked as supported in EEPROM". An OpenWrt user has tried to work around this and documented the required steps in a ticket: [0]. The original goal of my patch was to fix the eeprom endianness handling. However, it seemed easier to take the existing (working) code from eeprom_def and make it re-usable by the other eeprom implementations (namely _9287 and _4k). I have tested my patch on a single AR9227 device and there it's working fine. It would be great if more people would give this a go before merging this patch. Regards, Martin [0] https://dev.openwrt.org/ticket/13924 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel