Re: [ath9k-devel] [RFC] ath9k: Simplify and fix eeprom endianness swapping

2015-10-25 Thread Martin Blumenstingl
On Thu, Oct 15, 2015 at 12:33 AM, Martin Blumenstingl
 wrote:
> 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

2015-10-14 Thread Martin Blumenstingl
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