Hi!

On Wed, Sep 18, 2019 at 8:18 PM Adrian Schmutzler
<[email protected]> 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
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to