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-vadapa...@ti.com/
Regards,
Siddharth.
