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

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

On 26/08/2026 08:41, Sagi Maimon wrote:
> On Tue, Aug 25, 2026 at 7:38 PM Vadim Fedorenko
> <vadim.fedorenko@linux.dev> 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