On Monday 29 August 2016, Martin Blumenstingl wrote: > > and then do a swab32() on them. I suspect these should just be __le32 > > (and __le16, respectively where needed), using appropriate accessors > > everywhere that those fields are being read instead of having one function > > that tries to turn them into cpu-native ordering. > I'm not sure if we want those fields to be __le32: > BIT(0) in the eepMisc field indicates whether to interpret the data as > big or little endian. > When this bit is set we would want these fields to be __be32 instead - > so I guess the current implementation is "OK" for this specific > use-case. Ok, I see. It's still confusing because it's different from how other drivers handle this (case in point: I was very confused by this). Do you see any downsides in changing the code to consistently annotate the eeprom as either __le or __be (whichever is more common), using the respective endianess accessors, and then doing the swap if the data we read is the opposite way? 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
