On Monday, August 22, 2016 1:56:46 PM CEST Martin Blumenstingl wrote:
> On Mon, Aug 22, 2016 at 1:47 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> > On Sunday, August 21, 2016 4:49:03 PM CEST Martin Blumenstingl wrote:
> >> We will default to the system's native endianness for the eepmisc value.
> >> This may be overwritten by the actual calibration data. If it is not
> >> overwritten we interpret the template data in it's native endianness,
> >> meaning that no swapping is required.
> >
> > I'm still skeptical about this one. What is the significance of "native
> > endianess" here? You are keying the endianess of the eeprom tables off the
> > way the CPU operates, but for a PCI device there is no correlation between
> > those two.
> (the ar9003 eeprom format and handling is different compared to 9287,
> def and 4k)
> ar9003_eeprom.c contains EEPROM templates -> these are compiled into
> the ath9k kernel module. Values from these templates can be
> overwritten by the EEPROM found on the actual hardware.
> This change tries to handle the case where the values in the hardware
> EEPROM do not override any of the template values (means final EEPROM
> data = template data). In this case the we can simply rely on the
> endianness which was used to compile ath9k.ko.
Ok, I see what you mean now. However, looking at the source now, I
also see
#define LE16(x) cpu_to_le16(x)
#define LE32(x) cpu_to_le32(x)
.baseEepHeader = {
.regDmn = { LE16(0), LE16(0x1f) },
suggesting that the fields are meant to be little-endian in object
code, and your patch does not change that. In fact, Felix's
ffdc4cbe5b17 ("ath9k_hw: clean up EEPROM endian handling on AR9003")
seems to have corrected this already.
Arnd
