RE: [PATCH v5 net-next 13/15] net: enetc: add PTP synchronization support for ENETC v4

From: Wei Fang
Date: Mon Aug 25 2025 - 22:11:34 EST


> On Mon, Aug 25, 2025 at 12:15:30PM +0800, Wei Fang wrote:
> > Regarding PTP, ENETC v4 has some changes compared to ENETC v1
> > (LS1028A), mainly as follows.
> >
> > 1. ENETC v4 uses a different PTP driver, so the way to get phc_index
> > is different from LS1028A. Therefore, enetc_get_ts_info() has been
> > modified appropriately to be compatible with ENETC v1 and v4.
> >
> > 2. Move sync packet content modification before dma_map_single() to
> > follow correct DMA usage process, even though the previous sequence
> > worked due to hardware DMA-coherence support (LS1028A). But For i.MX95
> > (ENETC v4), it does not support "dma-coherent", so this step is very
> > necessary. Otherwise, the originTimestamp and correction fields of the
> > sent packets will still be the values before the modification.
> >
>
> I think it is wonth to create seperate patch for it, put it before this patch.

Okay, I will a separate patch.

>
> > 3. The PMa_SINGLE_STEP register has changed in ENETC v4, not only the
> > register offset, but also some register fields. Therefore, two helper
> > functions are added, enetc_set_one_step_ts() for ENETC v1 and
> > enetc4_set_one_step_ts() for ENETC v4.
> >
> > 4. Since the generic helper functions from ptp_clock are used to get
> > the PHC index of the PTP clock, so FSL_ENETC_CORE depends on Kconfig
> > symbol "PTP_1588_CLOCK_OPTIONAL". But FSL_ENETC_CORE can only be
> > selected, so add the dependency to FSL_ENETC, FSL_ENETC_VF and
> > NXP_ENETC4. Perhaps the best approach would be to change
> > FSL_ENETC_CORE to a visible menu entry. Then make FSL_ENETC,
> > FSL_ENETC_VF, and
> > NXP_ENETC4 depend on it, but this is not the goal of this patch, so
> > this may be changed in the future.
>
> select PTP_1588_CLOCK_OPTIONAL in kconfig will simple this?

I did not find any other drivers select this symbol, and I looked the
help text of this symbol, it says "Drivers that can optionally use the
PTP_1588_CLOCK framework should depend on this symbol". It looks
like we'd better use "depend on" rather than "select".