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

[Vadim Fedorenko <vadim.fedorenko@linux.dev>]

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.