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

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

[Sagi Maimon]

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.

Thanks,
Sagi Maimon

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

[Vadim Fedorenko]

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.

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@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.

Thanks,
Sagi

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@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