On Mon, Jul 28, 2025 at 11:36:53AM -0500, Andrew Davis wrote: Hello Andrew,
> On 7/28/25 10:33 AM, Kumar, Udit wrote: > > > > On 7/28/2025 8:19 PM, Siddharth Vadapalli wrote: > > > Increase the PHY Auto-Negotiation timeout to 20,000 ms from the current > > > default of 4,000 ms inherited from "Kconfig" for PHY_ANEG_TIMEOUT. > > > > > > The motivation for this change is that existing devices will continue > > > working as-is (timeout is an upper bound and auto-negotiation can be > > > done earlier), while older Hardware connected to the board that might > > > occasionally take longer than 4,000 ms for the Auto-Negotiation process > > > will benefit from an increased timeout. > > > > > > Can we think of using TI_COMMON_OPTION , similar to TI_COMMON_CMD_OPTIONS > > > > Or simply change the default in Kconfig to something like: > > default 20000 if ARCH_K3 || ARCH_OMAP2PLUS || ARCH_KEYSTONE > default 4000 > > Much better than 45 patches updating each board defconfig individually. Thank you for the suggestion and I agree that this is much simpler than the existing approach taken in this series. > > Side question, if this is right for TI plats, why is it not right for > all the other platforms? Should this be the new base default timeout? > I don't really think so in either case, the point of the timeout is to > switch to a fallback port or boot mode in a reasonable time, not sure > 20 seconds is reasonable.. The timeout is not due to the PHY on TI boards. Rather, it is for the Link-Partner PHY on the device connected to the TI boards. Based on my testing, the DP83867 PHY can consistently complete auto-negotiation under 4 seconds at 1 Gbps Full-Duplex configuration (Tested over 1000 iterations). On the other hand, certain Network Switches which are acting as the Link-Partner seem to randomly take around 8 seconds. Since the "config" is a timeout rather than a delay, having a higher value for the benefit of Link-Partner PHY wouldn't have adverse affect except in the case where we wish to timeout earlier to start a fallback mechanism. Regarding the "20 seconds" being unreasonable, I agree that it seems invalid, but there are other platforms which use that value. Hence, I used the same value. I assume that the value wasn't randomly set and is probably based on testing for those platforms. > > (you probably don't need ~50 people in the TO/CC on this one either, not > everyone who has ever touched the defconfigs cares about PHY timeouts) I used the "get_maintainer.pl" script to get the list of email IDs. Regards, Siddharth.
