> Hello Lorenzo,

Hi Maxime,

> 
> On 8/25/26 11:24, Lorenzo Bianconi wrote:
> > The core soft reset issued in stmmac_init_dma_engine() clears the
> > MTL_EST registers, but nothing re-applies the taprio offload after it:
> > priv->est->enable stays true while the hardware EST block is left
> > disabled. The TX/XDP paths then keep dropping frames larger than
> > priv->est->max_sdu[] and taprio is reported as offloaded, although the
> > EST block is not programmed.
> > 
> > Re-apply the taprio offload in __stmmac_open() after PTP is up. The
> > base time is recomputed from the reserved base time and the current PTP
> > time, since the timestamp counter has been re-initialized and the
> > previously programmed base time is stale.
> 
> I agree with idea, but the way I see that, this new reconfigure method shares
> some code with stmmac_tc.c's tc_taprio_configure() step (the base time computation).
> 
> Can you also take a pass on that, so that we have a single helper (your new
> stmmac_est_reconfigure) that does the base time computation and the EST setup, that
> would be used in the .ndo_open, clock adjust and tc_taprio configuration ?

Do you mean introducing a single helper (e.g stmmac_setup_est()) where we have a
tc_taprio_qopt_offload pointer in the routine signature to distinguish between
the 'configure' and 'reconfigure' cases? E.g:

void stmmac_setup_est(struct stmmac_priv *priv,
		      struct tc_taprio_qopt_offload *qopt)
{
	...
	if (qopt) {
		/* configure from tc path */
	} else {
		/* reconfigure from __stmmac_open() path */
	}
	...
}

Regards,
Lorenzo

> 
> Maybe rename it stmmac_setup_est() to keep consistency with the stmmac_setup_ptp()
> that comes before, this would also open the door for an equivalent
> stmmac_cleanup_est() if we ever need it.
> 
> Maxime
>