Re: [RFC] ptp: ocp: exposing the TimeCard X2 AXI Ethernet port - which approach?

[Sagi Maimon]

On Sun, Aug 30, 2026 at 5:05 PM Gupta, Suraj <suraj.gupta2@xxxxxxx> wrote:
>
> Hi Maimon,
>
> On 8/20/2026 8:31 PM, Sagi Maimon wrote:
> > Hi,
> >
> > Before posting patches I would like to check which of two approaches you would
> > prefer, since they differ a lot in how much code lands and where.
> >
> > The ADVA TimeCard X2 is a PCIe card whose FPGA image contains a Xilinx AXI
> > Ethernet MAC and an AXI DMA engine alongside the timing blocks ptp_ocp already
> > supports. We want to expose that Ethernet port as a netdevice.
> >
>
> Is AXI Ethernet being used for 1588 timestamping here?
>

No. The AXI Ethernet is a plain data path on this card. It does no 1588
timestamping, and this series neither adds nor touches any timestamping
support in axienet. It could be added later, as separate work.

> Could you please share the role of axienet in the TimeCard architecture,
> including:
>
> - Which timestamping device/IP is used

The FPGA clock/ToD block on the ptp_ocp side, disciplined by GNSS and the
local oscillator, not by network packets. That block is the PHC that
ptp_ocp registers. The MAC and AXI DMA sit at a separate register window
with no timestamp unit between them.

> - How timestamps are generated and handled

Not on this path at all -- there is no timestamp unit on the Ethernet
datapath to generate them.

> - How the driver interacts with the timestamping mechanism
>

It doesn't, and there is nothing in axienet for it to use: no
.get_ts_info, no .ndo_hwtstamp_get/set, and axienet_ioctl() only
forwards to phylink_mii_ioctl(). I mention this explicitly because the
Xilinx vendor tree's axienet does carry a hwtstamp/TSU path -- we are
not using, porting or touching it.

The scope here is only to expose the existing Ethernet port as a
netdevice by reusing the in-tree driver, rather than duplicating the MAC
and DMA logic inside ptp_ocp.

Thanks,
Sagi

> Regards,
> Suraj
>
> > Approach A - let xilinx_axienet drive it.
> >
> > ptp_ocp creates a platform device describing the two register windows and the
> > three MSI-X vectors, and xilinx_axienet binds to it. This is what ptp_ocp
> > already does for the Xilinx SPI and I2C cores on the same card, see
> > ptp_ocp_i2c_bus() and ptp_ocp_register_spi().
> >
> > There is no device tree, so a software node stands in for one: "phy-mode"
> > replaces a phy-handle, since the MAC is wired to the fabric internally with no
> > MDIO and no PHY, and a "fixed-link" child node pins the link at 1 Gbit/s full
> > duplex.
> >
> > This needs two things from xilinx_axienet:
> >
> >    1. Read its configuration through the generic device property API instead of
> >       the OF-specific one, so it can be described by a software node. On a
> >       device-tree system dev_fwnode() resolves to the OF fwnode and the reads
> >       land in the same OF code as today, so this is a no-op for existing users.
> >       It is also in line with the wider move from of_* to
> >       device_property_*/fwnode_*.
> >
> >    2. A dma_dev in struct axienet_local. Descriptors and buffers must be mapped
> >       against the device that masters the bus, which for a platform device
> >       created by a PCIe parent is that parent - a platform device does not
> >       inherit its parent's DMA ops or IOMMU domain. For every existing user
> >       dma_dev would equal dev, so no behavioural change.
> >
> > That comes to about 50 changed lines in xilinx_axienet and about 180 new lines
> > in ptp_ocp.
> >
> > Approach B - a separate driver under drivers/ptp.
> >
> > Reimplement the descriptor rings, NAPI and ethtool support against the same IP,
> > roughly 2500 lines, and share xilinx_axienet's register definitions out of
> > drivers/net/ethernet/xilinx/.
> >
> > We have both working. Approach A is tested on 7.0.0-rc1 with the card:
> >
> >    xilinx_axienet xilinx_axienet.512 eth0: configuring for
> > fixed/internal link mode
> >    xilinx_axienet xilinx_axienet.512 eth0: Link is Up - 1Gbps/Full -
> > flow control off
> >
> > ping at 0% loss, a 90 s bulk TCP transfer moving ~9000 packets each way with
> > zero errors and no TX timeouts, ethtool -S/-g/-c/-a all working, and clean
> > module unload and reload.
> >
> > We would much rather do A than maintain a duplicate of an existing driver, so
> > the questions are:
> >
> >    1. Is instantiating xilinx_axienet from a PCIe parent as a platform device
> >       acceptable, or would you prefer the driver split so the device can be
> >       created on the auxiliary bus? The platform device route keeps the change
> >       to xilinx_axienet small and matches what ptp_ocp already does for the SPI
> >       and I2C cores, but auxiliary bus is the more usual choice for sub-devices
> >       of a PCIe function and would make the DMA parent explicit.
> >
> >    2. For the dma_dev, we currently infer it by testing whether the parent is a
> >       PCI device. That is concise but implicit; we are happy to pass it in
> >       explicitly if you would prefer it were not inferred.
> >
> > I can post the series straight away if you would rather look at the code.
> >
> > Thanks,
> > Sagi Maimon
>