[PATCH] net: ti: am65-cpsw-nuss: allow skipping phy_config() for speed

[Siddharth Vadapalli]

On 11/06/26 18:07, Nora Schiffer wrote:

Hello Nora,

> On Thu, 2026-06-11 at 17:36 +0530, Siddharth Vadapalli wrote:
>> Currently, phy_config() is invoked every time during am65_cpsw_start()
>> which guarantees robustness and also allows recovering from link
>> failures by resetting the Ethernet PHY. While this is beneficial for
>> system stability, for use-cases where speed is prioritized over
>> robustness, the existing implementation is insufficient.
> 
> Hi Siddharth,
> 
> I wonder if making this configurable is actually the best approach, and if we
> can't find a way to make phy_config a no-op when there is already a valid link.
> Is phy_config() actually needed to recover at all? I would expect regular

We have automated tests running frequently on a daily basis which rely on 
Ethernet to transfer Images. We have seen intermittent failures due to link 
stability (frequency is roughly once every two weeks with hundreds of tests 
running daily). With an unconditional invocation of phy_config() 
independent of the link status, the failures fell down drastically (close 
to none if I may say so).

> Ethernet PHYs to reestablish the link by themselves - I guess 1000BASE-T1
> Single-Pair Ethernet might need this?
> 
> Some background:
> 
> In our vendor branch of U-Boot, we have reverted commit 05dc050059d2 ("net: ti:
> am65-cpsw-nuss: invoke phy_config() in driver's .start callback") because it
> made PXE boot with U-Boot's default config path selection pretty much unusable:
> U-Boot would try a long list of TFTP paths based on different identifiers like
> IP addresses, each time using a new TFTP context, thus resetting the PHY and
> reestablishing the link dozens of times before arriving at the correct path.
> 
> Another solution for the PXE problem might be to refactor the code not to
> shutdown and startup the Ethernet for each attempt, but that would not help
> scripts that use separate tftp commands or similar for a sequence of file
> transfers.

My interpretation of the above makes me believe that the current patch is 
exactly what you need so that you no longer need to revert the commit 
quoted in your response. The symptom that you have described (thus 
resetting the PHY and reestablishing the link dozens of times) is prevented 
by setting 'am65_cpsw_phy_config_once' environment variable to 'y' with the 
current patch applied.

Please test it out and let me know.

Regards,
Siddharth.