Hi Jonas, as we found out here (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845128#63), FORCE_MASTER was disabled in 2019.01+dfsg-7.
I therefore downloaded u-boot-2020.07+dfsg-1 and did some testing. System: debian buster Results are attached. What i did: u-boot without FORCE_MASTER and different TX-Delays: No difference can be seen i guess. I would have expected this, as the FORCE_MASTER switch should only work for realtek-PHYs, and the REV K uses the Micrel PHY. However: I was not able to force the other partner (my old lenovo T500) of the connection to a certain mode. I thought ethtool would allow me to force the T500s, but i could not find the option. u-boot with FORCE_MASTER and TX-Delay 4: Same as above. u-boot with CONFIG_PHY_MICREL instead of CONFIG_PHY_REALTEK Good performance with TX-Delay = [3,4]. The results with TX-Delay = 2 could not be reproduced. Summed up: TX-delay = 3/4 seems useful for the Micrel phy. With TX-delay = 0, no connection was possible at all. Do you know what the switch regarding PHY_MICREL or PHY_REALTEK does? Is this possibly only used in u-boot, and therefore irrelevant as soon as linux boots? As you mentioned this commit (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3aed3e2) earlier in this thread, i would guess we should re-tests this with a linux-image > 5.2? Best regards, Dieter
u-boot-2020.07+dfsg-1.7z
Description: application/7z-compressed
