[PATCH 01/45] configs: am335x_baltos_defconfig: Increase aneg timeout to 20000 ms

[Siddharth Vadapalli]

On Mon, Jul 28, 2025 at 10:53:29AM -0600, Tom Rini wrote:

Hello Tom,

> On Mon, Jul 28, 2025 at 11:36:53AM -0500, Andrew Davis wrote:
> > 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.
> > 
> > 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..
> > 
> > (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)
> 
> [trimmed the CC list a bit]
> 
> The other part of this to me is, is this even right outside of "we have
> a big test board farm" ? And since this is read from the environment now
> (yes?) can we instead not just expect big labs to update the
> environment? Or no, too many of these will lack persistent environments?

I have posted a patch to allow overriding the timeout in the form of an
environment variable [0].

I agree that end users should override the config for their use-case and
it is mostly in the Test Farm that we see issues - the process takes
around 8 seconds once in a while and that triggers a timeout. However,
since the "config" is a timeout rather than a delay, it will not
increase the time taken for the auto-negotiation process. So it might be
safe to increase the timeout, except in cases where we wish to detect a
timeout early (if it doesn't complete within 4 seconds, we don't expect
it to ever complete, so there is no point waiting for 20 seconds).

Please let me know which among the following seem acceptable:
1. The patch at [0] is the proper method to override the timeout and the
   config shouldn't be modified.
2. The default value is modified in Kconfig based on Andrew's suggestion:
	default 20000 if ARCH_K3 || ARCH_OMAP2PLUS || ARCH_KEYSTONE
	default 4000
3. Another approach that you may wish to suggest in order to address the
   problem.

[0]: https://patchwork.ozlabs.org/project/uboot/patch/20250724141536.1222764-1-s-vadapalli@ti.com/

Regards,
Siddharth.