[OpenWrt-Devel] question about ath9k endianness check in eeprom_9287.c

[Ben Mulvihill]

On Sun, 2014-12-28 at 01:02 +0100, Ben Mulvihill wrote:
> Hello Felix,
> 
> I am working on the BT Home Hub 3A, which has ath9k wireless.
> More or less everything is working now, apart from
> reading the calibration data. To get that working too, 
> endianness checking must be enabled. That requires a one line
> fix to eeprom_9257.c . 
> 
> --- a/drivers/net/wireless/ath/ath9k/eeprom_9287.c	2014-09-27 15:48:08.000000000 +0200
> +++ b/drivers/net/wireless/ath/ath9k/eeprom_9287.c	2014-12-28 00:55:52.000000000 +0100
> @@ -184,7 +184,7 @@ static int ath9k_hw_ar9287_check_eeprom(
>  	struct ar9287_eeprom *eep = &ah->eeprom.map9287;
>  	struct ath_common *common = ath9k_hw_common(ah);
>  
> -	if (!ath9k_hw_use_flash(ah)) {
> +	if (!(ah->ah_flags & AH_NO_EEP_SWAP)) {
>  		if (!ath9k_hw_nvram_read(ah, AR5416_EEPROM_MAGIC_OFFSET,
>  					 &magic)) {
>  			ath_err(common, "Reading Magic # failed\n");
> 
> A similar fix was in fact present until quite recently
> (till r42950 to be precise) in
> package/kernel/mac80211/patches/501-ath9k-eeprom_endianess.patch
> but in the wrong place (there are two calls to ath9k_hw_use_flash()
> in eeprom_9287.c, and the patch changed the wrong one). With
> changeset 42951 that fix was then dropped (together with the
> equivalent fix to eeprom_4k.c).
> 
> A much much earlier version of 501-ath9k-eeprom_endianess.patch
> (r31084) contains the fix in the correct place. I guess 
> that somewhere in between r31084 and r42950 (I haven't tried to
> work out exactly where) someone slipped up when updating this 
> patch. And presumably there can't be many boards making use of
> this code otherwise someone else would have noticed already.
> 
> If I had I been writing this email four months ago I would
> simply  have submitted a patch correcting
> 501-ath9k-eeprom_endianess.patch.
> However that patch and its successor have now disappeared. Am I
> right in thinking that their contents have gone upstream? If 
> so I should be grateful if you would let me know how to proceed.
> Should I submit a new patch to be inserted into
> package/kernel/mac80211/patches ? Or should I try to get the fix
> into compat-wireless directly?
> 
> Many thanks, Ben Mulvihill
> 

Any thoughts about this? Actually I think there are three options:

 - a new patch in package/kernel/mac80211/patches reinstating 
   a couple of lines from the old 501-ath9k-eeprom_endianess.patch

 - the same fix straight into the upstream code

 - no fix at all, and instead work round the bug during installation
   by reading the ath9k calibration partition, byte-swapping certain
   fields offline and re-flashing it.
   
Thanks in advance.
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel