[OpenWrt-Devel] Negative offset for checksum in ath79's 10-ath9k-eeprom

[Chuanhong Guo]

Hi!

On Wed, Sep 18, 2019 at 8:18 PM Adrian Schmutzler
<mail at adrianschmutzler.de> wrote:
>
> Hi,
>
> I've encountered the following issue, for which I would like a second opinion.
>
> In ath79's 10-ath9k-eeprom, in addition to patching the firmware MAC address, some devices also need a checksum adjustment:
> https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom#L60
>
> For this purpose, the function ath9k_patch_fw_mac_crc is used (below ath9k_patch_fw_mac), where the chksum_offset is calculated by subtracting 10 from the mac_offset.
> (For ath10k chksum_offset value is hardcoded to 2).
>
> However, in ath79's 10-ath9k-eeprom, some devices call this function with a mac_offset of 0x2, e.g.
>
> dlink,dir-825-c1|\
> dlink,dir-835-a1)
>         ath9k_eeprom_extract "art" 0x1000 0x440
>         ath9k_patch_fw_mac_crc $(mtd_get_mac_text "mac" 0x4) 0x2
>
> This would result in a negative chksum_offset.
>
> To me this looks like a misuse of ath9k_patch_fw_mac_crc where ath9k_patch_fw_mac should have been used.

That's indeed a misuse. ar9300 eeproms (which are used on ar9331 and
later socs and ar938x pcie cards) have their macs at 0x4 and don't
have a checksum field at all.

BTW there's another misuse in ath10k-caldata: All ath10k eeproms have
checksum fields and should use ath10k_patch_mac_crc, ath10k_patch_mac
exists only because ath10k firmware doesn't verify it.

Regards,
Chuanhong Guo

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel