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

[Sagi Maimon]

On Tue, Aug 25, 2026 at 7:38 PM Vadim Fedorenko
<vadim.fedorenko@xxxxxxxxx> wrote:
>
> On 20/08/2026 16:01, 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.
> >
> > 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.
>
> Well, we definitely don't want to copy code but rather reuse existing as
> much as possible. Looks like platform device is the way to go. Let's
> discuss the code.
>

Thanks - agreed on reusing the existing driver rather than duplicating
it, and good to hear the platform device approach looks acceptable.

On timing: the X2 Ethernet support depends on X2 board support in
ptp_ocp, which doesn't exist yet, and that in turn builds on the CPLD
programming work I currently have in flight for X1.  So the order will
be: finish the X1 CPLD series, then X2 board support, then the Ethernet
series - the axienet property/dma_dev changes together with the ptp_ocp
patch that uses them, as one series since it is all net-next.

I'd rather send them in that order than post Ethernet patches against a
board the driver doesn't know about yet.  Happy to share the Ethernet
code early as an RFC if it's useful for the architecture discussion in
the meantime.

Thanks,
Sagi