[PATCH] ath79: add support for gl-e750

mail at adrianschmutzler.de mail at adrianschmutzler.de
Fri Jul 10 07:41:22 EDT 2020

> Thank you for pointing out my problem.
> Part of the problem I need to explain.
> No LEDs?
> --->Yes, no leds
> Why eth1?
> If that's caused by &eth1 being enabled in device tree, you can try to put the following in DTS:
> &eth1 {
> compatible = "syscon", "simple-mfd";
> };
> With this, you might be able to use
> ucidef_set_interface_lan "eth0"
> --->the E750 has only one ethernet port, but this port corresponds to eth1 in the system.

I still think if there is only one port, it should be eth0 on the running system. I do not see a point to use eth1 and have a non-working eth0 there.
And I assume that putting the above node into DTS should achieve just this.

> --->In E750, we only use GMAC0, but in ATH79 target, I had to initialize P4 via GMAC1 connected to the Ethernet switch, the GMAC0 corresponds to eth1 and the GMAC1  corresponds to eth0.
> --->I have tried to use GMAC0 to initialize P4 directly, but after initializing P4 in this way, the speed of P4 can only be 100M, not 100M/10M.
> This should be done properly in generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata instead.
> --->E750 block using eeprom storage calibration data of 9887, when the driving load, also won't call /etc/hotplug.d/firmware/11-ath10k-caldata.
> What about caldata? Is there a valid address in 0x5006?
> ---> Calibration data for the E750 is not stored in flash, therefore, the MAC address is not read from 0x5006.
> ---> In the production process of GL router, a basic MAC address will be written at the beginning of ART, and I calculate the MAC address of 5G through this MAC address.

Okay, then please consolidate the MAC address setup like the following:

> +	glinet,gl-e750)
> +		# Set mac address for 5g device
> +		[ "$PHYNBR" -eq 0 ] && \
> +			macaddr_add $(mtd_get_mac_binary art 0x0) 2) > /sys${DEVPATH}/macaddress
> +		;;

Despite, I'm always happy about a MAC address overview in the commit message, e.g. like here:

Instead of the last byte from an actual address, you might just include the offset relative to one of the addresses. This will help a lot for understanding the setup when looking at the commit in a few years.

Despite, if the device has a "label MAC address" printed on a label/the case somewhere, it would be nice to mention which one it is (i.e. which interface has the same address) in the commit message and to implement it in the code (see https://openwrt.org/docs/guide-developer/mac.address#label_mac_address).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20200710/a0fbebcc/attachment.sig>

More information about the openwrt-devel mailing list