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

[Vadim Fedorenko]

On 26/08/2026 08:41, Sagi Maimon wrote:
> 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.

It's OK to send it once required code is landed