[PATCH net-next v7 00/14] net: lan966x: add support for PCIe FDMA

[PATCH net-next v7 00/14] net: lan966x: add support for PCIe FDMA

[Daniel Machon]

When lan966x operates as a PCIe endpoint, the driver currently uses
register-based I/O for frame injection and extraction. This approach is
functional but slow, topping out at around 33 Mbps on an Intel x86 host
with a lan966x PCIe card.

This series adds FDMA (Frame DMA) support for the PCIe path. When
operating as a PCIe endpoint, the internal FDMA engine on lan966x cannot
directly access host memory, so DMA buffers are allocated as contiguous
coherent memory and mapped through the PCIe Address Translation Unit
(ATU). The ATU provides outbound windows that translate internal FDMA
addresses to PCIe bus addresses, allowing the FDMA engine to read and
write host memory. Because the ATU requires contiguous address regions,
page_pool and normal per-page DMA mappings cannot be used. Instead,
frames are transferred using memcpy between the ATU-mapped buffers and
the network stack. With this, throughput increases from ~33 Mbps to
~620 Mbps for default MTU.

Patch 1 adds the shared drivers/net/ethernet/microchip/fdma/ directory
to the Sparx5 SoC MAINTAINERS entry.

Patches 2-3 prepare the shared FDMA library: patch 2 renames the
contiguous dataptr helpers for clarity, and patch 3 adds PCIe ATU
region management and coherent DMA allocation with ATU mapping.

Patches 4-7 refactor the lan966x FDMA code to support both platform
and PCIe paths: extracting the LLP register write into a helper,
exporting shared functions, introducing a dedicated device for DMA
operations, and adding an ops dispatch table selected at probe time.

Patches 8-9 harden the existing FDMA path for the PCIe endpoint
lifecycle: patch 8 clears latched FDMA error/interrupt stickies after
the switch reset so they don't assert as soon as interrupts are
enabled, and patch 9 adds a shutdown() callback that quiesces the
FDMA engine on host warm reboot (on the PCIe card the FDMA survives
host reset and would otherwise keep the shared INTx asserted into
the next probe).

Patch 10 adds the core PCIe FDMA implementation with RX/TX using
contiguous ATU-mapped buffers. Patches 11 and 12 extend it with MTU
change and XDP support respectively. XDP_PASS, XDP_TX, XDP_DROP and
XDP_ABORTED are supported; XDP_REDIRECT is deliberately not, because
the PCIe data path does not use page_pool.

Patches 13-14 update the lan966x PCI device tree overlay to extend the
cpu register mapping to cover the ATU register space and add the FDMA
interrupt.

Patches 1-12 touch MAINTAINERS and drivers/net/ethernet/microchip/, and
are for the netdev tree.

Patches 13-14 touch drivers/misc/lan966x_pci.dtso, and are for the
char-misc tree.

To: Andrew Lunn <andrew+netdev@lunn.ch>
To: David S. Miller <davem@davemloft.net>
To: Eric Dumazet <edumazet@google.com>
To: Jakub Kicinski <kuba@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>
To: Horatiu Vultur <horatiu.vultur@microchip.com>
To: Steen Hegelund <steen.hegelund@microchip.com>
To: UNGLinuxDriver@microchip.com
To: Alexei Starovoitov <ast@kernel.org>
To: Daniel Borkmann <daniel@iogearbox.net>
To: Jesper Dangaard Brouer <hawk@kernel.org>
To: John Fastabend <john.fastabend@gmail.com>
To: Stanislav Fomichev <sdf@fomichev.me>
To: Herve Codina <herve.codina@bootlin.com>
To: Arnd Bergmann <arnd@arndb.de>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Mohsin Bashir <mohsin.bashr@gmail.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: bpf@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org

Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
---
Changes in v7:

Mostly a response to the automated review of v6. The notable change is
that the resize-time MTU guards added in v6 are replaced by an advertised
limit. v6 rejected an oversized MTU inside lan966x_fdma_pci_resize() with
-ERANGE, which is late, and leaves dev->max_mtu advertising a range the
PCIe path cannot honour. v7 derives the maximum from the same constants
and publishes it in dev->max_mtu instead, so the core rejects the request
up front and both -ERANGE returns become unreachable and are removed.
Also, the shutdown() was refactored to not race with ndo's.

- PCIe: cap dev->max_mtu on the PCIe path (FDMA_PCI_MAX_MTU), derived
  from the contiguous ring having to fit one MAX_PAGE_ORDER block after
  padding to the ATU region granularity, and from db_size having to fit
  the 16-bit DCB DATAL field. On a 4KB-page, MAX_PAGE_ORDER=10 build that
  is MTU 15498. Both resize-time -ERANGE checks are removed with it.
- PCIe: factor the frame overhead into LAN966X_FDMA_OVERHEAD and use it
  for both the cap and lan966x_fdma_get_max_frame(), so it is not
  open-coded twice.
- PCIe: skip the resize while the FDMA is not initialised. The rings are
  built by lan966x_fdma_pci_init(), which runs after the netdevs are
  registered, so an MTU change in that window would dereference NULL.
- PCIe: comment why NAPI has to be enabled before the queues are woken in
  the MTU reload path.
- shutdown(): rework the quiesce ordering. Free the xtr, ana and FDMA
  irqs first so no source can assert INTx, mask ANA_ANAINTR whether or not
  the FDMA is in use, then disable NAPI, stop and detach the netdevs,
  disable the FDMA channels, clear the FDMA interrupt enables and unmap
  the ATU windows.
- ATU: document the alignment requirement and -EINVAL at
  fdma_pci_atu_region_map(), document at fdma_pci_atu_translate_addr()
  that the caller must quiesce DMA and the descriptor paths before
  unmapping a region, initialise the region bookkeeping explicitly in
  fdma_pci_atu_init(), and fix the comment on the upper limit register.
- Patch 3 commit message: drop the claim that the patch adds PCIe FDMA
  support; it adds the helpers the lan966x path later uses.

Reported by the v6 review and deliberately not fixed here, because the
code is pre-existing and the fixes want a Fixes: tag:

- register_netdev() and the FDMA irq request both happen before
  ops->fdma_init(), so an MTU change or a stale interrupt can reach an
  uninitialised FDMA. Pre-existing on the platform path; the fix is a
  reorder of the shared probe, which I will send against net. The skip
  above closes the MTU-change half on PCIe in the meantime.
- lan966x_hw_offload() frees the caller's skb and reports only a bool.
  Pre-existing, all three callers affected. Goes to net with
  Fixes: 6476f90aefaf.
- The platform XDP hook leaves the FCS in the window handed to the BPF
  program, while the PCIe hook strips it. Pre-existing. Goes to net with
  Fixes: 6a2159be7604.
- Link to v6: https://lore.kernel.org/r/20260909-lan966x-pci-fdma-v6-0-6f48dab9d671@microchip.com

Changes in v6:

The main change is a DMA bug on the PCIe path, found after enabling the
IOMMU on the test host. The rest is hardening and cleanup.

- New patch 6: use a dedicated device for DMA operations. On the PCIe
  path lan966x->dev is the platform device created by
  of_platform_default_populate(), which carries no iommus/dma-ranges of
  its own, so it is not the device the IOMMU has a domain for. DMA
  mapped against it lands outside the domain the endpoint's requester ID
  is associated with. With the IOMMU enabled, AMD-Vi reported
  IO_PAGE_FAULT for the endpoint and no traffic passed. All FDMA DMA now
  targets the real PCIe endpoint device. Retested with the IOMMU in
  translated (DMA-FQ) mode.
- ATU: serialise region allocation/free and ATU register access with a
  mutex.
- ATU: program the region limit per mapping (base_addr + size - 1)
  instead of the full region bound, and disable every region in
  fdma_pci_atu_init().
- ATU: return -ERANGE instead of -E2BIG when the requested size exceeds
  the region size, and clear fdma->atu_region on unmap.
- PCIe FDMA: check fdma_dcbs_init() and unwind the coherent allocation
  and the ATU mapping on failure.
- PCIe FDMA: drop the WARN_ON() on an out-of-range src_port; a malformed
  IFH should not be able to splat the host.
- Quiesce consistently in shutdown, deinit and the MTU reload: stop the
  netdev queues and NAPI before disabling the FDMA channels, and share
  one lan966x_fdma_tx_disable_netdev() helper instead of open-coding it
  per path.
- shutdown: also mask ANA_ANAINTR, which shares the PCIe INTx with the
  FDMA sources.
- MTU change: reject an MTU whose ring would not fit in a single
  MAX_PAGE_ORDER coherent block, and reject one whose db_size would be
  truncated by the 16-bit DCB DATAL field, rather than programming a
  wrong buffer length.
- Assign lan966x->ops directly in the ops dispatch patch, so that patch
  no longer adds a helper returning a single constant; PCI detection now
  derives from dma_dev and arrives with the PCIe implementation.
- ATU: reject a target address that is not aligned to the 64KB ATU region
  granularity, instead of programming a translation offset by the
  misalignment.
- Drop the CONFIG_MCHP_LAN966X_PCI guard around the fdma_pci.h include in
  fdma_api.h (Jakub).
- Use ifneq ($(CONFIG_MCHP_LAN966X_PCI),) instead of ifdef in both the fdma
  and lan966x Makefiles; the symbol is tristate, so the condition has to
  cover both y and m (Jakub).
- Reprogram the FDMA LLP registers on the platform reload restore path,
  which stopped happening when the LLP write moved into the allocation
  functions.
- XDP: drop the napi_synchronize() before freeing the old program on the
  PCIe path; READ_ONCE() on port->xdp_prog plus the RCU-deferred
  bpf_prog_put() already cover the in-flight poll.
- XDP: note that the ETH_ZLEN floor is deliberately not enforced on XDP_TX.
- PCIe FDMA: count tx_dropped when the DCB ring is full.
- PCIe FDMA: guard the deinit napi_disable() on fdma_ndev, as shutdown()
  already does; NAPI is only initialised on the first ndo_open.
- ATU: program the region translation before enabling the region.
- ATU: pad the mapped allocation to the 64KB outbound region granularity,
  so the window does not extend past the coherent allocation.
- ATU: reject mapping an fdma that already holds a region, instead of
  overwriting the handle and leaking the old mapping. The MTU reload clears
  the handle on the live rings first, since it keeps the old mapping alive
  until the new rings are in place.
- PCIe FDMA: declare the RX DCB DATAL as the space actually available to the
  extraction engine (db_size - XDP_PACKET_HEADROOM), since the data block
  pointer starts that far into the slot.
- Move the XDP-unsupported guards from the XDP patch into the PCIe FDMA
  patch, so that no intermediate commit advertises NETDEV_XDP_ACT_NDO_XMIT
  for a PCIe instance while tx->dcbs_buf is NULL, and none lets an XDP
  attach reach the platform page_pool reload. The final tree is unchanged.
- shutdown: take rtnl, so it cannot interleave with the rtnl-only reload
  paths and double-disable the NAPI, which would spin forever in
  napi_disable().
- Link to v5: https://lore.kernel.org/r/20260520-lan966x-pci-fdma-v5-0-ca56197ae05b@microchip.com

Changes in v5:

This version fixes a single AI review issue, flagged by Paolo. Other AI
issues  for v4 has been classified as pre-existing or changes for
follow-ups.

- Fix premature napi_complete_done() in lan966x_fdma_pci_napi_poll() on
  FDMA_ERROR and napi_alloc_skb() failure. Bailing out left DONE=1 DCBs
  in the ring with no IRQ to drain them. Drop the frame and continue
  the poll loop instead. Bump rx_dropped on memory-pressure drop.
  (Paolo)
- Link to v4: https://lore.kernel.org/r/20260508-lan966x-pci-fdma-v4-0-14e0c89d8d63@microchip.com

Changes in v4:
- Consolidate rx size checks into lan966x_fdma_pci_rx_size_fits().
  Subtract XDP_PACKET_HEADROOM on the max size check, and add ETH_HLEN
  on the min size check. This fixes potential OOB reads/writes.
- On xdp_prepare_buff(), update comment to clarify that data is already
  offset by XDP_PACKET_HEADROOM.
- Link to v3:
  https://lore.kernel.org/r/20260504-lan966x-pci-fdma-v3-0-a56f5740d870@microchip.com

Changes in v3:

Version 3 fixes a number of issues reported by sashiko - mostly
hardening.

- Fix double use of XDP_PACKET_HEADROOM.
- Fix ERR_PTR persistence in fdma->atu_region and add missing
  NULL/ERR_PTR guard in fdma_pci_atu_region_unmap().
- Reject size <= 0 in fdma_pci_atu_region_map() and return
  -ENOSPC (was -ENOMEM) when no region is free.
- Introduce lan966x_fdma_pci_tx_size_fits() that accounts for
  XDP_PACKET_HEADROOM; use it from both xmit paths to keep
  bpf_xdp_adjust_tail from writing past the TX slot.
- Validate BLOCKL in rx_check_frame() (reject < IFH+FCS or
  > db_size) before it feeds memcpy/XDP sizes.
- READ_ONCE(port->xdp_prog) inside lan966x_xdp_pci_run() to close
  a TOCTOU on XDP detach that could deref NULL in
  bpf_prog_run_xdp().
- Strip IFH and FCS pre-XDP in rx_check_frame(). After BPF runs
  the driver cannot tell whether the tail was modified; drop the
  unconditional skb_pull/skb_trim in rx_get_frame().
- Account tx_bytes/tx_packets on XDP_TX success and tx_dropped on
  XDP_TX size reject.
- Add dma_wmb()/dma_rmb() around DCB status writes and reads in
  xmit, xmit_xdpf, and napi_poll.
- Collected Tested-by: Hervé Codina.
- Link to v2: https://lore.kernel.org/r/20260428-lan966x-pci-fdma-v2-0-d3ec66e06202@microchip.com

Changes in v2:

Version 2 primarily addresses issues with module unload/load, where
traffic would stop working (Hervé), and XDP head/tail adjust that would be
discarded (Mohsin).

Apart from that, I ran through issues reported by Sashiko, and fixed a
number of other issues.

- New patch 1: add drivers/net/ethernet/microchip/fdma/ to the Sparx5
  SoC MAINTAINERS entry.
- New patch 7: clear latched FDMA error/interrupt stickies after the
  switch reset so they don't fire as soon as interrupts are enabled.
- New patch 8: shutdown() callback, quiescing FDMA on host warm reboot.
- Replaced the depth-2 dev_is_pci(parent->parent) backend selector
  with a parent-chain walk.
- XDP: use xdp.data/xdp.data_end for the post-XDP frame length so that
  bpf_xdp_adjust_head/tail are respected (Mohsin Bashir)
- MTU change: drain in-flight xmits with netif_tx_disable() on every
  port before reallocating rings, waking them again on completion.
- MTU change: cap the PCIe DCB ring at 256 entries so a full-ring
  coherent DMA allocation fits in a single MAX_PAGE_ORDER block at
  jumbo MTU.
- PCIe ATU: disable the region before clearing its translation on
  unmap.
- PCIe FDMA: hold tx_lock in napi_poll around the free-DCB check used
  to wake stopped netdev queues.
- PCIe FDMA: return -ENOSPC (not -1) when the DCB ring is exhausted.
- Link to v1: https://lore.kernel.org/r/20260320-lan966x-pci-fdma-v1-0-ef54cb9b0c4b@microchip.com

---
Daniel Machon (14):
      MAINTAINERS: add FDMA library to Sparx5 SoC entry
      net: microchip: fdma: rename contiguous dataptr helpers
      net: microchip: fdma: add PCIe ATU support
      net: lan966x: add FDMA LLP register write helper
      net: lan966x: export FDMA helpers for reuse
      net: lan966x: use a dedicated device for DMA operations
      net: lan966x: add FDMA ops dispatch for PCIe support
      net: lan966x: clear FDMA interrupt stickies after switch reset
      net: lan966x: add shutdown callback to stop the FDMA on reboot
      net: lan966x: add PCIe FDMA support
      net: lan966x: add PCIe FDMA MTU change support
      net: lan966x: add PCIe FDMA XDP support
      misc: lan966x-pci: dts: extend cpu reg to cover PCIE DBI space
      misc: lan966x-pci: dts: add fdma interrupt to overlay

 MAINTAINERS                                        |   1 +
 drivers/misc/lan966x_pci.dtso                      |   5 +-
 drivers/net/ethernet/microchip/fdma/Makefile       |   4 +
 drivers/net/ethernet/microchip/fdma/fdma_api.c     |  44 ++
 drivers/net/ethernet/microchip/fdma/fdma_api.h     |  22 +-
 drivers/net/ethernet/microchip/fdma/fdma_pci.c     | 208 ++++++
 drivers/net/ethernet/microchip/fdma/fdma_pci.h     |  57 ++
 drivers/net/ethernet/microchip/lan966x/Makefile    |   4 +
 .../net/ethernet/microchip/lan966x/lan966x_fdma.c  |  88 ++-
 .../ethernet/microchip/lan966x/lan966x_fdma_pci.c  | 695 +++++++++++++++++++++
 .../net/ethernet/microchip/lan966x/lan966x_main.c  | 121 +++-
 .../net/ethernet/microchip/lan966x/lan966x_main.h  |  69 ++
 .../net/ethernet/microchip/lan966x/lan966x_regs.h  |  25 +
 .../net/ethernet/microchip/lan966x/lan966x_xdp.c   |   6 +
 14 files changed, 1287 insertions(+), 62 deletions(-)
---
base-commit: 548b86839f7fb819a4d6c83b71c73ec378d24275
change-id: 20260313-lan966x-pci-fdma-94ed485d23fa

Best regards,
-- 
Daniel Machon <daniel.machon@microchip.com>

[PATCH net-next v7 01/14] MAINTAINERS: add FDMA library to Sparx5 SoC entry

[Daniel Machon]

The FDMA library under drivers/net/ethernet/microchip/fdma/ is shared by
the lan966x, sparx5 and lan969x drivers, but is not covered by an entry
in the MAINTAINERS file. A subsequent patch will add new files to the
FDMA library, so let's make sure it's covered.

Add drivers/net/ethernet/microchip/fdma/ to the Sparx5 SoC entry, since
I am already listed there.

Tested-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b23fb6f2f4ef..e41d4337136d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3214,6 +3214,7 @@ M:	UNGLinuxDriver@microchip.com
 L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
 S:	Supported
 F:	arch/arm64/boot/dts/microchip/sparx*
+F:	drivers/net/ethernet/microchip/fdma/
 F:	drivers/net/ethernet/microchip/vcap/
 F:	drivers/pinctrl/pinctrl-microchip-sgpio.c
 N:	sparx5

-- 
2.34.1

Re: [PATCH net-next v7 01/14] MAINTAINERS: add FDMA library to Sparx5 SoC entry

[Simon Horman]

On Fri, Sep 18, 2026 at 01:33:53PM +0200, Daniel Machon wrote:
> The FDMA library under drivers/net/ethernet/microchip/fdma/ is shared by
> the lan966x, sparx5 and lan969x drivers, but is not covered by an entry
> in the MAINTAINERS file. A subsequent patch will add new files to the
> FDMA library, so let's make sure it's covered.
> 
> Add drivers/net/ethernet/microchip/fdma/ to the Sparx5 SoC entry, since
> I am already listed there.
> 
> Tested-by: Herve Codina <herve.codina@bootlin.com>
> Signed-off-by: Daniel Machon <daniel.machon@microchip.com>

Reviewed-by: Simon Horman <horms@kernel.org>

[PATCH net-next v7 02/14] net: microchip: fdma: rename contiguous dataptr helpers

[Daniel Machon]

When the FDMA library was introduced [1], two helpers to get the DMA and
virtual address of a data buffer, in contiguous memory, were added. These
helpers have had no callers until this series. I found the naming I
initially used confusing and inconsistent.

Rename fdma_dataptr_get_contiguous() and
fdma_dataptr_virt_get_contiguous() to fdma_dataptr_dma_addr_contiguous()
and fdma_dataptr_virt_addr_contiguous(). This makes the pair symmetric
and clarifies what type of address each returns.

[1]: commit 30e48a75df9c ("net: microchip: add FDMA library")

Tested-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
---
 drivers/net/ethernet/microchip/fdma/fdma_api.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/microchip/fdma/fdma_api.h b/drivers/net/ethernet/microchip/fdma/fdma_api.h
index d91affe8bd98..dea8e3cc155a 100644
--- a/drivers/net/ethernet/microchip/fdma/fdma_api.h
+++ b/drivers/net/ethernet/microchip/fdma/fdma_api.h
@@ -197,8 +197,8 @@ static inline int fdma_nextptr_cb(struct fdma *fdma, int dcb_idx, u64 *nextptr)
  * if the dataptr addresses and DCB's are in contiguous memory and the driver
  * supports XDP.
  */
-static inline u64 fdma_dataptr_get_contiguous(struct fdma *fdma, int dcb_idx,
-					      int db_idx)
+static inline u64 fdma_dataptr_dma_addr_contiguous(struct fdma *fdma,
+						   int dcb_idx, int db_idx)
 {
 	return fdma->dma + (sizeof(struct fdma_dcb) * fdma->n_dcbs) +
 	       (dcb_idx * fdma->n_dbs + db_idx) * fdma->db_size +
@@ -209,8 +209,8 @@ static inline u64 fdma_dataptr_get_contiguous(struct fdma *fdma, int dcb_idx,
  * applicable if the dataptr addresses and DCB's are in contiguous memory and
  * the driver supports XDP.
  */
-static inline void *fdma_dataptr_virt_get_contiguous(struct fdma *fdma,
-						     int dcb_idx, int db_idx)
+static inline void *fdma_dataptr_virt_addr_contiguous(struct fdma *fdma,
+						      int dcb_idx, int db_idx)
 {
 	return (u8 *)fdma->dcbs + (sizeof(struct fdma_dcb) * fdma->n_dcbs) +
 	       (dcb_idx * fdma->n_dbs + db_idx) * fdma->db_size +

-- 
2.34.1

Re: [PATCH net-next v7 02/14] net: microchip: fdma: rename contiguous dataptr helpers

[Simon Horman]

On Fri, Sep 18, 2026 at 01:33:54PM +0200, Daniel Machon wrote:
> When the FDMA library was introduced [1], two helpers to get the DMA and
> virtual address of a data buffer, in contiguous memory, were added. These
> helpers have had no callers until this series. I found the naming I
> initially used confusing and inconsistent.
> 
> Rename fdma_dataptr_get_contiguous() and
> fdma_dataptr_virt_get_contiguous() to fdma_dataptr_dma_addr_contiguous()
> and fdma_dataptr_virt_addr_contiguous(). This makes the pair symmetric
> and clarifies what type of address each returns.
> 
> [1]: commit 30e48a75df9c ("net: microchip: add FDMA library")
> 
> Tested-by: Herve Codina <herve.codina@bootlin.com>
> Signed-off-by: Daniel Machon <daniel.machon@microchip.com>

Reviewed-by: Simon Horman <horms@kernel.org>

[PATCH net-next v7 03/14] net: microchip: fdma: add PCIe ATU support

[Daniel Machon]

When lan966x or lan969x operates as a PCIe endpoint, the internal FDMA
engine cannot directly access host memory. Instead, DMA addresses must
be translated through the PCIe Address Translation Unit (ATU). The ATU
provides outbound windows that map internal addresses to PCIe bus
addresses.

The ATU outbound address space (0x10000000-0x1fffffff) is divided into
six equally-sized regions (~42MB each). When FDMA buffers are allocated,
a free ATU region is claimed and programmed with the DMA target address.
The FDMA engine then uses the region's base address in its descriptors,
and the ATU translates these to the actual DMA addresses on the PCIe bus.

Add the required functions and helpers that combine the DMA allocation
with the ATU region mapping. These are used by the lan966x PCIe FDMA
path.

The ATU cannot express a limit finer than its 64KB region granularity,
so pad the mapped allocation to that boundary; otherwise the outbound
window would extend past the memory the host allocated for DMA.

This implementation will also be used by the lan969x, when PCIe FDMA is
added for that platform in the future.

Tested-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
---
 drivers/net/ethernet/microchip/fdma/Makefile   |   4 +
 drivers/net/ethernet/microchip/fdma/fdma_api.c |  44 ++++++
 drivers/net/ethernet/microchip/fdma/fdma_api.h |  14 ++
 drivers/net/ethernet/microchip/fdma/fdma_pci.c | 208 +++++++++++++++++++++++++
 drivers/net/ethernet/microchip/fdma/fdma_pci.h |  57 +++++++
 5 files changed, 327 insertions(+)

diff --git a/drivers/net/ethernet/microchip/fdma/Makefile b/drivers/net/ethernet/microchip/fdma/Makefile
index cc9a736be357..910a10b33fb9 100644
--- a/drivers/net/ethernet/microchip/fdma/Makefile
+++ b/drivers/net/ethernet/microchip/fdma/Makefile
@@ -5,3 +5,7 @@
 
 obj-$(CONFIG_FDMA) += fdma.o
 fdma-y += fdma_api.o
+
+ifneq ($(CONFIG_MCHP_LAN966X_PCI),)
+fdma-y += fdma_pci.o
+endif
diff --git a/drivers/net/ethernet/microchip/fdma/fdma_api.c b/drivers/net/ethernet/microchip/fdma/fdma_api.c
index e78c3590da9e..a3c9e3097c5c 100644
--- a/drivers/net/ethernet/microchip/fdma/fdma_api.c
+++ b/drivers/net/ethernet/microchip/fdma/fdma_api.c
@@ -127,6 +127,50 @@ void fdma_free_phys(struct fdma *fdma)
 }
 EXPORT_SYMBOL_GPL(fdma_free_phys);
 
+#if IS_ENABLED(CONFIG_MCHP_LAN966X_PCI)
+/* Allocate coherent DMA memory and map it in the ATU. */
+int fdma_alloc_coherent_and_map(struct device *dev, struct fdma *fdma,
+				struct fdma_pci_atu *atu)
+{
+	struct fdma_pci_atu_region *region;
+	int err;
+
+	if (WARN_ON(fdma->atu_region))
+		return -EBUSY;
+
+	/* The ATU cannot express a limit finer than the region granularity, so
+	 * the hardware widens the programmed limit to that boundary. Pad the
+	 * allocation to match, or the outbound window would extend past the
+	 * memory we own.
+	 */
+	fdma->size = ALIGN(fdma->size, FDMA_PCI_ATU_REGION_ALIGN);
+
+	err = fdma_alloc_coherent(dev, fdma);
+	if (err)
+		return err;
+
+	region = fdma_pci_atu_region_map(atu, fdma->dma, fdma->size);
+	if (IS_ERR(region)) {
+		fdma_free_coherent(dev, fdma);
+		return PTR_ERR(region);
+	}
+
+	fdma->atu_region = region;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(fdma_alloc_coherent_and_map);
+
+/* Free coherent DMA memory and unmap the memory in the ATU. */
+void fdma_free_coherent_and_unmap(struct device *dev, struct fdma *fdma)
+{
+	fdma_pci_atu_region_unmap(fdma->atu_region);
+	fdma->atu_region = NULL;
+	fdma_free_coherent(dev, fdma);
+}
+EXPORT_SYMBOL_GPL(fdma_free_coherent_and_unmap);
+#endif
+
 /* Get the size of the FDMA memory */
 u32 fdma_get_size(struct fdma *fdma)
 {
diff --git a/drivers/net/ethernet/microchip/fdma/fdma_api.h b/drivers/net/ethernet/microchip/fdma/fdma_api.h
index dea8e3cc155a..ccc30d506e89 100644
--- a/drivers/net/ethernet/microchip/fdma/fdma_api.h
+++ b/drivers/net/ethernet/microchip/fdma/fdma_api.h
@@ -7,6 +7,8 @@
 #include <linux/etherdevice.h>
 #include <linux/types.h>
 
+#include "fdma_pci.h"
+
 /* This provides a common set of functions and data structures for interacting
  * with the Frame DMA engine on multiple Microchip switchcores.
  *
@@ -109,6 +111,11 @@ struct fdma {
 	u32 channel_id;
 
 	struct fdma_ops ops;
+
+#if IS_ENABLED(CONFIG_MCHP_LAN966X_PCI)
+	/* PCI ATU region for this FDMA instance. */
+	struct fdma_pci_atu_region *atu_region;
+#endif
 };
 
 /* Advance the DCB index and wrap if required. */
@@ -233,9 +240,16 @@ int __fdma_dcb_add(struct fdma *fdma, int dcb_idx, u64 info, u64 status,
 
 int fdma_alloc_coherent(struct device *dev, struct fdma *fdma);
 int fdma_alloc_phys(struct fdma *fdma);
+#if IS_ENABLED(CONFIG_MCHP_LAN966X_PCI)
+int fdma_alloc_coherent_and_map(struct device *dev, struct fdma *fdma,
+				struct fdma_pci_atu *atu);
+#endif
 
 void fdma_free_coherent(struct device *dev, struct fdma *fdma);
 void fdma_free_phys(struct fdma *fdma);
+#if IS_ENABLED(CONFIG_MCHP_LAN966X_PCI)
+void fdma_free_coherent_and_unmap(struct device *dev, struct fdma *fdma);
+#endif
 
 u32 fdma_get_size(struct fdma *fdma);
 u32 fdma_get_size_contiguous(struct fdma *fdma);
diff --git a/drivers/net/ethernet/microchip/fdma/fdma_pci.c b/drivers/net/ethernet/microchip/fdma/fdma_pci.c
new file mode 100644
index 000000000000..dd1dc46cbc9d
--- /dev/null
+++ b/drivers/net/ethernet/microchip/fdma/fdma_pci.c
@@ -0,0 +1,208 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include <linux/align.h>
+#include <linux/errno.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/types.h>
+
+#include "fdma_pci.h"
+
+/* When the switch operates as a PCIe endpoint, the FDMA engine needs to
+ * DMA to/from host memory. The FDMA writes to addresses within the endpoint's
+ * internal Outbound (OB) address space, and the PCIe ATU translates these to
+ * DMA addresses on the PCIe bus, targeting host memory.
+ *
+ * The ATU supports up to six outbound regions. This implementation divides
+ * the OB address space into six equally sized chunks.
+ *
+ * +-------------+------------+------------+-----+------------+
+ * | Index       | Region 0   | Region 1   | ... | Region 5   |
+ * +-------------+------------+------------+-----+------------+
+ * | Base addr   | 0x10000000 | 0x12aa0000 | ... | 0x1d520000 |
+ * | Limit addr  | 0x12a9ffff | 0x1553ffff | ... | 0x1ffbffff |
+ * | Target addr | host dma   | host dma   | ... | host dma   |
+ * +-------------+------------+------------+-----+------------+
+ *
+ * Base addr is the start address of the region within the OB address space.
+ * Limit addr is each region's own upper bound. The value actually
+ * programmed is set per-mapping as base_addr + mapped size - 1, and is
+ * usually smaller than this.
+ * Target addr is the host DMA address that the base addr translates to.
+ */
+
+#define FDMA_PCI_ATU_OB_START        0x10000000
+#define FDMA_PCI_ATU_OB_END          0x1fffffff
+
+#define FDMA_PCI_ATU_ADDR            0x300000
+#define FDMA_PCI_ATU_IDX_SIZE        0x200
+#define FDMA_PCI_ATU_ENA_REG         0x4
+#define FDMA_PCI_ATU_ENA_BIT         BIT(31)
+#define FDMA_PCI_ATU_LWR_BASE_ADDR   0x8
+#define FDMA_PCI_ATU_UPP_BASE_ADDR   0xc
+#define FDMA_PCI_ATU_LIMIT_ADDR      0x10
+#define FDMA_PCI_ATU_LWR_TARGET_ADDR 0x14
+#define FDMA_PCI_ATU_UPP_TARGET_ADDR 0x18
+
+static u32 fdma_pci_atu_region_size(void)
+{
+	return round_down((FDMA_PCI_ATU_OB_END - FDMA_PCI_ATU_OB_START) /
+			  FDMA_PCI_ATU_REGION_MAX, FDMA_PCI_ATU_REGION_ALIGN);
+}
+
+static void __iomem *fdma_pci_atu_addr_get(void __iomem *addr, int offset,
+					   int idx)
+{
+	return addr + FDMA_PCI_ATU_ADDR + FDMA_PCI_ATU_IDX_SIZE * idx + offset;
+}
+
+static void fdma_pci_atu_region_enable(struct fdma_pci_atu_region *region)
+{
+	writel(FDMA_PCI_ATU_ENA_BIT,
+	       fdma_pci_atu_addr_get(region->atu->addr, FDMA_PCI_ATU_ENA_REG,
+				     region->idx));
+}
+
+static void fdma_pci_atu_region_disable(struct fdma_pci_atu_region *region)
+{
+	writel(0, fdma_pci_atu_addr_get(region->atu->addr, FDMA_PCI_ATU_ENA_REG,
+					region->idx));
+}
+
+/* Configure the address translation in the ATU. */
+static void
+fdma_pci_atu_configure_translation(struct fdma_pci_atu_region *region)
+{
+	struct fdma_pci_atu *atu = region->atu;
+	int idx = region->idx;
+
+	writel(lower_32_bits(region->base_addr),
+	       fdma_pci_atu_addr_get(atu->addr,
+				     FDMA_PCI_ATU_LWR_BASE_ADDR, idx));
+
+	writel(upper_32_bits(region->base_addr),
+	       fdma_pci_atu_addr_get(atu->addr,
+				     FDMA_PCI_ATU_UPP_BASE_ADDR, idx));
+
+	/* The OB address space lies entirely below 4GB, so the limit always
+	 * fits the lower limit register and the upper one is left alone.
+	 */
+	writel(region->limit_addr,
+	       fdma_pci_atu_addr_get(atu->addr, FDMA_PCI_ATU_LIMIT_ADDR, idx));
+
+	writel(lower_32_bits(region->target_addr),
+	       fdma_pci_atu_addr_get(atu->addr,
+				     FDMA_PCI_ATU_LWR_TARGET_ADDR, idx));
+
+	writel(upper_32_bits(region->target_addr),
+	       fdma_pci_atu_addr_get(atu->addr,
+				     FDMA_PCI_ATU_UPP_TARGET_ADDR, idx));
+}
+
+/* Find an unused ATU region. */
+static struct fdma_pci_atu_region *
+fdma_pci_atu_region_get_free(struct fdma_pci_atu *atu)
+{
+	struct fdma_pci_atu_region *regions = atu->regions;
+
+	for (int i = 0; i < FDMA_PCI_ATU_REGION_MAX; i++) {
+		if (regions[i].in_use)
+			continue;
+
+		return &regions[i];
+	}
+
+	return ERR_PTR(-ENOSPC);
+}
+
+/* Unmap an ATU region, clearing its translation and disabling it. */
+void fdma_pci_atu_region_unmap(struct fdma_pci_atu_region *region)
+{
+	if (IS_ERR_OR_NULL(region))
+		return;
+
+	mutex_lock(&region->atu->lock);
+
+	region->target_addr = 0;
+	region->in_use = false;
+
+	fdma_pci_atu_region_disable(region);
+	fdma_pci_atu_configure_translation(region);
+
+	mutex_unlock(&region->atu->lock);
+}
+EXPORT_SYMBOL_GPL(fdma_pci_atu_region_unmap);
+
+/* Map a host DMA address into a free outbound region. */
+struct fdma_pci_atu_region *
+fdma_pci_atu_region_map(struct fdma_pci_atu *atu, u64 target_addr, int size)
+{
+	struct fdma_pci_atu_region *region;
+
+	if (!atu)
+		return ERR_PTR(-EINVAL);
+
+	if (size <= 0)
+		return ERR_PTR(-EINVAL);
+
+	if (size > fdma_pci_atu_region_size())
+		return ERR_PTR(-ERANGE);
+
+	/* The ATU region base is only ever aligned to FDMA_PCI_ATU_REGION_ALIGN;
+	 * require the same alignment of the host target address, since the ATU
+	 * translates addr - target_addr + base_addr and any misalignment here
+	 * would shift every translated address by the same amount.
+	 */
+	if (!IS_ALIGNED(target_addr, FDMA_PCI_ATU_REGION_ALIGN))
+		return ERR_PTR(-EINVAL);
+
+	mutex_lock(&atu->lock);
+
+	region = fdma_pci_atu_region_get_free(atu);
+	if (IS_ERR(region)) {
+		mutex_unlock(&atu->lock);
+		return region;
+	}
+
+	region->target_addr = target_addr;
+	region->limit_addr = region->base_addr + size - 1;
+	region->in_use = true;
+
+	fdma_pci_atu_configure_translation(region);
+	fdma_pci_atu_region_enable(region);
+
+	mutex_unlock(&atu->lock);
+
+	return region;
+}
+EXPORT_SYMBOL_GPL(fdma_pci_atu_region_map);
+
+/* Translate a host DMA address to the corresponding OB address. */
+u64 fdma_pci_atu_translate_addr(struct fdma_pci_atu_region *region, u64 addr)
+{
+	return region->base_addr + (addr - region->target_addr);
+}
+EXPORT_SYMBOL_GPL(fdma_pci_atu_translate_addr);
+
+/* Initialize ATU, dividing the OB space into equally sized regions. */
+void fdma_pci_atu_init(struct fdma_pci_atu *atu, void __iomem *addr)
+{
+	struct fdma_pci_atu_region *regions = atu->regions;
+	u32 region_size = fdma_pci_atu_region_size();
+
+	atu->addr = addr;
+	mutex_init(&atu->lock);
+
+	for (int i = 0; i < FDMA_PCI_ATU_REGION_MAX; i++) {
+		regions[i].base_addr =
+			FDMA_PCI_ATU_OB_START + (i * region_size);
+		regions[i].limit_addr = 0;
+		regions[i].target_addr = 0;
+		regions[i].idx = i;
+		regions[i].atu = atu;
+		regions[i].in_use = false;
+
+		fdma_pci_atu_region_disable(&regions[i]);
+	}
+}
+EXPORT_SYMBOL_GPL(fdma_pci_atu_init);
diff --git a/drivers/net/ethernet/microchip/fdma/fdma_pci.h b/drivers/net/ethernet/microchip/fdma/fdma_pci.h
new file mode 100644
index 000000000000..010bdb4d50b0
--- /dev/null
+++ b/drivers/net/ethernet/microchip/fdma/fdma_pci.h
@@ -0,0 +1,57 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+#ifndef _FDMA_PCI_H_
+#define _FDMA_PCI_H_
+
+#include <linux/align.h>
+#include <linux/bits.h>
+#include <linux/mutex.h>
+#include <linux/types.h>
+
+#define FDMA_PCI_ATU_REGION_MAX 6
+
+/* Outbound regions are 64KB granular (datasheet section 3.24.7.4.1), so both
+ * the region base and the mapped size must be aligned to this.
+ */
+#define FDMA_PCI_ATU_REGION_ALIGN BIT(16)
+
+#define FDMA_PCI_DB_ALIGN 128
+#define FDMA_PCI_DB_SIZE(mtu) ALIGN(mtu, FDMA_PCI_DB_ALIGN)
+
+struct fdma_pci_atu;
+
+struct fdma_pci_atu_region {
+	struct fdma_pci_atu *atu;
+	u64 base_addr; /* Base addr of the OB window */
+	u64 limit_addr; /* End addr of the active mapping (base_addr + size - 1) */
+	u64 target_addr; /* Host DMA address this region maps to */
+	int idx;
+	bool in_use;
+};
+
+struct fdma_pci_atu {
+	void __iomem *addr;
+	struct mutex lock; /* Protects region alloc/free and ATU register access */
+	struct fdma_pci_atu_region regions[FDMA_PCI_ATU_REGION_MAX];
+};
+
+/* Initialize ATU, dividing OB space into regions. */
+void fdma_pci_atu_init(struct fdma_pci_atu *atu, void __iomem *addr);
+
+/* Unmap an ATU region, clearing its translation and disabling it. */
+void fdma_pci_atu_region_unmap(struct fdma_pci_atu_region *region);
+
+/* Map a host DMA address into a free ATU region. target_addr and size must be
+ * FDMA_PCI_ATU_REGION_ALIGN aligned; a misaligned target_addr returns -EINVAL.
+ */
+struct fdma_pci_atu_region *fdma_pci_atu_region_map(struct fdma_pci_atu *atu,
+						    u64 target_addr,
+						    int size);
+
+/* Translate a host DMA address to the OB address space. Reads the region
+ * unlocked, so the caller must quiesce DMA and the descriptor paths before
+ * unmapping the region.
+ */
+u64 fdma_pci_atu_translate_addr(struct fdma_pci_atu_region *region, u64 addr);
+
+#endif

-- 
2.34.1

Re: [PATCH net-next v7 03/14] net: microchip: fdma: add PCIe ATU support

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 4 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 3

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] fdma_pci_atu_region_map() programs base/limit/target and then
  issues the region-enable write (CTRL2 bit31) and returns immediately;…
- [Low] fdma_pci_atu_region_map()
  (drivers/net/ethernet/microchip/fdma/fdma_pci.c:138) validates that…
- [Low] fdma_pci_atu_configure_translation() programs lower/upper base
  (+0x8/+0xc), limit (+0x10) and lower/upper target (+0x14/+0x18), and…
- [Low] fdma_pci_atu_translate_addr() (fdma_pci.c:181) computes
  region->base_addr + (addr - region->target_addr) with no check that…

--

net: microchip: fdma: add PCIe ATU support

Adds a PCIe ATU layer for the Microchip FDMA engine so that a lan966x or
lan969x acting as a PCIe endpoint can reach host memory. The outbound
address space 0x10000000-0x1fffffff is split into six regions that are
claimed and programmed when FDMA buffers are allocated.

A few questions on the new ATU code below.

> diff --git a/drivers/net/ethernet/microchip/fdma/fdma_api.c b/drivers/net/ethernet/microchip/fdma/fdma_api.c
> index e78c3590da9e..a3c9e3097c5c 100644
> --- a/drivers/net/ethernet/microchip/fdma/fdma_api.c
> +++ b/drivers/net/ethernet/microchip/fdma/fdma_api.c
> @@ -127,6 +127,50 @@ void fdma_free_phys(struct fdma *fdma)
>  }
>  EXPORT_SYMBOL_GPL(fdma_free_phys);
>  
> +#if IS_ENABLED(CONFIG_MCHP_LAN966X_PCI)
> +/* Allocate coherent DMA memory and map it in the ATU. */
> +int fdma_alloc_coherent_and_map(struct device *dev, struct fdma *fdma,
> +				struct fdma_pci_atu *atu)
> +{
> +	struct fdma_pci_atu_region *region;
> +	int err;
> +
> +	if (WARN_ON(fdma->atu_region))
> +		return -EBUSY;
> +
> +	/* The ATU cannot express a limit finer than the region granularity, so
> +	 * the hardware widens the programmed limit to that boundary. Pad the
> +	 * allocation to match, or the outbound window would extend past the
> +	 * memory we own.
> +	 */
> +	fdma->size = ALIGN(fdma->size, FDMA_PCI_ATU_REGION_ALIGN);
> +
> +	err = fdma_alloc_coherent(dev, fdma);
> +	if (err)
> +		return err;
> +
> +	region = fdma_pci_atu_region_map(atu, fdma->dma, fdma->size);
> +	if (IS_ERR(region)) {
> +		fdma_free_coherent(dev, fdma);
> +		return PTR_ERR(region);
> +	}
> +
> +	fdma->atu_region = region;
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(fdma_alloc_coherent_and_map);
> +
> +/* Free coherent DMA memory and unmap the memory in the ATU. */
> +void fdma_free_coherent_and_unmap(struct device *dev, struct fdma *fdma)
> +{
> +	fdma_pci_atu_region_unmap(fdma->atu_region);
> +	fdma->atu_region = NULL;
> +	fdma_free_coherent(dev, fdma);
> +}
> +EXPORT_SYMBOL_GPL(fdma_free_coherent_and_unmap);
> +#endif

[ ... ]

> diff --git a/drivers/net/ethernet/microchip/fdma/fdma_pci.c b/drivers/net/ethernet/microchip/fdma/fdma_pci.c
> new file mode 100644
> index 000000000000..dd1dc46cbc9d
> --- /dev/null
> +++ b/drivers/net/ethernet/microchip/fdma/fdma_pci.c
> @@ -0,0 +1,208 @@

[ ... ]

> +#define FDMA_PCI_ATU_ADDR            0x300000
> +#define FDMA_PCI_ATU_IDX_SIZE        0x200
> +#define FDMA_PCI_ATU_ENA_REG         0x4
> +#define FDMA_PCI_ATU_ENA_BIT         BIT(31)
> +#define FDMA_PCI_ATU_LWR_BASE_ADDR   0x8
> +#define FDMA_PCI_ATU_UPP_BASE_ADDR   0xc
> +#define FDMA_PCI_ATU_LIMIT_ADDR      0x10
> +#define FDMA_PCI_ATU_LWR_TARGET_ADDR 0x14
> +#define FDMA_PCI_ATU_UPP_TARGET_ADDR 0x18

[ ... ]

> +/* Configure the address translation in the ATU. */
> +static void
> +fdma_pci_atu_configure_translation(struct fdma_pci_atu_region *region)
> +{
> +	struct fdma_pci_atu *atu = region->atu;
> +	int idx = region->idx;
> +
> +	writel(lower_32_bits(region->base_addr),
> +	       fdma_pci_atu_addr_get(atu->addr,
> +				     FDMA_PCI_ATU_LWR_BASE_ADDR, idx));
> +
> +	writel(upper_32_bits(region->base_addr),
> +	       fdma_pci_atu_addr_get(atu->addr,
> +				     FDMA_PCI_ATU_UPP_BASE_ADDR, idx));
> +
> +	/* The OB address space lies entirely below 4GB, so the limit always
> +	 * fits the lower limit register and the upper one is left alone.
> +	 */
> +	writel(region->limit_addr,
> +	       fdma_pci_atu_addr_get(atu->addr, FDMA_PCI_ATU_LIMIT_ADDR, idx));
> +
> +	writel(lower_32_bits(region->target_addr),
> +	       fdma_pci_atu_addr_get(atu->addr,
> +				     FDMA_PCI_ATU_LWR_TARGET_ADDR, idx));
> +
> +	writel(upper_32_bits(region->target_addr),
> +	       fdma_pci_atu_addr_get(atu->addr,
> +				     FDMA_PCI_ATU_UPP_TARGET_ADDR, idx));
> +}

[Severity: Low]
The offsets used here match the DesignWare unrolled iATU layout: block at
DBI + 0x300000, 0x200 stride per region, Control 2 at +0x4 with enable in
bit 31, base at +0x8/+0xc, limit at +0x10, target at +0x14/+0x18.

That layout also has a Control 1 register at +0x0 selecting the outbound
TLP type, the function number and the ECRC/TD bits, and it is never
written here. fdma_pci_atu_init() claims all six outbound regions and
only clears Control 2, so each region keeps whatever Control 1 value it
already held.

The generic driver for the same block always programs it explicitly
before enabling:

drivers/pci/controller/dwc/pcie-designware.c:dw_pcie_prog_outbound_atu() {
	...
	val = atu->type | atu->routing | PCIE_ATU_FUNC_NUM(atu->func_no);
	...
	dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL1, val);
	...
}

Is it safe to inherit Control 1 from whatever configured the outbound
windows before the driver probes, or should it be programmed for the
memory TLP type explicitly?

> +/* Map a host DMA address into a free outbound region. */
> +struct fdma_pci_atu_region *
> +fdma_pci_atu_region_map(struct fdma_pci_atu *atu, u64 target_addr, int size)
> +{
> +	struct fdma_pci_atu_region *region;
> +
> +	if (!atu)
> +		return ERR_PTR(-EINVAL);
> +
> +	if (size <= 0)
> +		return ERR_PTR(-EINVAL);
> +
> +	if (size > fdma_pci_atu_region_size())
> +		return ERR_PTR(-ERANGE);
> +
> +	/* The ATU region base is only ever aligned to FDMA_PCI_ATU_REGION_ALIGN;
> +	 * require the same alignment of the host target address, since the ATU
> +	 * translates addr - target_addr + base_addr and any misalignment here
> +	 * would shift every translated address by the same amount.
> +	 */
> +	if (!IS_ALIGNED(target_addr, FDMA_PCI_ATU_REGION_ALIGN))
> +		return ERR_PTR(-EINVAL);

[Severity: Low]
Should size also be checked against FDMA_PCI_ATU_REGION_ALIGN here?

fdma_pci.h documents the requirement for both arguments:

/* Outbound regions are 64KB granular (datasheet section 3.24.7.4.1), so both
 * the region base and the mapped size must be aligned to this.
 */

/* Map a host DMA address into a free ATU region. target_addr and size must be
 * FDMA_PCI_ATU_REGION_ALIGN aligned; a misaligned target_addr returns -EINVAL.
 */

but only target_addr is verified, and the unaligned value then goes
straight into the hardware limit:

	region->limit_addr = region->base_addr + size - 1;

Per the commit message the hardware widens that limit to the 64KB
boundary, so an unaligned size would leave the outbound window covering
up to 64KB - 1 beyond the buffer.

The single in-tree caller, fdma_alloc_coherent_and_map(), pads with
fdma->size = ALIGN(fdma->size, FDMA_PCI_ATU_REGION_ALIGN) before
allocating, so nothing can hit this today, but the invariant lives in the
caller while fdma_pci_atu_region_map() is exported. Would it make sense
to enforce it in the primitive too?

> +	mutex_lock(&atu->lock);
> +
> +	region = fdma_pci_atu_region_get_free(atu);
> +	if (IS_ERR(region)) {
> +		mutex_unlock(&atu->lock);
> +		return region;
> +	}
> +
> +	region->target_addr = target_addr;
> +	region->limit_addr = region->base_addr + size - 1;
> +	region->in_use = true;
> +
> +	fdma_pci_atu_configure_translation(region);
> +	fdma_pci_atu_region_enable(region);
> +
> +	mutex_unlock(&atu->lock);
> +
> +	return region;
> +}
> +EXPORT_SYMBOL_GPL(fdma_pci_atu_region_map);

[Severity: Medium]
Does the enable write need to be read back before the region is treated
as mapped?

fdma_pci_atu_region_enable() issues a posted write of bit 31 to Control 2
and fdma_pci_atu_region_map() returns immediately, so the caller can arm
the FDMA channel (later in the series
lan966x_fdma_pci_rx_alloc() programs the LLP with region->base_addr and
lan966x_fdma_rx_start() starts the channel) before the outbound window is
known to be live. There is also no way for the API to report a window
that never enables.

The generic driver for this register layout polls instead:

drivers/pci/controller/dwc/pcie-designware.c:dw_pcie_prog_outbound_atu() {
	...
	/*
	 * Make sure ATU enable takes effect before any subsequent config
	 * and I/O accesses.
	 */
	for (retries = 0; retries < LINK_WAIT_MAX_IATU_RETRIES; retries++) {
		val = dw_pcie_readl_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL2);
		if (val & PCIE_ATU_ENABLE)
			return 0;

		mdelay(LINK_WAIT_IATU);
	}
	...
	return -ETIMEDOUT;
}

The same applies in reverse on teardown: fdma_pci_atu_region_unmap()
issues the disable write and fdma_free_coherent_and_unmap() calls
fdma_free_coherent() right after, without confirming the window is down
before those pages go back to the allocator.

> +/* Translate a host DMA address to the corresponding OB address. */
> +u64 fdma_pci_atu_translate_addr(struct fdma_pci_atu_region *region, u64 addr)
> +{
> +	return region->base_addr + (addr - region->target_addr);
> +}
> +EXPORT_SYMBOL_GPL(fdma_pci_atu_translate_addr);

[Severity: Low]
Can this return an address belonging to a different region?

All six regions are contiguous slices of the same outbound space
(base_addr = 0x10000000 + i * region_size), and nothing here checks that
addr falls inside [target_addr, target_addr + mapped size) or that
region->in_use is still set. An address outside the mapping silently
lands in a neighbouring window and the FDMA would then read or write
another buffer's host target rather than failing.

fdma_pci_atu_region_unmap() also resets target_addr to 0 while leaving
base_addr alone:

	region->target_addr = 0;
	region->in_use = false;

so a translation on a released region returns base_addr + addr.

The in-tree users, lan966x_fdma_pci_dataptr_cb() and
lan966x_fdma_pci_nextptr_cb(), only pass offsets inside the mapped
buffer, and fdma_free_coherent_and_unmap() clears fdma->atu_region, so no
current path feeds a bad address. Since the region already stores
limit_addr, would a bounds and in_use assertion be worth adding?

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260918-lan966x-pci-fdma-v7-0-0ecc179c8a2c%40microchip.com

Re: [PATCH net-next v7 03/14] net: microchip: fdma: add PCIe ATU support

[Daniel Machon]

> Thank you for your contribution! Sashiko AI review found 4 potential
> issue(s) to consider.
> 
> Critical: 0 · High: 0 · Medium: 1 · Low: 3
> 
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
> 
> - [Medium] fdma_pci_atu_region_map() programs base/limit/target and then
>   issues the region-enable write (CTRL2 bit31) and returns immediately;…
> - [Low] fdma_pci_atu_region_map()
>   (drivers/net/ethernet/microchip/fdma/fdma_pci.c:138) validates that…
> - [Low] fdma_pci_atu_configure_translation() programs lower/upper base
>   (+0x8/+0xc), limit (+0x10) and lower/upper target (+0x14/+0x18), and…
> - [Low] fdma_pci_atu_translate_addr() (fdma_pci.c:181) computes
>   region->base_addr + (addr - region->target_addr) with no check that…
> 
> --
> 
> net: microchip: fdma: add PCIe ATU support
> 
> Adds a PCIe ATU layer for the Microchip FDMA engine so that a lan966x or
> lan969x acting as a PCIe endpoint can reach host memory. The outbound
> address space 0x10000000-0x1fffffff is split into six regions that are
> claimed and programmed when FDMA buffers are allocated.
> 
> A few questions on the new ATU code below.
> 
> > diff --git a/drivers/net/ethernet/microchip/fdma/fdma_api.c b/drivers/net/ethernet/microchip/fdma/fdma_api.c
> > index e78c3590da9e..a3c9e3097c5c 100644
> > --- a/drivers/net/ethernet/microchip/fdma/fdma_api.c
> > +++ b/drivers/net/ethernet/microchip/fdma/fdma_api.c
> > @@ -127,6 +127,50 @@ void fdma_free_phys(struct fdma *fdma)
> >  }
> >  EXPORT_SYMBOL_GPL(fdma_free_phys);
> >
> > +#if IS_ENABLED(CONFIG_MCHP_LAN966X_PCI)
> > +/* Allocate coherent DMA memory and map it in the ATU. */
> > +int fdma_alloc_coherent_and_map(struct device *dev, struct fdma *fdma,
> > +                             struct fdma_pci_atu *atu)
> > +{
> > +     struct fdma_pci_atu_region *region;
> > +     int err;
> > +
> > +     if (WARN_ON(fdma->atu_region))
> > +             return -EBUSY;
> > +
> > +     /* The ATU cannot express a limit finer than the region granularity, so
> > +      * the hardware widens the programmed limit to that boundary. Pad the
> > +      * allocation to match, or the outbound window would extend past the
> > +      * memory we own.
> > +      */
> > +     fdma->size = ALIGN(fdma->size, FDMA_PCI_ATU_REGION_ALIGN);
> > +
> > +     err = fdma_alloc_coherent(dev, fdma);
> > +     if (err)
> > +             return err;
> > +
> > +     region = fdma_pci_atu_region_map(atu, fdma->dma, fdma->size);
> > +     if (IS_ERR(region)) {
> > +             fdma_free_coherent(dev, fdma);
> > +             return PTR_ERR(region);
> > +     }
> > +
> > +     fdma->atu_region = region;
> > +
> > +     return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(fdma_alloc_coherent_and_map);
> > +
> > +/* Free coherent DMA memory and unmap the memory in the ATU. */
> > +void fdma_free_coherent_and_unmap(struct device *dev, struct fdma *fdma)
> > +{
> > +     fdma_pci_atu_region_unmap(fdma->atu_region);
> > +     fdma->atu_region = NULL;
> > +     fdma_free_coherent(dev, fdma);
> > +}
> > +EXPORT_SYMBOL_GPL(fdma_free_coherent_and_unmap);
> > +#endif
> 
> [ ... ]
> 
> > diff --git a/drivers/net/ethernet/microchip/fdma/fdma_pci.c b/drivers/net/ethernet/microchip/fdma/fdma_pci.c
> > new file mode 100644
> > index 000000000000..dd1dc46cbc9d
> > --- /dev/null
> > +++ b/drivers/net/ethernet/microchip/fdma/fdma_pci.c
> > @@ -0,0 +1,208 @@
> 
> [ ... ]
> 
> > +#define FDMA_PCI_ATU_ADDR            0x300000
> > +#define FDMA_PCI_ATU_IDX_SIZE        0x200
> > +#define FDMA_PCI_ATU_ENA_REG         0x4
> > +#define FDMA_PCI_ATU_ENA_BIT         BIT(31)
> > +#define FDMA_PCI_ATU_LWR_BASE_ADDR   0x8
> > +#define FDMA_PCI_ATU_UPP_BASE_ADDR   0xc
> > +#define FDMA_PCI_ATU_LIMIT_ADDR      0x10
> > +#define FDMA_PCI_ATU_LWR_TARGET_ADDR 0x14
> > +#define FDMA_PCI_ATU_UPP_TARGET_ADDR 0x18
> 
> [ ... ]
> 
> > +/* Configure the address translation in the ATU. */
> > +static void
> > +fdma_pci_atu_configure_translation(struct fdma_pci_atu_region *region)
> > +{
> > +     struct fdma_pci_atu *atu = region->atu;
> > +     int idx = region->idx;
> > +
> > +     writel(lower_32_bits(region->base_addr),
> > +            fdma_pci_atu_addr_get(atu->addr,
> > +                                  FDMA_PCI_ATU_LWR_BASE_ADDR, idx));
> > +
> > +     writel(upper_32_bits(region->base_addr),
> > +            fdma_pci_atu_addr_get(atu->addr,
> > +                                  FDMA_PCI_ATU_UPP_BASE_ADDR, idx));
> > +
> > +     /* The OB address space lies entirely below 4GB, so the limit always
> > +      * fits the lower limit register and the upper one is left alone.
> > +      */
> > +     writel(region->limit_addr,
> > +            fdma_pci_atu_addr_get(atu->addr, FDMA_PCI_ATU_LIMIT_ADDR, idx));
> > +
> > +     writel(lower_32_bits(region->target_addr),
> > +            fdma_pci_atu_addr_get(atu->addr,
> > +                                  FDMA_PCI_ATU_LWR_TARGET_ADDR, idx));
> > +
> > +     writel(upper_32_bits(region->target_addr),
> > +            fdma_pci_atu_addr_get(atu->addr,
> > +                                  FDMA_PCI_ATU_UPP_TARGET_ADDR, idx));
> > +}
> 
> [Severity: Low]
> The offsets used here match the DesignWare unrolled iATU layout: block at
> DBI + 0x300000, 0x200 stride per region, Control 2 at +0x4 with enable in
> bit 31, base at +0x8/+0xc, limit at +0x10, target at +0x14/+0x18.
> 
> That layout also has a Control 1 register at +0x0 selecting the outbound
> TLP type, the function number and the ECRC/TD bits, and it is never
> written here. fdma_pci_atu_init() claims all six outbound regions and
> only clears Control 2, so each region keeps whatever Control 1 value it
> already held.
> 
> The generic driver for the same block always programs it explicitly
> before enabling:
> 
> drivers/pci/controller/dwc/pcie-designware.c:dw_pcie_prog_outbound_atu() {
>         ...
>         val = atu->type | atu->routing | PCIE_ATU_FUNC_NUM(atu->func_no);
>         ...
>         dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL1, val);
>         ...
> }
> 
> Is it safe to inherit Control 1 from whatever configured the outbound
> windows before the driver probes, or should it be programmed for the
> memory TLP type explicitly?
> 
> > +/* Map a host DMA address into a free outbound region. */
> > +struct fdma_pci_atu_region *
> > +fdma_pci_atu_region_map(struct fdma_pci_atu *atu, u64 target_addr, int size)
> > +{
> > +     struct fdma_pci_atu_region *region;
> > +
> > +     if (!atu)
> > +             return ERR_PTR(-EINVAL);
> > +
> > +     if (size <= 0)
> > +             return ERR_PTR(-EINVAL);
> > +
> > +     if (size > fdma_pci_atu_region_size())
> > +             return ERR_PTR(-ERANGE);
> > +
> > +     /* The ATU region base is only ever aligned to FDMA_PCI_ATU_REGION_ALIGN;
> > +      * require the same alignment of the host target address, since the ATU
> > +      * translates addr - target_addr + base_addr and any misalignment here
> > +      * would shift every translated address by the same amount.
> > +      */
> > +     if (!IS_ALIGNED(target_addr, FDMA_PCI_ATU_REGION_ALIGN))
> > +             return ERR_PTR(-EINVAL);
> 
> [Severity: Low]
> Should size also be checked against FDMA_PCI_ATU_REGION_ALIGN here?
> 
> fdma_pci.h documents the requirement for both arguments:
> 
> /* Outbound regions are 64KB granular (datasheet section 3.24.7.4.1), so both
>  * the region base and the mapped size must be aligned to this.
>  */
> 
> /* Map a host DMA address into a free ATU region. target_addr and size must be
>  * FDMA_PCI_ATU_REGION_ALIGN aligned; a misaligned target_addr returns -EINVAL.
>  */
> 
> but only target_addr is verified, and the unaligned value then goes
> straight into the hardware limit:
> 
>         region->limit_addr = region->base_addr + size - 1;
> 
> Per the commit message the hardware widens that limit to the 64KB
> boundary, so an unaligned size would leave the outbound window covering
> up to 64KB - 1 beyond the buffer.
> 
> The single in-tree caller, fdma_alloc_coherent_and_map(), pads with
> fdma->size = ALIGN(fdma->size, FDMA_PCI_ATU_REGION_ALIGN) before
> allocating, so nothing can hit this today, but the invariant lives in the
> caller while fdma_pci_atu_region_map() is exported. Would it make sense
> to enforce it in the primitive too?
> 
> > +     mutex_lock(&atu->lock);
> > +
> > +     region = fdma_pci_atu_region_get_free(atu);
> > +     if (IS_ERR(region)) {
> > +             mutex_unlock(&atu->lock);
> > +             return region;
> > +     }
> > +
> > +     region->target_addr = target_addr;
> > +     region->limit_addr = region->base_addr + size - 1;
> > +     region->in_use = true;
> > +
> > +     fdma_pci_atu_configure_translation(region);
> > +     fdma_pci_atu_region_enable(region);
> > +
> > +     mutex_unlock(&atu->lock);
> > +
> > +     return region;
> > +}
> > +EXPORT_SYMBOL_GPL(fdma_pci_atu_region_map);
> 
> [Severity: Medium]
> Does the enable write need to be read back before the region is treated
> as mapped?
> 
> fdma_pci_atu_region_enable() issues a posted write of bit 31 to Control 2
> and fdma_pci_atu_region_map() returns immediately, so the caller can arm
> the FDMA channel (later in the series
> lan966x_fdma_pci_rx_alloc() programs the LLP with region->base_addr and
> lan966x_fdma_rx_start() starts the channel) before the outbound window is
> known to be live. There is also no way for the API to report a window
> that never enables.
> 
> The generic driver for this register layout polls instead:
> 
> drivers/pci/controller/dwc/pcie-designware.c:dw_pcie_prog_outbound_atu() {
>         ...
>         /*
>          * Make sure ATU enable takes effect before any subsequent config
>          * and I/O accesses.
>          */
>         for (retries = 0; retries < LINK_WAIT_MAX_IATU_RETRIES; retries++) {
>                 val = dw_pcie_readl_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL2);
>                 if (val & PCIE_ATU_ENABLE)
>                         return 0;
> 
>                 mdelay(LINK_WAIT_IATU);
>         }
>         ...
>         return -ETIMEDOUT;
> }

Issue addressed and dismissed in v6 - same finding, unchanged.

> 
> The same applies in reverse on teardown: fdma_pci_atu_region_unmap()
> issues the disable write and fdma_free_coherent_and_unmap() calls
> fdma_free_coherent() right after, without confirming the window is down
> before those pages go back to the allocator.
> 
> > +/* Translate a host DMA address to the corresponding OB address. */
> > +u64 fdma_pci_atu_translate_addr(struct fdma_pci_atu_region *region, u64 addr)
> > +{
> > +     return region->base_addr + (addr - region->target_addr);
> > +}
> > +EXPORT_SYMBOL_GPL(fdma_pci_atu_translate_addr);
> 
> [Severity: Low]
> Can this return an address belonging to a different region?
> 
> All six regions are contiguous slices of the same outbound space
> (base_addr = 0x10000000 + i * region_size), and nothing here checks that
> addr falls inside [target_addr, target_addr + mapped size) or that
> region->in_use is still set. An address outside the mapping silently
> lands in a neighbouring window and the FDMA would then read or write
> another buffer's host target rather than failing.
> 
> fdma_pci_atu_region_unmap() also resets target_addr to 0 while leaving
> base_addr alone:
> 
>         region->target_addr = 0;
>         region->in_use = false;
> 
> so a translation on a released region returns base_addr + addr.
> 
> The in-tree users, lan966x_fdma_pci_dataptr_cb() and
> lan966x_fdma_pci_nextptr_cb(), only pass offsets inside the mapped
> buffer, and fdma_free_coherent_and_unmap() clears fdma->atu_region, so no
> current path feeds a bad address. Since the region already stores
> limit_addr, would a bounds and in_use assertion be worth adding?
> 
> [ ... ]
> 
> --
> Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260918-lan966x-pci-fdma-v7-0-0ecc179c8a2c%40microchip.com

Re: [PATCH net-next v7 03/14] net: microchip: fdma: add PCIe ATU support

[Simon Horman]

On Fri, Sep 18, 2026 at 01:33:55PM +0200, Daniel Machon wrote:
> When lan966x or lan969x operates as a PCIe endpoint, the internal FDMA
> engine cannot directly access host memory. Instead, DMA addresses must
> be translated through the PCIe Address Translation Unit (ATU). The ATU
> provides outbound windows that map internal addresses to PCIe bus
> addresses.
> 
> The ATU outbound address space (0x10000000-0x1fffffff) is divided into
> six equally-sized regions (~42MB each). When FDMA buffers are allocated,
> a free ATU region is claimed and programmed with the DMA target address.
> The FDMA engine then uses the region's base address in its descriptors,
> and the ATU translates these to the actual DMA addresses on the PCIe bus.
> 
> Add the required functions and helpers that combine the DMA allocation
> with the ATU region mapping. These are used by the lan966x PCIe FDMA
> path.
> 
> The ATU cannot express a limit finer than its 64KB region granularity,
> so pad the mapped allocation to that boundary; otherwise the outbound
> window would extend past the memory the host allocated for DMA.
> 
> This implementation will also be used by the lan969x, when PCIe FDMA is
> added for that platform in the future.
> 
> Tested-by: Herve Codina <herve.codina@bootlin.com>
> Signed-off-by: Daniel Machon <daniel.machon@microchip.com>

Reviewed-by: Simon Horman <horms@kernel.org>

[PATCH net-next v7 04/14] net: lan966x: add FDMA LLP register write helper

[Daniel Machon]

The FDMA Link List Pointer (LLP) register points to the first DCB in the
chain and must be written before the channel is activated. This tells
the FDMA engine where to begin DMA transfers.

Move the LLP register writes from the channel start/activate functions
into the allocation functions and introduce a shared
lan966x_fdma_llp_configure() helper. This is needed because the upcoming
PCIe FDMA path writes ATU-translated addresses to the LLP registers
instead of DMA addresses. Keeping the writes in the shared
start/activate path would overwrite these translated addresses.

Tested-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
---
 .../net/ethernet/microchip/lan966x/lan966x_fdma.c  | 30 ++++++++++------------
 1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
index 41d4ec7f2f57..b8344fd5e5ad 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
@@ -109,6 +109,13 @@ static int lan966x_fdma_rx_alloc_page_pool(struct lan966x_rx *rx)
 	return 0;
 }
 
+static void lan966x_fdma_llp_configure(struct lan966x *lan966x, u64 addr,
+				       u8 channel_id)
+{
+	lan_wr(lower_32_bits(addr), lan966x, FDMA_DCB_LLP(channel_id));
+	lan_wr(upper_32_bits(addr), lan966x, FDMA_DCB_LLP1(channel_id));
+}
+
 static int lan966x_fdma_rx_alloc(struct lan966x_rx *rx)
 {
 	struct lan966x *lan966x = rx->lan966x;
@@ -128,6 +135,8 @@ static int lan966x_fdma_rx_alloc(struct lan966x_rx *rx)
 	fdma_dcbs_init(fdma, FDMA_DCB_INFO_DATAL(fdma->db_size),
 		       FDMA_DCB_STATUS_INTR);
 
+	lan966x_fdma_llp_configure(lan966x, fdma->dma, fdma->channel_id);
+
 	return 0;
 }
 
@@ -137,14 +146,6 @@ static void lan966x_fdma_rx_start(struct lan966x_rx *rx)
 	struct fdma *fdma = &rx->fdma;
 	u32 mask;
 
-	/* When activating a channel, first is required to write the first DCB
-	 * address and then to activate it
-	 */
-	lan_wr(lower_32_bits((u64)fdma->dma), lan966x,
-	       FDMA_DCB_LLP(fdma->channel_id));
-	lan_wr(upper_32_bits((u64)fdma->dma), lan966x,
-	       FDMA_DCB_LLP1(fdma->channel_id));
-
 	lan_wr(FDMA_CH_CFG_CH_DCB_DB_CNT_SET(fdma->n_dbs) |
 	       FDMA_CH_CFG_CH_INTR_DB_EOF_ONLY_SET(1) |
 	       FDMA_CH_CFG_CH_INJ_PORT_SET(0) |
@@ -215,6 +216,8 @@ static int lan966x_fdma_tx_alloc(struct lan966x_tx *tx)
 
 	fdma_dcbs_init(fdma, 0, 0);
 
+	lan966x_fdma_llp_configure(lan966x, fdma->dma, fdma->channel_id);
+
 	return 0;
 
 out:
@@ -236,14 +239,6 @@ static void lan966x_fdma_tx_activate(struct lan966x_tx *tx)
 	struct fdma *fdma = &tx->fdma;
 	u32 mask;
 
-	/* When activating a channel, first is required to write the first DCB
-	 * address and then to activate it
-	 */
-	lan_wr(lower_32_bits((u64)fdma->dma), lan966x,
-	       FDMA_DCB_LLP(fdma->channel_id));
-	lan_wr(upper_32_bits((u64)fdma->dma), lan966x,
-	       FDMA_DCB_LLP1(fdma->channel_id));
-
 	lan_wr(FDMA_CH_CFG_CH_DCB_DB_CNT_SET(fdma->n_dbs) |
 	       FDMA_CH_CFG_CH_INTR_DB_EOF_ONLY_SET(1) |
 	       FDMA_CH_CFG_CH_INJ_PORT_SET(0) |
@@ -876,6 +871,9 @@ static int lan966x_fdma_reload(struct lan966x *lan966x, int new_mtu)
 					   MEM_TYPE_PAGE_POOL, page_pool);
 	}
 
+	lan966x_fdma_llp_configure(lan966x, lan966x->rx.fdma.dma,
+				   lan966x->rx.fdma.channel_id);
+
 	lan966x_fdma_rx_start(&lan966x->rx);
 
 	lan966x_fdma_wakeup_netdev(lan966x);

-- 
2.34.1

Re: [PATCH net-next v7 04/14] net: lan966x: add FDMA LLP register write helper

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider.

Critical: 0 · High: 0 (1) · Medium: 1 · Low: 1

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] By moving the FDMA_DCB_LLP/LLP1 writes out of
  lan966x_fdma_tx_activate() into lan966x_fdma_tx_alloc()…
- [Low] The patch deletes the comment 'When activating a channel, first
  is required to write the first DCB address and then to activate it'…

Pre-existing issues:
- [High] lan966x_fdma_rx_alloc() (lan966x_fdma.c:135) and
  lan966x_fdma_tx_alloc() (line 217) discard the return value of…

--

net: lan966x: add FDMA LLP register write helper

This moves the FDMA_DCB_LLP/LLP1 register writes out of
lan966x_fdma_rx_start() and lan966x_fdma_tx_activate() into the RX/TX
allocation functions, adding a shared lan966x_fdma_llp_configure() helper
plus one extra call in the lan966x_fdma_reload() restore path.  The stated
motivation is that the upcoming PCIe FDMA path programs ATU-translated
addresses into these registers.

A few questions below.

> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
> index 41d4ec7f2f57..b8344fd5e5ad 100644
> --- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
> @@ -109,6 +109,13 @@ static int lan966x_fdma_rx_alloc_page_pool(struct lan966x_rx *rx)
>  	return 0;
>  }
>  
> +static void lan966x_fdma_llp_configure(struct lan966x *lan966x, u64 addr,
> +				       u8 channel_id)
> +{
> +	lan_wr(lower_32_bits(addr), lan966x, FDMA_DCB_LLP(channel_id));
> +	lan_wr(upper_32_bits(addr), lan966x, FDMA_DCB_LLP1(channel_id));
> +}
> +
>  static int lan966x_fdma_rx_alloc(struct lan966x_rx *rx)
>  {
>  	struct lan966x *lan966x = rx->lan966x;
> @@ -128,6 +135,8 @@ static int lan966x_fdma_rx_alloc(struct lan966x_rx *rx)
>  	fdma_dcbs_init(fdma, FDMA_DCB_INFO_DATAL(fdma->db_size),
>  		       FDMA_DCB_STATUS_INTR);
>  
> +	lan966x_fdma_llp_configure(lan966x, fdma->dma, fdma->channel_id);
> +
>  	return 0;
>  }

[Severity: High]
This isn't a bug introduced by this patch, but since the new LLP write now
sits right after it: should lan966x_fdma_rx_alloc() check the return value
of fdma_dcbs_init() before arming the channel?

fdma_dcbs_init() is fallible and stops at the first failing descriptor:

drivers/net/ethernet/microchip/fdma/fdma_api.c:fdma_dcbs_init() {
	for (i = 0; i < fdma->n_dcbs; i++) {
		err = fdma_dcb_add(fdma, i, info, status);
		if (err)
			return err;
	}
}

and lan966x_fdma_rx_dataptr_cb() returns -ENOMEM when
page_pool_dev_alloc_pages() fails, without updating rx->page[dcb][db] or
*dataptr.  So under memory pressure the chain is left truncated, the
remaining DB dataptrs stay 0, and rx->page[] keeps its previous contents
while this function still returns 0 and now also programs the LLP.

In lan966x_fdma_reload() the success branch then runs, which releases every
page in old_pages to the old pool and calls page_pool_destroy(page_pool)
while rx->page[] still references those pages.  A later
lan966x_fdma_rx_free_pages() at deinit, or on the next MTU change, would
then call page_pool_put_full_page() on pages already returned to a
destroyed pool.  In the probe path the same suppressed failure leaves NULL
entries in rx->page[] that lan966x_fdma_rx_free_pages() dereferences
unconditionally.

RX would also stall, since the software dcb_index wraps modulo n_dcbs while
the hardware only walks the truncated part of the ring.

Interestingly the PCIe variant added later in this series does check the
same call, so would it make sense to propagate the error here as well?

> @@ -137,14 +146,6 @@ static void lan966x_fdma_rx_start(struct lan966x_rx *rx)
>  	struct fdma *fdma = &rx->fdma;
>  	u32 mask;
>  
> -	/* When activating a channel, first is required to write the first DCB
> -	 * address and then to activate it
> -	 */
> -	lan_wr(lower_32_bits((u64)fdma->dma), lan966x,
> -	       FDMA_DCB_LLP(fdma->channel_id));
> -	lan_wr(upper_32_bits((u64)fdma->dma), lan966x,
> -	       FDMA_DCB_LLP1(fdma->channel_id));
> -
>  	lan_wr(FDMA_CH_CFG_CH_DCB_DB_CNT_SET(fdma->n_dbs) |
>  	       FDMA_CH_CFG_CH_INTR_DB_EOF_ONLY_SET(1) |
>  	       FDMA_CH_CFG_CH_INJ_PORT_SET(0) |

[Severity: Low]
This isn't a bug, but the comment documenting the hardware ordering rule
("first is required to write the first DCB address and then to activate
it") is removed from both lan966x_fdma_rx_start() and
lan966x_fdma_tx_activate(), and is not restated at
lan966x_fdma_llp_configure() or at either FDMA_CH_ACTIVATE site.

The requirement becomes an implicit contract between the allocation and
activation functions, which is what forces the extra open-coded call in the
lan966x_fdma_reload() restore path below.  Could the rule be documented at
the helper, or near the FDMA_CH_ACTIVATE writes?

All activation paths in the current tree do have a matching LLP write
before them, so this is only about the lost documentation.

Also, the commit message says the writes are moved "into the allocation
functions", but a third call site is added in lan966x_fdma_reload(), which
is not an allocation function.  Could that be mentioned as well?

> @@ -215,6 +216,8 @@ static int lan966x_fdma_tx_alloc(struct lan966x_tx *tx)
>  
>  	fdma_dcbs_init(fdma, 0, 0);
>  
> +	lan966x_fdma_llp_configure(lan966x, fdma->dma, fdma->channel_id);
> +
>  	return 0;
>  
>  out:

[Severity: High]
This is the same pre-existing unchecked fdma_dcbs_init() described above,
on the TX side; it is not introduced by this patch, but the new LLP write
and the unconditional "return 0" now follow it directly.

> @@ -236,14 +239,6 @@ static void lan966x_fdma_tx_activate(struct lan966x_tx *tx)
>  	struct fdma *fdma = &tx->fdma;
>  	u32 mask;
>  
> -	/* When activating a channel, first is required to write the first DCB
> -	 * address and then to activate it
> -	 */
> -	lan_wr(lower_32_bits((u64)fdma->dma), lan966x,
> -	       FDMA_DCB_LLP(fdma->channel_id));
> -	lan_wr(upper_32_bits((u64)fdma->dma), lan966x,
> -	       FDMA_DCB_LLP1(fdma->channel_id));
> -
>  	lan_wr(FDMA_CH_CFG_CH_DCB_DB_CNT_SET(fdma->n_dbs) |
>  	       FDMA_CH_CFG_CH_INTR_DB_EOF_ONLY_SET(1) |
>  	       FDMA_CH_CFG_CH_INJ_PORT_SET(0) |

[Severity: Medium]
Can the injection channel now be activated before the LLP has been
programmed during probe?

lan966x_probe() sets lan966x->fdma = true before the port loop that calls
lan966x_probe_port() -> register_netdev(), and only calls
lan966x_fdma_init() afterwards.  lan966x_port_xmit() dispatches purely on
that flag:

drivers/net/ethernet/microchip/lan966x/lan966x_main.c:lan966x_port_xmit() {
	spin_lock(&lan966x->tx_lock);
	if (port->lan966x->fdma)
		err = lan966x_fdma_xmit(skb, ifh, dev);
	...
}

lan966x_fdma_init() sets tx.fdma.n_dcbs/n_dbs and the ops before calling
lan966x_fdma_tx_alloc(), and lan966x_fdma_tx_alloc() does not take
tx_lock.  So an xmit landing between fdma_dcbs_init() and the new
lan966x_fdma_llp_configure() would find a valid dcbs_buf and DCB ring and
go:

lan966x_fdma_xmit() -> lan966x_fdma_tx_start() -> lan966x_fdma_tx_activate()

which after this patch writes FDMA_CH_ACTIVATE without programming the
LLP, so the engine would fetch its first DCB from the post-reset LLP value
of 0.  tx->activated is latched true there, so the LLP would never be
programmed for that channel afterwards:

	if (likely(lan966x->tx.activated)) {
		lan966x_fdma_tx_reload(tx);
	} else {
		/* Because it is first time, then just activate */
		lan966x->tx.activated = true;
		lan966x_fdma_tx_activate(tx);
	}

Before this patch tx_activate() wrote the LLP immediately before the
activate bit, so this ordering was not possible.  Note the same probe
window already exposes a pre-existing tx->dcbs_buf == NULL dereference in
lan966x_fdma_get_next_dcb() while n_dcbs is already set, so would
registering the netdevs after lan966x_fdma_init() be the better fix?

> @@ -876,6 +871,9 @@ static int lan966x_fdma_reload(struct lan966x *lan966x, int new_mtu)
>  					   MEM_TYPE_PAGE_POOL, page_pool);
>  	}
>  
> +	lan966x_fdma_llp_configure(lan966x, lan966x->rx.fdma.dma,
> +				   lan966x->rx.fdma.channel_id);
> +
>  	lan966x_fdma_rx_start(&lan966x->rx);
>  
>  	lan966x_fdma_wakeup_netdev(lan966x);

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260918-lan966x-pci-fdma-v7-0-0ecc179c8a2c%40microchip.com

Re: [PATCH net-next v7 04/14] net: lan966x: add FDMA LLP register write helper

[Daniel Machon]

> Thank you for your contribution! Sashiko AI review found 2 potential
> issue(s) to consider.
> 
> Critical: 0 · High: 0 (1) · Medium: 1 · Low: 1
> 
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
> 
> - [Medium] By moving the FDMA_DCB_LLP/LLP1 writes out of
>   lan966x_fdma_tx_activate() into lan966x_fdma_tx_alloc()…
> - [Low] The patch deletes the comment 'When activating a channel, first
>   is required to write the first DCB address and then to activate it'…
> 
> Pre-existing issues:
> - [High] lan966x_fdma_rx_alloc() (lan966x_fdma.c:135) and
>   lan966x_fdma_tx_alloc() (line 217) discard the return value of…
> 
> --
> 
> net: lan966x: add FDMA LLP register write helper
> 
> This moves the FDMA_DCB_LLP/LLP1 register writes out of
> lan966x_fdma_rx_start() and lan966x_fdma_tx_activate() into the RX/TX
> allocation functions, adding a shared lan966x_fdma_llp_configure() helper
> plus one extra call in the lan966x_fdma_reload() restore path.  The stated
> motivation is that the upcoming PCIe FDMA path programs ATU-translated
> addresses into these registers.
> 
> A few questions below.
> 
> > diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
> > index 41d4ec7f2f57..b8344fd5e5ad 100644
> > --- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
> > +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
> > @@ -109,6 +109,13 @@ static int lan966x_fdma_rx_alloc_page_pool(struct lan966x_rx *rx)
> >       return 0;
> >  }
> >
> > +static void lan966x_fdma_llp_configure(struct lan966x *lan966x, u64 addr,
> > +                                    u8 channel_id)
> > +{
> > +     lan_wr(lower_32_bits(addr), lan966x, FDMA_DCB_LLP(channel_id));
> > +     lan_wr(upper_32_bits(addr), lan966x, FDMA_DCB_LLP1(channel_id));
> > +}
> > +
> >  static int lan966x_fdma_rx_alloc(struct lan966x_rx *rx)
> >  {
> >       struct lan966x *lan966x = rx->lan966x;
> > @@ -128,6 +135,8 @@ static int lan966x_fdma_rx_alloc(struct lan966x_rx *rx)
> >       fdma_dcbs_init(fdma, FDMA_DCB_INFO_DATAL(fdma->db_size),
> >                      FDMA_DCB_STATUS_INTR);
> >
> > +     lan966x_fdma_llp_configure(lan966x, fdma->dma, fdma->channel_id);
> > +
> >       return 0;
> >  }
> 
> [Severity: High]
> This isn't a bug introduced by this patch, but since the new LLP write now
> sits right after it: should lan966x_fdma_rx_alloc() check the return value
> of fdma_dcbs_init() before arming the channel?
> 
> fdma_dcbs_init() is fallible and stops at the first failing descriptor:
> 
> drivers/net/ethernet/microchip/fdma/fdma_api.c:fdma_dcbs_init() {
>         for (i = 0; i < fdma->n_dcbs; i++) {
>                 err = fdma_dcb_add(fdma, i, info, status);
>                 if (err)
>                         return err;
>         }
> }
> 
> and lan966x_fdma_rx_dataptr_cb() returns -ENOMEM when
> page_pool_dev_alloc_pages() fails, without updating rx->page[dcb][db] or
> *dataptr.  So under memory pressure the chain is left truncated, the
> remaining DB dataptrs stay 0, and rx->page[] keeps its previous contents
> while this function still returns 0 and now also programs the LLP.
> 
> In lan966x_fdma_reload() the success branch then runs, which releases every
> page in old_pages to the old pool and calls page_pool_destroy(page_pool)
> while rx->page[] still references those pages.  A later
> lan966x_fdma_rx_free_pages() at deinit, or on the next MTU change, would
> then call page_pool_put_full_page() on pages already returned to a
> destroyed pool.  In the probe path the same suppressed failure leaves NULL
> entries in rx->page[] that lan966x_fdma_rx_free_pages() dereferences
> unconditionally.
> 
> RX would also stall, since the software dcb_index wraps modulo n_dcbs while
> the hardware only walks the truncated part of the ring.
> 
> Interestingly the PCIe variant added later in this series does check the
> same call, so would it make sense to propagate the error here as well?
> 
> > @@ -137,14 +146,6 @@ static void lan966x_fdma_rx_start(struct lan966x_rx *rx)
> >       struct fdma *fdma = &rx->fdma;
> >       u32 mask;
> >
> > -     /* When activating a channel, first is required to write the first DCB
> > -      * address and then to activate it
> > -      */
> > -     lan_wr(lower_32_bits((u64)fdma->dma), lan966x,
> > -            FDMA_DCB_LLP(fdma->channel_id));
> > -     lan_wr(upper_32_bits((u64)fdma->dma), lan966x,
> > -            FDMA_DCB_LLP1(fdma->channel_id));
> > -
> >       lan_wr(FDMA_CH_CFG_CH_DCB_DB_CNT_SET(fdma->n_dbs) |
> >              FDMA_CH_CFG_CH_INTR_DB_EOF_ONLY_SET(1) |
> >              FDMA_CH_CFG_CH_INJ_PORT_SET(0) |
> 
> [Severity: Low]
> This isn't a bug, but the comment documenting the hardware ordering rule
> ("first is required to write the first DCB address and then to activate
> it") is removed from both lan966x_fdma_rx_start() and
> lan966x_fdma_tx_activate(), and is not restated at
> lan966x_fdma_llp_configure() or at either FDMA_CH_ACTIVATE site.
> 
> The requirement becomes an implicit contract between the allocation and
> activation functions, which is what forces the extra open-coded call in the
> lan966x_fdma_reload() restore path below.  Could the rule be documented at
> the helper, or near the FDMA_CH_ACTIVATE writes?
> 
> All activation paths in the current tree do have a matching LLP write
> before them, so this is only about the lost documentation.
> 
> Also, the commit message says the writes are moved "into the allocation
> functions", but a third call site is added in lan966x_fdma_reload(), which
> is not an allocation function.  Could that be mentioned as well?
> 
> > @@ -215,6 +216,8 @@ static int lan966x_fdma_tx_alloc(struct lan966x_tx *tx)
> >
> >       fdma_dcbs_init(fdma, 0, 0);
> >
> > +     lan966x_fdma_llp_configure(lan966x, fdma->dma, fdma->channel_id);
> > +
> >       return 0;
> >
> >  out:
> 
> [Severity: High]
> This is the same pre-existing unchecked fdma_dcbs_init() described above,
> on the TX side; it is not introduced by this patch, but the new LLP write
> and the unconditional "return 0" now follow it directly.
> 
> > @@ -236,14 +239,6 @@ static void lan966x_fdma_tx_activate(struct lan966x_tx *tx)
> >       struct fdma *fdma = &tx->fdma;
> >       u32 mask;
> >
> > -     /* When activating a channel, first is required to write the first DCB
> > -      * address and then to activate it
> > -      */
> > -     lan_wr(lower_32_bits((u64)fdma->dma), lan966x,
> > -            FDMA_DCB_LLP(fdma->channel_id));
> > -     lan_wr(upper_32_bits((u64)fdma->dma), lan966x,
> > -            FDMA_DCB_LLP1(fdma->channel_id));
> > -
> >       lan_wr(FDMA_CH_CFG_CH_DCB_DB_CNT_SET(fdma->n_dbs) |
> >              FDMA_CH_CFG_CH_INTR_DB_EOF_ONLY_SET(1) |
> >              FDMA_CH_CFG_CH_INJ_PORT_SET(0) |
> 
> [Severity: Medium]
> Can the injection channel now be activated before the LLP has been
> programmed during probe?
> 
> lan966x_probe() sets lan966x->fdma = true before the port loop that calls
> lan966x_probe_port() -> register_netdev(), and only calls
> lan966x_fdma_init() afterwards.  lan966x_port_xmit() dispatches purely on
> that flag:
> 
> drivers/net/ethernet/microchip/lan966x/lan966x_main.c:lan966x_port_xmit() {
>         spin_lock(&lan966x->tx_lock);
>         if (port->lan966x->fdma)
>                 err = lan966x_fdma_xmit(skb, ifh, dev);
>         ...
> }
> 
> lan966x_fdma_init() sets tx.fdma.n_dcbs/n_dbs and the ops before calling
> lan966x_fdma_tx_alloc(), and lan966x_fdma_tx_alloc() does not take
> tx_lock.  So an xmit landing between fdma_dcbs_init() and the new
> lan966x_fdma_llp_configure() would find a valid dcbs_buf and DCB ring and
> go:
> 
> lan966x_fdma_xmit() -> lan966x_fdma_tx_start() -> lan966x_fdma_tx_activate()
> 
> which after this patch writes FDMA_CH_ACTIVATE without programming the
> LLP, so the engine would fetch its first DCB from the post-reset LLP value
> of 0.  tx->activated is latched true there, so the LLP would never be
> programmed for that channel afterwards:
> 
>         if (likely(lan966x->tx.activated)) {
>                 lan966x_fdma_tx_reload(tx);
>         } else {
>                 /* Because it is first time, then just activate */
>                 lan966x->tx.activated = true;
>                 lan966x_fdma_tx_activate(tx);
>         }
> 
> Before this patch tx_activate() wrote the LLP immediately before the
> activate bit, so this ordering was not possible.  Note the same probe
> window already exposes a pre-existing tx->dcbs_buf == NULL dereference in
> lan966x_fdma_get_next_dcb() while n_dcbs is already set, so would
> registering the netdevs after lan966x_fdma_init() be the better fix?

Netdev registration should be done last, yes - and that is the fix that should
go to net (as mentioned in v6). The probe window is real, but not something
introduced by this series.

> 
> > @@ -876,6 +871,9 @@ static int lan966x_fdma_reload(struct lan966x *lan966x, int new_mtu)
> >                                          MEM_TYPE_PAGE_POOL, page_pool);
> >       }
> >
> > +     lan966x_fdma_llp_configure(lan966x, lan966x->rx.fdma.dma,
> > +                                lan966x->rx.fdma.channel_id);
> > +
> >       lan966x_fdma_rx_start(&lan966x->rx);
> >
> >       lan966x_fdma_wakeup_netdev(lan966x);
> 
> --
> Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260918-lan966x-pci-fdma-v7-0-0ecc179c8a2c%40microchip.com

Re: [PATCH net-next v7 04/14] net: lan966x: add FDMA LLP register write helper

[Simon Horman]

On Fri, Sep 18, 2026 at 01:33:56PM +0200, Daniel Machon wrote:
> The FDMA Link List Pointer (LLP) register points to the first DCB in the
> chain and must be written before the channel is activated. This tells
> the FDMA engine where to begin DMA transfers.
> 
> Move the LLP register writes from the channel start/activate functions
> into the allocation functions and introduce a shared
> lan966x_fdma_llp_configure() helper. This is needed because the upcoming
> PCIe FDMA path writes ATU-translated addresses to the LLP registers
> instead of DMA addresses. Keeping the writes in the shared
> start/activate path would overwrite these translated addresses.
> 
> Tested-by: Herve Codina <herve.codina@bootlin.com>
> Signed-off-by: Daniel Machon <daniel.machon@microchip.com>

Reviewed-by: Simon Horman <horms@kernel.org>

[PATCH net-next v7 05/14] net: lan966x: export FDMA helpers for reuse

[Daniel Machon]

Make shared FDMA helpers non-static, so they can be reused by the PCIe
FDMA implementation.

Tested-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
---
 .../net/ethernet/microchip/lan966x/lan966x_fdma.c  | 22 +++++++++++-----------
 .../net/ethernet/microchip/lan966x/lan966x_main.h  | 11 +++++++++++
 2 files changed, 22 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
index b8344fd5e5ad..1311b79bd11f 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
@@ -109,8 +109,8 @@ static int lan966x_fdma_rx_alloc_page_pool(struct lan966x_rx *rx)
 	return 0;
 }
 
-static void lan966x_fdma_llp_configure(struct lan966x *lan966x, u64 addr,
-				       u8 channel_id)
+void lan966x_fdma_llp_configure(struct lan966x *lan966x, u64 addr,
+				u8 channel_id)
 {
 	lan_wr(lower_32_bits(addr), lan966x, FDMA_DCB_LLP(channel_id));
 	lan_wr(upper_32_bits(addr), lan966x, FDMA_DCB_LLP1(channel_id));
@@ -140,7 +140,7 @@ static int lan966x_fdma_rx_alloc(struct lan966x_rx *rx)
 	return 0;
 }
 
-static void lan966x_fdma_rx_start(struct lan966x_rx *rx)
+void lan966x_fdma_rx_start(struct lan966x_rx *rx)
 {
 	struct lan966x *lan966x = rx->lan966x;
 	struct fdma *fdma = &rx->fdma;
@@ -171,7 +171,7 @@ static void lan966x_fdma_rx_start(struct lan966x_rx *rx)
 		lan966x, FDMA_CH_ACTIVATE);
 }
 
-static void lan966x_fdma_rx_disable(struct lan966x_rx *rx)
+void lan966x_fdma_rx_disable(struct lan966x_rx *rx)
 {
 	struct lan966x *lan966x = rx->lan966x;
 	struct fdma *fdma = &rx->fdma;
@@ -191,7 +191,7 @@ static void lan966x_fdma_rx_disable(struct lan966x_rx *rx)
 		lan966x, FDMA_CH_DB_DISCARD);
 }
 
-static void lan966x_fdma_rx_reload(struct lan966x_rx *rx)
+void lan966x_fdma_rx_reload(struct lan966x_rx *rx)
 {
 	struct lan966x *lan966x = rx->lan966x;
 
@@ -264,7 +264,7 @@ static void lan966x_fdma_tx_activate(struct lan966x_tx *tx)
 		lan966x, FDMA_CH_ACTIVATE);
 }
 
-static void lan966x_fdma_tx_disable(struct lan966x_tx *tx)
+void lan966x_fdma_tx_disable(struct lan966x_tx *tx)
 {
 	struct lan966x *lan966x = tx->lan966x;
 	struct fdma *fdma = &tx->fdma;
@@ -296,7 +296,7 @@ static void lan966x_fdma_tx_reload(struct lan966x_tx *tx)
 		lan966x, FDMA_CH_RELOAD);
 }
 
-static void lan966x_fdma_wakeup_netdev(struct lan966x *lan966x)
+void lan966x_fdma_wakeup_netdev(struct lan966x *lan966x)
 {
 	struct lan966x_port *port;
 	int i;
@@ -470,7 +470,7 @@ static struct sk_buff *lan966x_fdma_rx_get_frame(struct lan966x_rx *rx,
 	return NULL;
 }
 
-static int lan966x_fdma_napi_poll(struct napi_struct *napi, int weight)
+int lan966x_fdma_napi_poll(struct napi_struct *napi, int weight)
 {
 	struct lan966x *lan966x = container_of(napi, struct lan966x, napi);
 	struct lan966x_rx *rx = &lan966x->rx;
@@ -583,7 +583,7 @@ static int lan966x_fdma_get_next_dcb(struct lan966x_tx *tx)
 	return -1;
 }
 
-static void lan966x_fdma_tx_start(struct lan966x_tx *tx)
+void lan966x_fdma_tx_start(struct lan966x_tx *tx)
 {
 	struct lan966x *lan966x = tx->lan966x;
 
@@ -801,7 +801,7 @@ static int lan966x_fdma_get_max_mtu(struct lan966x *lan966x)
 	return max_mtu;
 }
 
-static int lan966x_qsys_sw_status(struct lan966x *lan966x)
+int lan966x_qsys_sw_status(struct lan966x *lan966x)
 {
 	return lan_rd(lan966x, QSYS_SW_STATUS(CPU_PORT));
 }
@@ -883,7 +883,7 @@ static int lan966x_fdma_reload(struct lan966x *lan966x, int new_mtu)
 	return err;
 }
 
-static int lan966x_fdma_get_max_frame(struct lan966x *lan966x)
+int lan966x_fdma_get_max_frame(struct lan966x *lan966x)
 {
 	return lan966x_fdma_get_max_mtu(lan966x) +
 	       IFH_LEN_BYTES +
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.h b/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
index eea286c29474..83c361abb789 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
@@ -561,6 +561,17 @@ int lan966x_fdma_init(struct lan966x *lan966x);
 void lan966x_fdma_deinit(struct lan966x *lan966x);
 irqreturn_t lan966x_fdma_irq_handler(int irq, void *args);
 int lan966x_fdma_reload_page_pool(struct lan966x *lan966x);
+int lan966x_fdma_napi_poll(struct napi_struct *napi, int weight);
+void lan966x_fdma_llp_configure(struct lan966x *lan966x, u64 addr,
+				u8 channel_id);
+void lan966x_fdma_rx_start(struct lan966x_rx *rx);
+void lan966x_fdma_rx_disable(struct lan966x_rx *rx);
+void lan966x_fdma_rx_reload(struct lan966x_rx *rx);
+void lan966x_fdma_tx_start(struct lan966x_tx *tx);
+void lan966x_fdma_tx_disable(struct lan966x_tx *tx);
+void lan966x_fdma_wakeup_netdev(struct lan966x *lan966x);
+int lan966x_fdma_get_max_frame(struct lan966x *lan966x);
+int lan966x_qsys_sw_status(struct lan966x *lan966x);
 
 int lan966x_lag_port_join(struct lan966x_port *port,
 			  struct net_device *brport_dev,

-- 
2.34.1

Re: [PATCH net-next v7 05/14] net: lan966x: export FDMA helpers for reuse

[Simon Horman]

On Fri, Sep 18, 2026 at 01:33:57PM +0200, Daniel Machon wrote:
> Make shared FDMA helpers non-static, so they can be reused by the PCIe
> FDMA implementation.
> 
> Tested-by: Herve Codina <herve.codina@bootlin.com>
> Signed-off-by: Daniel Machon <daniel.machon@microchip.com>

Reviewed-by: Simon Horman <horms@kernel.org>

[PATCH net-next v7 06/14] net: lan966x: use a dedicated device for DMA operations

[Daniel Machon]

In preparation for the PCIe FDMA implementation, add lan966x->dma_dev,
resolved once at probe time, and use it for every DMA operation the
FDMA path performs: coherent allocations, streaming mappings and the RX
page pool. Natively, dma_dev is lan966x->dev, so there is no functional
change.

Since dma_dev differs from dev only on the PCIe path, add
lan966x_is_pci() on top of it, for the later PCIe patches to key off.

Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
---
 .../net/ethernet/microchip/lan966x/lan966x_fdma.c  | 30 +++++++++++-----------
 .../net/ethernet/microchip/lan966x/lan966x_main.c  | 16 ++++++++++++
 .../net/ethernet/microchip/lan966x/lan966x_main.h  | 10 ++++++++
 3 files changed, 41 insertions(+), 15 deletions(-)

diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
index 1311b79bd11f..15fc59cb4ad7 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
@@ -80,7 +80,7 @@ static int lan966x_fdma_rx_alloc_page_pool(struct lan966x_rx *rx)
 		.flags = PP_FLAG_DMA_MAP | PP_FLAG_DMA_SYNC_DEV,
 		.pool_size = rx->fdma.n_dcbs,
 		.nid = NUMA_NO_NODE,
-		.dev = lan966x->dev,
+		.dev = lan966x->dma_dev,
 		.dma_dir = DMA_FROM_DEVICE,
 		.offset = XDP_PACKET_HEADROOM,
 		.max_len = rx->max_mtu -
@@ -126,7 +126,7 @@ static int lan966x_fdma_rx_alloc(struct lan966x_rx *rx)
 	if (err)
 		return err;
 
-	err = fdma_alloc_coherent(lan966x->dev, fdma);
+	err = fdma_alloc_coherent(lan966x->dma_dev, fdma);
 	if (err) {
 		page_pool_destroy(rx->page_pool);
 		return err;
@@ -210,7 +210,7 @@ static int lan966x_fdma_tx_alloc(struct lan966x_tx *tx)
 	if (!tx->dcbs_buf)
 		return -ENOMEM;
 
-	err = fdma_alloc_coherent(lan966x->dev, fdma);
+	err = fdma_alloc_coherent(lan966x->dma_dev, fdma);
 	if (err)
 		goto out;
 
@@ -230,7 +230,7 @@ static void lan966x_fdma_tx_free(struct lan966x_tx *tx)
 	struct lan966x *lan966x = tx->lan966x;
 
 	kfree(tx->dcbs_buf);
-	fdma_free_coherent(lan966x->dev, &tx->fdma);
+	fdma_free_coherent(lan966x->dma_dev, &tx->fdma);
 }
 
 static void lan966x_fdma_tx_activate(struct lan966x_tx *tx)
@@ -355,7 +355,7 @@ static void lan966x_fdma_tx_clear_buf(struct lan966x *lan966x, int weight)
 
 		dcb_buf->used = false;
 		if (dcb_buf->use_skb) {
-			dma_unmap_single(lan966x->dev,
+			dma_unmap_single(lan966x->dma_dev,
 					 dcb_buf->dma_addr,
 					 dcb_buf->len,
 					 DMA_TO_DEVICE);
@@ -364,7 +364,7 @@ static void lan966x_fdma_tx_clear_buf(struct lan966x *lan966x, int weight)
 				napi_consume_skb(dcb_buf->data.skb, weight);
 		} else {
 			if (dcb_buf->xdp_ndo)
-				dma_unmap_single(lan966x->dev,
+				dma_unmap_single(lan966x->dma_dev,
 						 dcb_buf->dma_addr,
 						 dcb_buf->len,
 						 DMA_TO_DEVICE);
@@ -400,7 +400,7 @@ static int lan966x_fdma_rx_check_frame(struct lan966x_rx *rx, u64 *src_port)
 	if (unlikely(!page))
 		return FDMA_ERROR;
 
-	dma_sync_single_for_cpu(lan966x->dev,
+	dma_sync_single_for_cpu(lan966x->dma_dev,
 				(dma_addr_t)db->dataptr + XDP_PACKET_HEADROOM,
 				FDMA_DCB_STATUS_BLOCKL(db->status),
 				DMA_FROM_DEVICE);
@@ -635,11 +635,11 @@ int lan966x_fdma_xmit_xdpf(struct lan966x_port *port, void *ptr, u32 len)
 		lan966x_ifh_set_bypass(ifh, 1);
 		lan966x_ifh_set_port(ifh, BIT_ULL(port->chip_port));
 
-		dma_addr = dma_map_single(lan966x->dev,
+		dma_addr = dma_map_single(lan966x->dma_dev,
 					  xdpf->data - IFH_LEN_BYTES,
 					  xdpf->len + IFH_LEN_BYTES,
 					  DMA_TO_DEVICE);
-		if (dma_mapping_error(lan966x->dev, dma_addr)) {
+		if (dma_mapping_error(lan966x->dma_dev, dma_addr)) {
 			ret = NETDEV_TX_OK;
 			goto out;
 		}
@@ -655,7 +655,7 @@ int lan966x_fdma_xmit_xdpf(struct lan966x_port *port, void *ptr, u32 len)
 		lan966x_ifh_set_port(ifh, BIT_ULL(port->chip_port));
 
 		dma_addr = page_pool_get_dma_addr(page);
-		dma_sync_single_for_device(lan966x->dev,
+		dma_sync_single_for_device(lan966x->dma_dev,
 					   dma_addr + XDP_PACKET_HEADROOM,
 					   len + IFH_LEN_BYTES,
 					   DMA_TO_DEVICE);
@@ -734,9 +734,9 @@ int lan966x_fdma_xmit(struct sk_buff *skb, __be32 *ifh, struct net_device *dev)
 	memcpy(skb->data, ifh, IFH_LEN_BYTES);
 	skb_put(skb, 4);
 
-	dma_addr = dma_map_single(lan966x->dev, skb->data, skb->len,
+	dma_addr = dma_map_single(lan966x->dma_dev, skb->data, skb->len,
 				  DMA_TO_DEVICE);
-	if (dma_mapping_error(lan966x->dev, dma_addr)) {
+	if (dma_mapping_error(lan966x->dma_dev, dma_addr)) {
 		dev->stats.tx_dropped++;
 		err = NETDEV_TX_OK;
 		goto release;
@@ -842,7 +842,7 @@ static int lan966x_fdma_reload(struct lan966x *lan966x, int new_mtu)
 			page_pool_put_full_page(page_pool,
 						old_pages[i][j], false);
 
-	fdma_free_coherent(lan966x->dev, &fdma_rx_old);
+	fdma_free_coherent(lan966x->dma_dev, &fdma_rx_old);
 
 	page_pool_destroy(page_pool);
 
@@ -992,7 +992,7 @@ int lan966x_fdma_init(struct lan966x *lan966x)
 
 	err = lan966x_fdma_tx_alloc(&lan966x->tx);
 	if (err) {
-		fdma_free_coherent(lan966x->dev, &lan966x->rx.fdma);
+		fdma_free_coherent(lan966x->dma_dev, &lan966x->rx.fdma);
 		page_pool_destroy(lan966x->rx.page_pool);
 		return err;
 	}
@@ -1014,7 +1014,7 @@ void lan966x_fdma_deinit(struct lan966x *lan966x)
 	napi_disable(&lan966x->napi);
 
 	lan966x_fdma_rx_free_pages(&lan966x->rx);
-	fdma_free_coherent(lan966x->dev, &lan966x->rx.fdma);
+	fdma_free_coherent(lan966x->dma_dev, &lan966x->rx.fdma);
 	page_pool_destroy(lan966x->rx.page_pool);
 	lan966x_fdma_tx_free(&lan966x->tx);
 }
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
index 1179a6e127c5..2741f7c9fa4c 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
@@ -7,6 +7,7 @@
 #include <linux/ip.h>
 #include <linux/of.h>
 #include <linux/of_net.h>
+#include <linux/pci.h>
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
 #include <linux/reset.h>
@@ -1081,6 +1082,20 @@ static int lan966x_reset_switch(struct lan966x *lan966x)
 	return 0;
 }
 
+/* When enumerated over PCIe, dev is a platform device with no
+ * iommus/dma-ranges of its own, so DMA must target the PCIe endpoint instead.
+ * The result differs from dev only in that case; lan966x_is_pci() relies on it.
+ */
+static struct device *lan966x_get_dma_dev(struct device *dev)
+{
+	for (struct device *p = dev->parent; p; p = p->parent) {
+		if (dev_is_pci(p))
+			return p;
+	}
+
+	return dev;
+}
+
 static int lan966x_probe(struct platform_device *pdev)
 {
 	struct fwnode_handle *ports, *portnp;
@@ -1094,6 +1109,7 @@ static int lan966x_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, lan966x);
 	lan966x->dev = &pdev->dev;
+	lan966x->dma_dev = lan966x_get_dma_dev(lan966x->dev);
 
 	if (!device_get_mac_address(&pdev->dev, mac_addr)) {
 		ether_addr_copy(lan966x->base_mac, mac_addr);
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.h b/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
index 83c361abb789..3f09f8ddf620 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
@@ -270,6 +270,9 @@ struct lan966x_skb_cb {
 struct lan966x {
 	struct device *dev;
 
+	/* Device used for DMA; the PCIe endpoint when enumerated over PCIe. */
+	struct device *dma_dev;
+
 	u8 num_phys_ports;
 	struct lan966x_port **ports;
 
@@ -573,6 +576,13 @@ void lan966x_fdma_wakeup_netdev(struct lan966x *lan966x);
 int lan966x_fdma_get_max_frame(struct lan966x *lan966x);
 int lan966x_qsys_sw_status(struct lan966x *lan966x);
 
+/* dma_dev differs from dev only on the PCIe path. */
+static inline bool lan966x_is_pci(struct lan966x *lan966x)
+{
+	return IS_ENABLED(CONFIG_MCHP_LAN966X_PCI) &&
+	       lan966x->dma_dev != lan966x->dev;
+}
+
 int lan966x_lag_port_join(struct lan966x_port *port,
 			  struct net_device *brport_dev,
 			  struct net_device *bond,

-- 
2.34.1

Re: [PATCH net-next v7 06/14] net: lan966x: use a dedicated device for DMA operations

[Simon Horman]

On Fri, Sep 18, 2026 at 01:33:58PM +0200, Daniel Machon wrote:
> In preparation for the PCIe FDMA implementation, add lan966x->dma_dev,
> resolved once at probe time, and use it for every DMA operation the
> FDMA path performs: coherent allocations, streaming mappings and the RX
> page pool. Natively, dma_dev is lan966x->dev, so there is no functional
> change.
> 
> Since dma_dev differs from dev only on the PCIe path, add
> lan966x_is_pci() on top of it, for the later PCIe patches to key off.
> 
> Signed-off-by: Daniel Machon <daniel.machon@microchip.com>

Reviewed-by: Simon Horman <horms@kernel.org>

[PATCH net-next v7 07/14] net: lan966x: add FDMA ops dispatch for PCIe support

[Daniel Machon]

Introduce lan966x_fdma_ops to support different FDMA implementations
for platform and PCIe. Plumb fdma_init, fdma_deinit, fdma_xmit,
fdma_poll and fdma_resize through the ops table, and select the
implementation at probe time. Only the platform implementation exists
at this point; the PCIe implementation is added in a later patch.

Tested-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
---
 .../net/ethernet/microchip/lan966x/lan966x_fdma.c    |  2 +-
 .../net/ethernet/microchip/lan966x/lan966x_main.c    | 20 +++++++++++++++-----
 .../net/ethernet/microchip/lan966x/lan966x_main.h    | 13 +++++++++++++
 3 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
index 15fc59cb4ad7..2695bc41e52a 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
@@ -947,7 +947,7 @@ void lan966x_fdma_netdev_init(struct lan966x *lan966x, struct net_device *dev)
 		return;
 
 	lan966x->fdma_ndev = dev;
-	netif_napi_add(dev, &lan966x->napi, lan966x_fdma_napi_poll);
+	netif_napi_add(dev, &lan966x->napi, lan966x->ops->fdma_poll);
 	napi_enable(&lan966x->napi);
 }
 
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
index 2741f7c9fa4c..6e6c08bb8eea 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
@@ -27,6 +27,14 @@
 
 #define IO_RANGES 2
 
+static const struct lan966x_fdma_ops lan966x_fdma_ops = {
+	.fdma_init = &lan966x_fdma_init,
+	.fdma_deinit = &lan966x_fdma_deinit,
+	.fdma_xmit = &lan966x_fdma_xmit,
+	.fdma_poll = &lan966x_fdma_napi_poll,
+	.fdma_resize = &lan966x_fdma_change_mtu,
+};
+
 static const struct of_device_id lan966x_match[] = {
 	{ .compatible = "microchip,lan966x-switch" },
 	{ }
@@ -392,7 +400,7 @@ static netdev_tx_t lan966x_port_xmit(struct sk_buff *skb,
 
 	spin_lock(&lan966x->tx_lock);
 	if (port->lan966x->fdma)
-		err = lan966x_fdma_xmit(skb, ifh, dev);
+		err = lan966x->ops->fdma_xmit(skb, ifh, dev);
 	else
 		err = lan966x_port_ifh_xmit(skb, ifh, dev);
 	spin_unlock(&lan966x->tx_lock);
@@ -414,7 +422,7 @@ static int lan966x_port_change_mtu(struct net_device *dev, int new_mtu)
 	if (!lan966x->fdma)
 		return 0;
 
-	err = lan966x_fdma_change_mtu(lan966x);
+	err = lan966x->ops->fdma_resize(lan966x);
 	if (err) {
 		lan_wr(DEV_MAC_MAXLEN_CFG_MAX_LEN_SET(LAN966X_HW_MTU(old_mtu)),
 		       lan966x, DEV_MAC_MAXLEN_CFG(port->chip_port));
@@ -1111,6 +1119,8 @@ static int lan966x_probe(struct platform_device *pdev)
 	lan966x->dev = &pdev->dev;
 	lan966x->dma_dev = lan966x_get_dma_dev(lan966x->dev);
 
+	lan966x->ops = &lan966x_fdma_ops;
+
 	if (!device_get_mac_address(&pdev->dev, mac_addr)) {
 		ether_addr_copy(lan966x->base_mac, mac_addr);
 	} else {
@@ -1250,7 +1260,7 @@ static int lan966x_probe(struct platform_device *pdev)
 	if (err)
 		goto cleanup_fdb;
 
-	err = lan966x_fdma_init(lan966x);
+	err = lan966x->ops->fdma_init(lan966x);
 	if (err)
 		goto cleanup_ptp;
 
@@ -1263,7 +1273,7 @@ static int lan966x_probe(struct platform_device *pdev)
 	return 0;
 
 cleanup_fdma:
-	lan966x_fdma_deinit(lan966x);
+	lan966x->ops->fdma_deinit(lan966x);
 
 cleanup_ptp:
 	lan966x_ptp_deinit(lan966x);
@@ -1291,7 +1301,7 @@ static void lan966x_remove(struct platform_device *pdev)
 
 	lan966x_taprio_deinit(lan966x);
 	lan966x_vcap_deinit(lan966x);
-	lan966x_fdma_deinit(lan966x);
+	lan966x->ops->fdma_deinit(lan966x);
 	lan966x_cleanup_ports(lan966x);
 
 	cancel_delayed_work_sync(&lan966x->stats_work);
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.h b/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
index 3f09f8ddf620..aab5e53ed059 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
@@ -193,6 +193,17 @@ enum vcap_is1_port_sel_rt {
 	VCAP_IS1_PS_RT_FOLLOW_OTHER = 7,
 };
 
+struct lan966x;
+
+struct lan966x_fdma_ops {
+	int (*fdma_init)(struct lan966x *lan966x);
+	void (*fdma_deinit)(struct lan966x *lan966x);
+	int (*fdma_xmit)(struct sk_buff *skb, __be32 *ifh,
+			 struct net_device *dev);
+	int (*fdma_poll)(struct napi_struct *napi, int weight);
+	int (*fdma_resize)(struct lan966x *lan966x);
+};
+
 struct lan966x_port;
 
 struct lan966x_rx {
@@ -273,6 +284,8 @@ struct lan966x {
 	/* Device used for DMA; the PCIe endpoint when enumerated over PCIe. */
 	struct device *dma_dev;
 
+	const struct lan966x_fdma_ops *ops;
+
 	u8 num_phys_ports;
 	struct lan966x_port **ports;
 

-- 
2.34.1

Re: [PATCH net-next v7 07/14] net: lan966x: add FDMA ops dispatch for PCIe support

[Simon Horman]

On Fri, Sep 18, 2026 at 01:33:59PM +0200, Daniel Machon wrote:
> Introduce lan966x_fdma_ops to support different FDMA implementations
> for platform and PCIe. Plumb fdma_init, fdma_deinit, fdma_xmit,
> fdma_poll and fdma_resize through the ops table, and select the
> implementation at probe time. Only the platform implementation exists
> at this point; the PCIe implementation is added in a later patch.
> 
> Tested-by: Herve Codina <herve.codina@bootlin.com>
> Signed-off-by: Daniel Machon <daniel.machon@microchip.com>

Reviewed-by: Simon Horman <horms@kernel.org>

[PATCH net-next v7 08/14] net: lan966x: clear FDMA interrupt stickies after switch reset

[Daniel Machon]

When in PCI mode, the GCB soft reset issued by the reset controller
can latch spurious bits in the FDMA error stickies. The latched bits
sit in FDMA_INTR_ERR until the FDMA IRQ is requested later in probe,
at which point the handler fires immediately and WARNs.

Clear FDMA_ERRORS, FDMA_INTR_ERR and FDMA_INTR_DB right after the
switch reset so the FDMA comes out clean and the IRQ handler does not
see ghost errors on probe.

The clear runs on both the PCI and platform paths. On the platform
path it has no effect — there are no spurious stickies to clear — but
keeping it unconditional avoids a PCI-specific code path here.

Tested-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
---
 drivers/net/ethernet/microchip/lan966x/lan966x_main.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
index 6e6c08bb8eea..11094a381ec2 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
@@ -1067,6 +1067,15 @@ static int lan966x_reset_switch(struct lan966x *lan966x)
 
 	reset_control_reset(switch_reset);
 
+	/* When in PCI mode, the GCB soft reset issued by the reset
+	 * controller can latch spurious bits in the FDMA error stickies.
+	 * Clear them before request_irq hooks up the FDMA IRQ line,
+	 * otherwise the handler fires immediately on probe.
+	 */
+	lan_wr(lan_rd(lan966x, FDMA_ERRORS), lan966x, FDMA_ERRORS);
+	lan_wr(lan_rd(lan966x, FDMA_INTR_ERR), lan966x, FDMA_INTR_ERR);
+	lan_wr(lan_rd(lan966x, FDMA_INTR_DB), lan966x, FDMA_INTR_DB);
+
 	/* Don't reinitialize the switch core, if it is already initialized. In
 	 * case it is initialized twice, some pointers inside the queue system
 	 * in HW will get corrupted and then after a while the queue system gets

-- 
2.34.1

Re: [PATCH net-next v7 08/14] net: lan966x: clear FDMA interrupt stickies after switch reset

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] Commit message describes the WARN-on-probe failure in the present
  tense, but at this commit the PCI path cannot request the FDMA IRQ:…
- [Low] In-code comment under-describes the code it documents.

--

net: lan966x: clear FDMA interrupt stickies after switch reset

This adds three register acknowledgements right after the switch reset in
lan966x_reset_switch(), clearing FDMA_ERRORS, FDMA_INTR_ERR and
FDMA_INTR_DB so that a spurious sticky latched by the GCB soft reset in PCI
mode does not make the FDMA handler fire as soon as the IRQ is requested.
The clear is done unconditionally on both the PCI and platform paths.

> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
> index 6e6c08bb8eea..11094a381ec2 100644
> --- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
> @@ -1067,6 +1067,15 @@ static int lan966x_reset_switch(struct lan966x *lan966x)
>  
>  	reset_control_reset(switch_reset);
>  
> +	/* When in PCI mode, the GCB soft reset issued by the reset
> +	 * controller can latch spurious bits in the FDMA error stickies.
> +	 * Clear them before request_irq hooks up the FDMA IRQ line,
> +	 * otherwise the handler fires immediately on probe.
> +	 */
> +	lan_wr(lan_rd(lan966x, FDMA_ERRORS), lan966x, FDMA_ERRORS);
> +	lan_wr(lan_rd(lan966x, FDMA_INTR_ERR), lan966x, FDMA_INTR_ERR);
> +	lan_wr(lan_rd(lan966x, FDMA_INTR_DB), lan966x, FDMA_INTR_DB);

[Severity: Low]
This isn't a bug, but should the comment also mention FDMA_INTR_DB?  The
comment talks only about the "FDMA error stickies", while the code below it
also acks FDMA_INTR_DB, which is the data-block completion sticky rather
than an error sticky.

In lan966x_fdma.c, lan966x_fdma_irq_handler() consumes it in the non-error
branch:

	if (db) {
		lan_wr(0, lan966x, FDMA_INTR_DB_ENA);
		lan_wr(db, lan966x, FDMA_INTR_DB);

		napi_schedule(&lan966x->napi);
	}

So a latched DB sticky would lead to napi_schedule() rather than the WARN
described in the comment.

The commit message does list all three registers, so only the in-code
comment is out of sync.  Could it be extended to say that the data-block
sticky is cleared too, so a later cleanup doesn't drop the FDMA_INTR_DB
write as unrelated?

>  
>  	/* Don't reinitialize the switch core, if it is already initialized. In
>  	 * case it is initialized twice, some pointers inside the queue system
>  	 * in HW will get corrupted and then after a while the queue system gets

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260918-lan966x-pci-fdma-v7-0-0ecc179c8a2c%40microchip.com

Re: [PATCH net-next v7 08/14] net: lan966x: clear FDMA interrupt stickies after switch reset

[Simon Horman]

On Fri, Sep 18, 2026 at 01:34:00PM +0200, Daniel Machon wrote:
> When in PCI mode, the GCB soft reset issued by the reset controller
> can latch spurious bits in the FDMA error stickies. The latched bits
> sit in FDMA_INTR_ERR until the FDMA IRQ is requested later in probe,
> at which point the handler fires immediately and WARNs.
> 
> Clear FDMA_ERRORS, FDMA_INTR_ERR and FDMA_INTR_DB right after the
> switch reset so the FDMA comes out clean and the IRQ handler does not
> see ghost errors on probe.
> 
> The clear runs on both the PCI and platform paths. On the platform
> path it has no effect — there are no spurious stickies to clear — but
> keeping it unconditional avoids a PCI-specific code path here.
> 
> Tested-by: Herve Codina <herve.codina@bootlin.com>
> Signed-off-by: Daniel Machon <daniel.machon@microchip.com>

Reviewed-by: Simon Horman <horms@kernel.org>

[PATCH net-next v7 09/14] net: lan966x: add shutdown callback to stop the FDMA on reboot

[Daniel Machon]

As a PCIe endpoint, lan966x is not reset by a host reboot: its FDMA
channels and interrupt sources stay armed, and the OIC ORs every
source into the shared PCIe INTx, asserted before the driver has
re-probed. A still-active channel also keeps write access to host
memory the next kernel will reuse.

Add a shutdown callback that:
- frees the ana, xtr and FDMA irqs, masking and unmapping them at
  the OIC (disable_irq() would leave both set - the OIC has no
  irq_disable())
- masks the analyzer source, armed unconditionally by lan966x_init()
  and re-armed by the MAC table's age timer
- stops and detaches the netdevs, draining in-flight xmit and
  clearing netif_device_present() so ndo_open/ndo_change_mtu cannot
  re-enter the FDMA against a disabled NAPI
- disables both FDMA channels and masks their interrupts
- unmaps the outbound ATU windows, leaving none armed

NAPI is skipped when fdma_ndev is unset (a probed switch with no
usable port never adds one), and XDP attach cannot re-enter either,
since lan966x_xdp_setup() returns early on PCIe before touching the
FDMA.

Only the PCIe instantiation needs this - the SoC one resets with the
chip - so the callback returns early on a platform device; the check
is at runtime since .shutdown belongs to the driver, and a
PCIe-enabled kernel binds both.

FDMA_INTR_ENA persists across a warm reboot, so also restore the
full enable in lan966x_fdma_rx_start(), run after both rings are
allocated, re-arming both backends from one site.

Tested-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
---
 .../net/ethernet/microchip/lan966x/lan966x_fdma.c  |  4 ++
 .../net/ethernet/microchip/lan966x/lan966x_main.c  | 56 ++++++++++++++++++++++
 .../net/ethernet/microchip/lan966x/lan966x_regs.h  | 15 ++++++
 3 files changed, 75 insertions(+)

diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
index 2695bc41e52a..6fb2482eeb17 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
@@ -146,6 +146,10 @@ void lan966x_fdma_rx_start(struct lan966x_rx *rx)
 	struct fdma *fdma = &rx->fdma;
 	u32 mask;
 
+	lan_wr(FDMA_INTR_ENA_INTR_PORT_ENA_SET(GENMASK(1, 0)) |
+	       FDMA_INTR_ENA_INTR_CH_ENA_SET(GENMASK(7, 0)),
+	       lan966x, FDMA_INTR_ENA);
+
 	lan_wr(FDMA_CH_CFG_CH_DCB_DB_CNT_SET(fdma->n_dbs) |
 	       FDMA_CH_CFG_CH_INTR_DB_EOF_ONLY_SET(1) |
 	       FDMA_CH_CFG_CH_INJ_PORT_SET(0) |
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
index 11094a381ec2..2c1e2bc12024 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
@@ -1324,9 +1324,65 @@ static void lan966x_remove(struct platform_device *pdev)
 	debugfs_remove_recursive(lan966x->debugfs_root);
 }
 
+static void lan966x_shutdown(struct platform_device *pdev)
+{
+	struct lan966x *lan966x = platform_get_drvdata(pdev);
+
+	/* As a PCIe endpoint the switch is not reset by the host reboot, so it
+	 * has to be quiesced here:
+	 *
+	 *   Free the irqs and mask the sources: no source can assert INTx.
+	 *   Disable NAPI: the teardown must not race a poll.
+	 *   Stop and detach the netdevs: drains xmit, closes ndo_open and MTU.
+	 *   Stop the FDMA channels: waits for the engine to go idle.
+	 *   Unmap the ATU windows: revokes the engine's access to host memory.
+	 */
+	if (!lan966x_is_pci(lan966x))
+		return;
+
+	if (lan966x->xtr_irq > 0)
+		devm_free_irq(lan966x->dev, lan966x->xtr_irq, lan966x);
+	if (lan966x->ana_irq > 0)
+		devm_free_irq(lan966x->dev, lan966x->ana_irq, lan966x);
+	if (lan966x->fdma_irq > 0)
+		devm_free_irq(lan966x->dev, lan966x->fdma_irq, lan966x);
+
+	lan_wr(0, lan966x, ANA_ANAINTR);
+
+	if (!lan966x->fdma)
+		return;
+
+	rtnl_lock();
+
+	if (lan966x->fdma_ndev)
+		napi_disable(&lan966x->napi);
+
+	for (int p = 0; p < lan966x->num_phys_ports; p++) {
+		if (!lan966x->ports[p] || !lan966x->ports[p]->dev)
+			continue;
+
+		netif_tx_disable(lan966x->ports[p]->dev);
+		netif_device_detach(lan966x->ports[p]->dev);
+	}
+
+	lan966x_fdma_rx_disable(&lan966x->rx);
+	lan966x_fdma_tx_disable(&lan966x->tx);
+
+	lan_wr(0, lan966x, FDMA_INTR_ENA);
+	lan_wr(0, lan966x, FDMA_INTR_DB_ENA);
+
+#if IS_ENABLED(CONFIG_MCHP_LAN966X_PCI)
+	fdma_pci_atu_region_unmap(lan966x->rx.fdma.atu_region);
+	fdma_pci_atu_region_unmap(lan966x->tx.fdma.atu_region);
+#endif
+
+	rtnl_unlock();
+}
+
 static struct platform_driver lan966x_driver = {
 	.probe = lan966x_probe,
 	.remove = lan966x_remove,
+	.shutdown = lan966x_shutdown,
 	.driver = {
 		.name = "lan966x-switch",
 		.of_match_table = lan966x_match,
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_regs.h b/drivers/net/ethernet/microchip/lan966x/lan966x_regs.h
index 4b553927d2e0..aba0d36ae6b5 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_regs.h
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_regs.h
@@ -1039,6 +1039,21 @@ enum lan966x_target {
 /*      FDMA:FDMA:FDMA_INTR_ERR */
 #define FDMA_INTR_ERR             __REG(TARGET_FDMA, 0, 1, 8, 0, 1, 428, 400, 0, 1, 4)
 
+/*      FDMA:FDMA:FDMA_INTR_ENA */
+#define FDMA_INTR_ENA             __REG(TARGET_FDMA, 0, 1, 8, 0, 1, 428, 404, 0, 1, 4)
+
+#define FDMA_INTR_ENA_INTR_PORT_ENA              GENMASK(9, 8)
+#define FDMA_INTR_ENA_INTR_PORT_ENA_SET(x)\
+	FIELD_PREP(FDMA_INTR_ENA_INTR_PORT_ENA, x)
+#define FDMA_INTR_ENA_INTR_PORT_ENA_GET(x)\
+	FIELD_GET(FDMA_INTR_ENA_INTR_PORT_ENA, x)
+
+#define FDMA_INTR_ENA_INTR_CH_ENA                GENMASK(7, 0)
+#define FDMA_INTR_ENA_INTR_CH_ENA_SET(x)\
+	FIELD_PREP(FDMA_INTR_ENA_INTR_CH_ENA, x)
+#define FDMA_INTR_ENA_INTR_CH_ENA_GET(x)\
+	FIELD_GET(FDMA_INTR_ENA_INTR_CH_ENA, x)
+
 /*      FDMA:FDMA:FDMA_ERRORS */
 #define FDMA_ERRORS               __REG(TARGET_FDMA, 0, 1, 8, 0, 1, 428, 412, 0, 1, 4)
 

-- 
2.34.1

Re: [PATCH net-next v7 09/14] net: lan966x: add shutdown callback to stop the FDMA on reboot

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] BASELINE DECISION: false (discarded).
- [Low] BASELINE DECISION: false (discarded).
- [Low] The patch fixes an observable pre-existing failure on the
  already-supported PCIe endpoint configuration (the xtr and ana OIC…
- [Low] BASELINE DECISION: false (discarded).

Pre-existing issues:
- [Low] BASELINE DECISION: false (discarded).

--

net: lan966x: add shutdown callback to stop the FDMA on reboot

Adds a .shutdown callback to the lan966x switch driver that, on the PCIe
endpoint instantiation only, frees the xtr/ana/FDMA irqs, masks the
analyzer interrupt, stops and detaches the netdevs, disables both FDMA
channels and unmaps the outbound ATU windows. It also restores
FDMA_INTR_ENA in lan966x_fdma_rx_start() and adds the register defines.

> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
> index 11094a381ec2..2c1e2bc12024 100644
> --- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
> @@ -1324,9 +1324,65 @@ static void lan966x_remove(struct platform_device *pdev)

[ ... ]

> +	if (!lan966x_is_pci(lan966x))
> +		return;
> +
> +	if (lan966x->xtr_irq > 0)
> +		devm_free_irq(lan966x->dev, lan966x->xtr_irq, lan966x);
> +	if (lan966x->ana_irq > 0)
> +		devm_free_irq(lan966x->dev, lan966x->ana_irq, lan966x);
> +	if (lan966x->fdma_irq > 0)
> +		devm_free_irq(lan966x->dev, lan966x->fdma_irq, lan966x);
> +
> +	lan_wr(0, lan966x, ANA_ANAINTR);

[Severity: Low]
Should this carry a Fixes: tag?

This part of the new callback corrects a failure that already exists on
the shipping PCIe endpoint configuration, independently of the FDMA work
in the rest of the series: the xtr and ana OIC sources, plus the analyzer
enable written unconditionally by lan966x_init()

  drivers/net/ethernet/microchip/lan966x/lan966x_main.c:lan966x_init() {
      ...
      lan_rmw(ANA_ANAINTR_INTR_ENA_SET(1),
              ANA_ANAINTR_INTR_ENA,
              lan966x, ANA_ANAINTR);
      ...
  }

stay armed across a host reboot, and nothing released them at shutdown
before this patch, so the shared INTx can be asserted before the driver
re-probes.

Without a Fixes: tag, stable tooling and backporters have no way to tell
which versions are affected. Would the following be the right
provenance?

  Fixes: 185686beb464 ("misc: Add support for LAN966x PCI device")

That is the commit that introduced the PCI endpoint together with its
persistent OIC/INTx routing.

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260918-lan966x-pci-fdma-v7-0-0ecc179c8a2c%40microchip.com

Re: [PATCH net-next v7 09/14] net: lan966x: add shutdown callback to stop the FDMA on reboot

[Simon Horman]

On Fri, Sep 18, 2026 at 01:34:01PM +0200, Daniel Machon wrote:
> As a PCIe endpoint, lan966x is not reset by a host reboot: its FDMA
> channels and interrupt sources stay armed, and the OIC ORs every
> source into the shared PCIe INTx, asserted before the driver has
> re-probed. A still-active channel also keeps write access to host
> memory the next kernel will reuse.
> 
> Add a shutdown callback that:
> - frees the ana, xtr and FDMA irqs, masking and unmapping them at
>   the OIC (disable_irq() would leave both set - the OIC has no
>   irq_disable())
> - masks the analyzer source, armed unconditionally by lan966x_init()
>   and re-armed by the MAC table's age timer
> - stops and detaches the netdevs, draining in-flight xmit and
>   clearing netif_device_present() so ndo_open/ndo_change_mtu cannot
>   re-enter the FDMA against a disabled NAPI
> - disables both FDMA channels and masks their interrupts
> - unmaps the outbound ATU windows, leaving none armed
> 
> NAPI is skipped when fdma_ndev is unset (a probed switch with no
> usable port never adds one), and XDP attach cannot re-enter either,
> since lan966x_xdp_setup() returns early on PCIe before touching the
> FDMA.
> 
> Only the PCIe instantiation needs this - the SoC one resets with the
> chip - so the callback returns early on a platform device; the check
> is at runtime since .shutdown belongs to the driver, and a
> PCIe-enabled kernel binds both.
> 
> FDMA_INTR_ENA persists across a warm reboot, so also restore the
> full enable in lan966x_fdma_rx_start(), run after both rings are
> allocated, re-arming both backends from one site.
> 
> Tested-by: Herve Codina <herve.codina@bootlin.com>
> Signed-off-by: Daniel Machon <daniel.machon@microchip.com>

Reviewed-by: Simon Horman <horms@kernel.org>

[PATCH net-next v7 10/14] net: lan966x: add PCIe FDMA support

[Daniel Machon]

Add PCIe FDMA support for lan966x. The PCIe FDMA path uses contiguous
DMA buffers mapped through the endpoint's ATU, with memcpy-based frame
transfer instead of per-page DMA mappings.

With PCIe FDMA, throughput increases from ~33 Mbps (register-based I/O)
to ~620 Mbps on an Intel x86 host with a lan966x PCIe card.

XDP is not supported on this path yet, so do not advertise xdp_features
and reject program attach for PCIe instances.

Tested-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
---
 drivers/net/ethernet/microchip/lan966x/Makefile    |   4 +
 .../ethernet/microchip/lan966x/lan966x_fdma_pci.c  | 421 +++++++++++++++++++++
 .../net/ethernet/microchip/lan966x/lan966x_main.c  |  11 +-
 .../net/ethernet/microchip/lan966x/lan966x_main.h  |   7 +
 .../net/ethernet/microchip/lan966x/lan966x_regs.h  |  10 +
 .../net/ethernet/microchip/lan966x/lan966x_xdp.c   |   6 +
 6 files changed, 456 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/microchip/lan966x/Makefile b/drivers/net/ethernet/microchip/lan966x/Makefile
index 4cdbe263502c..02db4d4d9826 100644
--- a/drivers/net/ethernet/microchip/lan966x/Makefile
+++ b/drivers/net/ethernet/microchip/lan966x/Makefile
@@ -18,6 +18,10 @@ lan966x-switch-objs  := lan966x_main.o lan966x_phylink.o lan966x_port.o \
 lan966x-switch-$(CONFIG_LAN966X_DCB) += lan966x_dcb.o
 lan966x-switch-$(CONFIG_DEBUG_FS) += lan966x_vcap_debugfs.o
 
+ifneq ($(CONFIG_MCHP_LAN966X_PCI),)
+lan966x-switch-y += lan966x_fdma_pci.o
+endif
+
 # Provide include files
 ccflags-y += -I$(srctree)/drivers/net/ethernet/microchip/vcap
 ccflags-y += -I$(srctree)/drivers/net/ethernet/microchip/fdma
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
new file mode 100644
index 000000000000..5d6902459f20
--- /dev/null
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
@@ -0,0 +1,421 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include "fdma_api.h"
+#include "lan966x_main.h"
+
+static int lan966x_fdma_pci_dataptr_cb(struct fdma *fdma, int dcb, int db,
+				       u64 *dataptr)
+{
+	u64 addr;
+
+	addr = fdma_dataptr_dma_addr_contiguous(fdma, dcb, db);
+
+	*dataptr = fdma_pci_atu_translate_addr(fdma->atu_region, addr);
+
+	return 0;
+}
+
+static int lan966x_fdma_pci_nextptr_cb(struct fdma *fdma, int dcb, u64 *nextptr)
+{
+	u64 addr;
+
+	fdma_nextptr_cb(fdma, dcb, &addr);
+
+	*nextptr = fdma_pci_atu_translate_addr(fdma->atu_region, addr);
+
+	return 0;
+}
+
+/* Stop the TX queues on every port, so nothing feeds the injection channel
+ * while it is torn down or resized.
+ */
+static void lan966x_fdma_tx_disable_netdev(struct lan966x *lan966x)
+{
+	struct lan966x_port *port;
+	int i;
+
+	for (i = 0; i < lan966x->num_phys_ports; ++i) {
+		port = lan966x->ports[i];
+		if (!port)
+			continue;
+
+		netif_tx_disable(port->dev);
+	}
+}
+
+static int lan966x_fdma_pci_rx_alloc(struct lan966x_rx *rx)
+{
+	struct lan966x *lan966x = rx->lan966x;
+	struct fdma *fdma = &rx->fdma;
+	int err;
+
+	err = fdma_alloc_coherent_and_map(lan966x->dma_dev, fdma,
+					  &lan966x->atu);
+	if (err)
+		return err;
+
+	err = fdma_dcbs_init(fdma,
+			     FDMA_DCB_INFO_DATAL(fdma->db_size - XDP_PACKET_HEADROOM),
+			     FDMA_DCB_STATUS_INTR);
+	if (err) {
+		fdma_free_coherent_and_unmap(lan966x->dma_dev, fdma);
+		return err;
+	}
+
+	lan966x_fdma_llp_configure(lan966x,
+				   fdma->atu_region->base_addr,
+				   fdma->channel_id);
+
+	return 0;
+}
+
+static int lan966x_fdma_pci_tx_alloc(struct lan966x_tx *tx)
+{
+	struct lan966x *lan966x = tx->lan966x;
+	struct fdma *fdma = &tx->fdma;
+	int err;
+
+	err = fdma_alloc_coherent_and_map(lan966x->dma_dev, fdma,
+					  &lan966x->atu);
+	if (err)
+		return err;
+
+	err = fdma_dcbs_init(fdma,
+			     FDMA_DCB_INFO_DATAL(fdma->db_size),
+			     FDMA_DCB_STATUS_DONE);
+	if (err) {
+		fdma_free_coherent_and_unmap(lan966x->dma_dev, fdma);
+		return err;
+	}
+
+	lan966x_fdma_llp_configure(lan966x,
+				   fdma->atu_region->base_addr,
+				   fdma->channel_id);
+
+	return 0;
+}
+
+static int lan966x_fdma_pci_get_next_dcb(struct fdma *fdma)
+{
+	struct fdma_db *db;
+
+	for (int i = 0; i < fdma->n_dcbs; i++) {
+		db = fdma_db_get(fdma, i, 0);
+
+		if (!fdma_db_is_done(db))
+			continue;
+		if (fdma_is_last(fdma, &fdma->dcbs[i]))
+			continue;
+
+		return i;
+	}
+
+	return -ENOSPC;
+}
+
+/* TX slot layout (sizes in bytes):
+ *
+ *  +---------------------+-----+---------+-----+
+ *  | XDP_PACKET_HEADROOM | IFH | payload | FCS |
+ *  |         256         |  28 |   len   |   4 |
+ *  +---------------------+-----+---------+-----+
+ *  |<---------------- db_size ----------------->|
+ *
+ * Return true if the frame plus required overhead fits.
+ */
+static bool lan966x_fdma_pci_tx_size_fits(struct fdma *fdma, u32 len)
+{
+	return XDP_PACKET_HEADROOM + IFH_LEN_BYTES + len + ETH_FCS_LEN <=
+	       fdma->db_size;
+}
+
+/* Return true if blockl is a valid RX frame size. */
+static bool lan966x_fdma_pci_rx_size_fits(struct fdma *fdma, u32 blockl)
+{
+	return blockl >= IFH_LEN_BYTES + ETH_HLEN + ETH_FCS_LEN &&
+	       blockl <= fdma->db_size - XDP_PACKET_HEADROOM;
+}
+
+static int lan966x_fdma_pci_rx_check_frame(struct lan966x_rx *rx, u64 *src_port)
+{
+	struct lan966x *lan966x = rx->lan966x;
+	struct fdma *fdma = &rx->fdma;
+	struct lan966x_port *port;
+	struct fdma_db *db;
+	void *virt_addr;
+	u32 blockl;
+
+	/* virt_addr points to the IFH. */
+	virt_addr = fdma_dataptr_virt_addr_contiguous(fdma,
+						      fdma->dcb_index,
+						      fdma->db_index);
+
+	lan966x_ifh_get_src_port(virt_addr, src_port);
+
+	if (*src_port >= lan966x->num_phys_ports)
+		return FDMA_ERROR;
+
+	port = lan966x->ports[*src_port];
+	if (!port)
+		return FDMA_ERROR;
+
+	db = fdma_db_next_get(fdma);
+
+	/* BLOCKL is a 16-bit HW-populated field; reject obviously-bad
+	 * values before they feed memcpy/XDP sizes.
+	 */
+	blockl = FDMA_DCB_STATUS_BLOCKL(db->status);
+	if (!lan966x_fdma_pci_rx_size_fits(fdma, blockl))
+		return FDMA_ERROR;
+
+	return FDMA_PASS;
+}
+
+static struct sk_buff *lan966x_fdma_pci_rx_get_frame(struct lan966x_rx *rx,
+						     u64 src_port)
+{
+	struct lan966x *lan966x = rx->lan966x;
+	struct fdma *fdma = &rx->fdma;
+	struct sk_buff *skb;
+	struct fdma_db *db;
+	u32 data_len;
+
+	/* Get the received frame and create an SKB for it. */
+	db = fdma_db_next_get(fdma);
+	data_len = FDMA_DCB_STATUS_BLOCKL(db->status);
+
+	skb = napi_alloc_skb(&lan966x->napi, data_len);
+	if (unlikely(!skb))
+		return NULL;
+
+	memcpy(skb->data,
+	       fdma_dataptr_virt_addr_contiguous(fdma,
+						 fdma->dcb_index,
+						 fdma->db_index),
+						 data_len);
+
+	skb_put(skb, data_len);
+
+	skb->dev = lan966x->ports[src_port]->dev;
+	skb_pull(skb, IFH_LEN_BYTES);
+
+	skb_trim(skb, skb->len - ETH_FCS_LEN);
+
+	skb->protocol = eth_type_trans(skb, skb->dev);
+
+	if (lan966x->bridge_mask & BIT(src_port)) {
+		skb->offload_fwd_mark = 1;
+
+		skb_reset_network_header(skb);
+		if (!lan966x_hw_offload(lan966x, src_port, skb))
+			skb->offload_fwd_mark = 0;
+	}
+
+	skb->dev->stats.rx_bytes += skb->len;
+	skb->dev->stats.rx_packets++;
+
+	return skb;
+}
+
+static int lan966x_fdma_pci_xmit(struct sk_buff *skb, __be32 *ifh,
+				 struct net_device *dev)
+{
+	struct lan966x_port *port = netdev_priv(dev);
+	struct lan966x *lan966x = port->lan966x;
+	struct lan966x_tx *tx = &lan966x->tx;
+	struct fdma *fdma = &tx->fdma;
+	int next_to_use;
+	void *virt_addr;
+
+	next_to_use = lan966x_fdma_pci_get_next_dcb(fdma);
+
+	if (next_to_use < 0) {
+		netif_stop_queue(dev);
+		return NETDEV_TX_BUSY;
+	}
+
+	if (skb_put_padto(skb, ETH_ZLEN)) {
+		dev->stats.tx_dropped++;
+		return NETDEV_TX_OK;
+	}
+
+	if (!lan966x_fdma_pci_tx_size_fits(fdma, skb->len)) {
+		dev_kfree_skb_any(skb);
+		dev->stats.tx_dropped++;
+		return NETDEV_TX_OK;
+	}
+
+	skb_tx_timestamp(skb);
+
+	/* virt_addr points to the IFH. */
+	virt_addr = fdma_dataptr_virt_addr_contiguous(fdma, next_to_use, 0);
+	memcpy(virt_addr, ifh, IFH_LEN_BYTES);
+	memcpy(virt_addr + IFH_LEN_BYTES, skb->data, skb->len);
+
+	/* Order frame write before DCB status write below. */
+	dma_wmb();
+
+	fdma_dcb_add(fdma,
+		     next_to_use,
+		     0,
+		     FDMA_DCB_STATUS_INTR |
+		     FDMA_DCB_STATUS_SOF |
+		     FDMA_DCB_STATUS_EOF |
+		     FDMA_DCB_STATUS_BLOCKO(0) |
+		     FDMA_DCB_STATUS_BLOCKL(IFH_LEN_BYTES + skb->len + ETH_FCS_LEN));
+
+	/* Start the transmission. */
+	lan966x_fdma_tx_start(tx);
+
+	dev->stats.tx_bytes += skb->len;
+	dev->stats.tx_packets++;
+
+	/* Safe to free: PTP is not supported on the PCIe path yet,
+	 * so lan966x->ptp is always 0 here.
+	 */
+	dev_consume_skb_any(skb);
+
+	return NETDEV_TX_OK;
+}
+
+static int lan966x_fdma_pci_napi_poll(struct napi_struct *napi, int weight)
+{
+	struct lan966x *lan966x = container_of(napi, struct lan966x, napi);
+	struct lan966x_rx *rx = &lan966x->rx;
+	struct fdma *fdma = &rx->fdma;
+	int dcb_reload, old_dcb;
+	struct sk_buff *skb;
+	int counter = 0;
+	u64 src_port;
+
+	/* Wake any stopped TX queues if a TX DCB is available. */
+	spin_lock(&lan966x->tx_lock);
+	if (lan966x_fdma_pci_get_next_dcb(&lan966x->tx.fdma) >= 0)
+		lan966x_fdma_wakeup_netdev(lan966x);
+	spin_unlock(&lan966x->tx_lock);
+
+	dcb_reload = fdma->dcb_index;
+
+	/* Get all received skbs. */
+	while (counter < weight) {
+		if (!fdma_has_frames(fdma))
+			break;
+		/* Order DONE read before DCB/frame reads below. */
+		dma_rmb();
+		counter++;
+		switch (lan966x_fdma_pci_rx_check_frame(rx, &src_port)) {
+		case FDMA_PASS:
+			break;
+		case FDMA_ERROR:
+			/* No rx_dropped increment here because src_port is
+			 * invalid.
+			 */
+			fdma_dcb_advance(fdma);
+			continue;
+		}
+		skb = lan966x_fdma_pci_rx_get_frame(rx, src_port);
+		fdma_dcb_advance(fdma);
+		if (!skb) {
+			lan966x->ports[src_port]->dev->stats.rx_dropped++;
+			continue;
+		}
+
+		napi_gro_receive(&lan966x->napi, skb);
+	}
+	while (dcb_reload != fdma->dcb_index) {
+		old_dcb = dcb_reload;
+		dcb_reload++;
+		dcb_reload &= fdma->n_dcbs - 1;
+
+		fdma_dcb_add(fdma,
+			     old_dcb,
+			     FDMA_DCB_INFO_DATAL(fdma->db_size - XDP_PACKET_HEADROOM),
+			     FDMA_DCB_STATUS_INTR);
+
+		lan966x_fdma_rx_reload(rx);
+	}
+
+	if (counter < weight && napi_complete_done(napi, counter))
+		lan_wr(0xff, lan966x, FDMA_INTR_DB_ENA);
+
+	return counter;
+}
+
+static int lan966x_fdma_pci_init(struct lan966x *lan966x)
+{
+	struct fdma *rx_fdma = &lan966x->rx.fdma;
+	struct fdma *tx_fdma = &lan966x->tx.fdma;
+	int err;
+
+	if (!lan966x->fdma)
+		return 0;
+
+	lan_wr(FDMA_CTRL_NRESET_SET(0), lan966x, FDMA_CTRL);
+	lan_wr(FDMA_CTRL_NRESET_SET(1), lan966x, FDMA_CTRL);
+
+	fdma_pci_atu_init(&lan966x->atu, lan966x->regs[TARGET_PCIE_DBI]);
+
+	lan966x->rx.lan966x = lan966x;
+	lan966x->rx.max_mtu = lan966x_fdma_get_max_frame(lan966x);
+	rx_fdma->channel_id = FDMA_XTR_CHANNEL;
+	rx_fdma->n_dcbs = FDMA_DCB_MAX;
+	rx_fdma->n_dbs = FDMA_RX_DCB_MAX_DBS;
+	rx_fdma->priv = lan966x;
+	rx_fdma->db_size = FDMA_PCI_DB_SIZE(lan966x->rx.max_mtu);
+	rx_fdma->size = fdma_get_size_contiguous(rx_fdma);
+	rx_fdma->ops.nextptr_cb = &lan966x_fdma_pci_nextptr_cb;
+	rx_fdma->ops.dataptr_cb = &lan966x_fdma_pci_dataptr_cb;
+
+	lan966x->tx.lan966x = lan966x;
+	tx_fdma->channel_id = FDMA_INJ_CHANNEL;
+	tx_fdma->n_dcbs = FDMA_DCB_MAX;
+	tx_fdma->n_dbs = FDMA_TX_DCB_MAX_DBS;
+	tx_fdma->priv = lan966x;
+	tx_fdma->db_size = FDMA_PCI_DB_SIZE(lan966x->rx.max_mtu);
+	tx_fdma->size = fdma_get_size_contiguous(tx_fdma);
+	tx_fdma->ops.nextptr_cb = &lan966x_fdma_pci_nextptr_cb;
+	tx_fdma->ops.dataptr_cb = &lan966x_fdma_pci_dataptr_cb;
+
+	err = lan966x_fdma_pci_rx_alloc(&lan966x->rx);
+	if (err)
+		return err;
+
+	err = lan966x_fdma_pci_tx_alloc(&lan966x->tx);
+	if (err) {
+		fdma_free_coherent_and_unmap(lan966x->dma_dev, rx_fdma);
+		return err;
+	}
+
+	lan966x_fdma_rx_start(&lan966x->rx);
+
+	return 0;
+}
+
+static int lan966x_fdma_pci_resize(struct lan966x *lan966x)
+{
+	return -EOPNOTSUPP;
+}
+
+static void lan966x_fdma_pci_deinit(struct lan966x *lan966x)
+{
+	if (!lan966x->fdma)
+		return;
+
+	if (lan966x->fdma_ndev)
+		napi_disable(&lan966x->napi);
+
+	lan966x_fdma_tx_disable_netdev(lan966x);
+	lan966x_fdma_rx_disable(&lan966x->rx);
+	lan966x_fdma_tx_disable(&lan966x->tx);
+
+	fdma_free_coherent_and_unmap(lan966x->dma_dev, &lan966x->rx.fdma);
+	fdma_free_coherent_and_unmap(lan966x->dma_dev, &lan966x->tx.fdma);
+}
+
+const struct lan966x_fdma_ops lan966x_fdma_pci_ops = {
+	.fdma_init = &lan966x_fdma_pci_init,
+	.fdma_deinit = &lan966x_fdma_pci_deinit,
+	.fdma_xmit = &lan966x_fdma_pci_xmit,
+	.fdma_poll = &lan966x_fdma_pci_napi_poll,
+	.fdma_resize = &lan966x_fdma_pci_resize,
+};
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
index 2c1e2bc12024..c803619d83e2 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
@@ -50,6 +50,7 @@ struct lan966x_main_io_resource {
 static const struct lan966x_main_io_resource lan966x_main_iomap[] =  {
 	{ TARGET_CPU,                   0xc0000, 0 }, /* 0xe00c0000 */
 	{ TARGET_FDMA,                  0xc0400, 0 }, /* 0xe00c0400 */
+	{ TARGET_PCIE_DBI,             0x400000, 0 }, /* 0xe0400000 */
 	{ TARGET_ORG,                         0, 1 }, /* 0xe2000000 */
 	{ TARGET_GCB,                    0x4000, 1 }, /* 0xe2004000 */
 	{ TARGET_QS,                     0x8000, 1 }, /* 0xe2008000 */
@@ -873,7 +874,8 @@ static int lan966x_probe_port(struct lan966x *lan966x, u32 p,
 
 	port->phylink = phylink;
 
-	if (lan966x->fdma)
+	/* XDP is not supported on the PCIe FDMA path. */
+	if (lan966x->fdma && !lan966x_is_pci(lan966x))
 		dev->xdp_features = NETDEV_XDP_ACT_BASIC |
 				    NETDEV_XDP_ACT_REDIRECT |
 				    NETDEV_XDP_ACT_NDO_XMIT;
@@ -1128,7 +1130,8 @@ static int lan966x_probe(struct platform_device *pdev)
 	lan966x->dev = &pdev->dev;
 	lan966x->dma_dev = lan966x_get_dma_dev(lan966x->dev);
 
-	lan966x->ops = &lan966x_fdma_ops;
+	lan966x->ops = lan966x_is_pci(lan966x) ? &lan966x_fdma_pci_ops :
+						 &lan966x_fdma_ops;
 
 	if (!device_get_mac_address(&pdev->dev, mac_addr)) {
 		ether_addr_copy(lan966x->base_mac, mac_addr);
@@ -1187,7 +1190,9 @@ static int lan966x_probe(struct platform_device *pdev)
 		if (err)
 			return dev_err_probe(&pdev->dev, err, "Unable to use ptp irq");
 
-		lan966x->ptp = 1;
+		/* PTP is not supported on the PCIe path yet. */
+		if (!lan966x_is_pci(lan966x))
+			lan966x->ptp = 1;
 	}
 
 	lan966x->fdma_irq = platform_get_irq_byname(pdev, "fdma");
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.h b/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
index aab5e53ed059..16bc28c8f11f 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
@@ -17,6 +17,7 @@
 #include <net/xdp.h>
 
 #include <fdma_api.h>
+#include <fdma_pci.h>
 #include <vcap_api.h>
 #include <vcap_api_client.h>
 
@@ -291,6 +292,10 @@ struct lan966x {
 
 	void __iomem *regs[NUM_TARGETS];
 
+#if IS_ENABLED(CONFIG_MCHP_LAN966X_PCI)
+	struct fdma_pci_atu atu;
+#endif
+
 	int shared_queue_sz;
 
 	u8 base_mac[ETH_ALEN];
@@ -589,6 +594,8 @@ void lan966x_fdma_wakeup_netdev(struct lan966x *lan966x);
 int lan966x_fdma_get_max_frame(struct lan966x *lan966x);
 int lan966x_qsys_sw_status(struct lan966x *lan966x);
 
+extern const struct lan966x_fdma_ops lan966x_fdma_pci_ops;
+
 /* dma_dev differs from dev only on the PCIe path. */
 static inline bool lan966x_is_pci(struct lan966x *lan966x)
 {
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_regs.h b/drivers/net/ethernet/microchip/lan966x/lan966x_regs.h
index aba0d36ae6b5..4778ea217673 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_regs.h
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_regs.h
@@ -20,6 +20,7 @@ enum lan966x_target {
 	TARGET_FDMA = 21,
 	TARGET_GCB = 27,
 	TARGET_ORG = 36,
+	TARGET_PCIE_DBI = 40,
 	TARGET_PTP = 41,
 	TARGET_QS = 42,
 	TARGET_QSYS = 46,
@@ -1009,6 +1010,15 @@ enum lan966x_target {
 #define FDMA_CH_CFG_CH_MEM_GET(x)\
 	FIELD_GET(FDMA_CH_CFG_CH_MEM, x)
 
+/*      FDMA:FDMA:FDMA_CTRL */
+#define FDMA_CTRL                 __REG(TARGET_FDMA, 0, 1, 8, 0, 1, 428, 424, 0, 1, 4)
+
+#define FDMA_CTRL_NRESET                         BIT(0)
+#define FDMA_CTRL_NRESET_SET(x)\
+	FIELD_PREP(FDMA_CTRL_NRESET, x)
+#define FDMA_CTRL_NRESET_GET(x)\
+	FIELD_GET(FDMA_CTRL_NRESET, x)
+
 /*      FDMA:FDMA:FDMA_PORT_CTRL */
 #define FDMA_PORT_CTRL(r)         __REG(TARGET_FDMA, 0, 1, 8, 0, 1, 428, 376, r, 2, 4)
 
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_xdp.c b/drivers/net/ethernet/microchip/lan966x/lan966x_xdp.c
index 9ee61db8690b..e63634887f64 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_xdp.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_xdp.c
@@ -20,6 +20,12 @@ static int lan966x_xdp_setup(struct net_device *dev, struct netdev_bpf *xdp)
 		return -EOPNOTSUPP;
 	}
 
+	if (lan966x_is_pci(lan966x)) {
+		NL_SET_ERR_MSG_MOD(xdp->extack,
+				   "XDP is not supported on the PCIe FDMA path");
+		return -EOPNOTSUPP;
+	}
+
 	old_xdp = lan966x_xdp_present(lan966x);
 	old_prog = xchg(&port->xdp_prog, xdp->prog);
 	new_xdp = lan966x_xdp_present(lan966x);

-- 
2.34.1

Re: [PATCH net-next v7 10/14] net: lan966x: add PCIe FDMA support

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 6 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 4 (1) · Low: 2

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] DISCARDED (resolved later in the series): claim that the new {
  TARGET_PCIE_DBI, 0x400000, 0 } iomap entry points 3 MiB past the end…
- [Medium] DISCARDED (resolved later in the series): claim that
  lan966x_fdma_pci_resize() returning -EOPNOTSUPP unconditionally makes…
- [Medium] The PCIe FDMA path places hardware descriptors in host memory
  and lets the LAN966x endpoint fetch them over PCIe, but every…
- [Medium] net: lan966x: rx_bytes statistic undercounts received frame
  size
- [Low] DISCARDED (resolved later in the series): claim that the PCIe
  FDMA backend is dead code because drivers/misc/lan966x_pci.dtso…
- [Low] In lan966x_fdma_pci_napi_poll() the FDMA_ERROR arm carries the
  comment "No rx_dropped increment here because src_port is invalid.",…

Pre-existing issues:
- [Medium] DISCARDED: claim that __fdma_dcb_add() links a new DCB into
  the live hardware chain (writing fdma->last_dcb->nextptr) before…

--

net: lan966x: add PCIe FDMA support

This adds a second FDMA backend for lan966x that is selected when the
switch is enumerated over PCIe. It uses contiguous coherent DMA buffers
mapped through the endpoint ATU and memcpy-based frame transfer, and it
opts out of XDP and PTP on that path.

A couple of questions about the new path below.

> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> new file mode 100644
> index 000000000000..5d6902459f20
> --- /dev/null
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> @@ -0,0 +1,421 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +#include "fdma_api.h"
> +#include "lan966x_main.h"
> +
> +static int lan966x_fdma_pci_dataptr_cb(struct fdma *fdma, int dcb, int db,
> +				       u64 *dataptr)
> +{
> +	u64 addr;
> +
> +	addr = fdma_dataptr_dma_addr_contiguous(fdma, dcb, db);
> +
> +	*dataptr = fdma_pci_atu_translate_addr(fdma->atu_region, addr);
> +
> +	return 0;
> +}
> +
> +static int lan966x_fdma_pci_nextptr_cb(struct fdma *fdma, int dcb, u64 *nextptr)
> +{
> +	u64 addr;
> +
> +	fdma_nextptr_cb(fdma, dcb, &addr);
> +
> +	*nextptr = fdma_pci_atu_translate_addr(fdma->atu_region, addr);
> +
> +	return 0;
> +}

[Severity: Medium]
Is this path expected to work on a big-endian host?

Until now the descriptor producer and the FDMA engine were both on the
little-endian SoC, so the native-endian descriptor layout in
drivers/net/ethernet/microchip/fdma/fdma_api.h was fine:

  struct fdma_db {
  	u64 dataptr;
  	u64 status;
  };

  struct fdma_dcb {
  	u64 nextptr;
  	u64 info;
  	struct fdma_db db[FDMA_DB_MAX];
  };

With PCIe FDMA the descriptors live in host memory and are fetched by the
endpoint, so the host and the engine can disagree on byte order. The
translated addresses written here, and the status/info words written by
__fdma_db_add()/__fdma_dcb_add(), all go out in host byte order, and the
HW-written DONE/BLOCKL fields are read back the same way in
lan966x_fdma_pci_get_next_dcb() and lan966x_fdma_pci_rx_check_frame().

CONFIG_MCHP_LAN966X_PCI in drivers/misc/Kconfig only has

  depends on PCI
  depends on OF_OVERLAY

so a big-endian host (e.g. powerpc) can select it. On such a host, would
the engine see byte-swapped nextptr/dataptr and length fields, i.e. would
RX/TX not work at all? Should the descriptor fields become explicit
little-endian types with accessors at the hardware boundary, or should the
Kconfig entry gain a little-endian dependency?

[ ... ]

> +static int lan966x_fdma_pci_rx_check_frame(struct lan966x_rx *rx, u64 *src_port)
> +{
[ ... ]
> +	lan966x_ifh_get_src_port(virt_addr, src_port);
> +
> +	if (*src_port >= lan966x->num_phys_ports)
> +		return FDMA_ERROR;
> +
> +	port = lan966x->ports[*src_port];
> +	if (!port)
> +		return FDMA_ERROR;
> +
> +	db = fdma_db_next_get(fdma);
> +
> +	/* BLOCKL is a 16-bit HW-populated field; reject obviously-bad
> +	 * values before they feed memcpy/XDP sizes.
> +	 */
> +	blockl = FDMA_DCB_STATUS_BLOCKL(db->status);
> +	if (!lan966x_fdma_pci_rx_size_fits(fdma, blockl))
> +		return FDMA_ERROR;
> +
> +	return FDMA_PASS;
> +}

[ ... ]

> +		switch (lan966x_fdma_pci_rx_check_frame(rx, &src_port)) {
> +		case FDMA_PASS:
> +			break;
> +		case FDMA_ERROR:
> +			/* No rx_dropped increment here because src_port is
> +			 * invalid.
> +			 */
> +			fdma_dcb_advance(fdma);
> +			continue;
> +		}

[Severity: Low]
Is this comment accurate for all FDMA_ERROR cases?

lan966x_fdma_pci_rx_check_frame() also returns FDMA_ERROR for a BLOCKL
value rejected by lan966x_fdma_pci_rx_size_fits(), and that check runs
after *src_port and lan966x->ports[*src_port] have already been validated.

So for a frame whose BLOCKL is below IFH_LEN_BYTES + ETH_HLEN +
ETH_FCS_LEN or above db_size - XDP_PACKET_HEADROOM, src_port is known
good, yet the frame is dropped without incrementing rx_dropped on
lan966x->ports[src_port]->dev.

Would it make sense to distinguish the two failures so the size-rejected
frames get counted, and adjust the comment accordingly?

[ ... ]

> @@ -0,0 +1,421 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +#include "fdma_api.h"
> +#include "lan966x_main.h"
> +
> +static int lan966x_fdma_pci_dataptr_cb(struct fdma *fdma, int dcb, int db,
> +				       u64 *dataptr)
> +{
> +	u64 addr;
> +
> +	addr = fdma_dataptr_dma_addr_contiguous(fdma, dcb, db);
> +
> +	*dataptr = fdma_pci_atu_translate_addr(fdma->atu_region, addr);
> +
> +	return 0;
> +}
> +
> +static int lan966x_fdma_pci_nextptr_cb(struct fdma *fdma, int dcb, u64 *nextptr)
> +{
> +	u64 addr;
> +
> +	fdma_nextptr_cb(fdma, dcb, &addr);
> +
> +	*nextptr = fdma_pci_atu_translate_addr(fdma->atu_region, addr);
> +
> +	return 0;
> +}
> +
> +/* Stop the TX queues on every port, so nothing feeds the injection channel
> + * while it is torn down or resized.
> + */
> +static void lan966x_fdma_tx_disable_netdev(struct lan966x *lan966x)
> +{
> +	struct lan966x_port *port;
> +	int i;
> +
> +	for (i = 0; i < lan966x->num_phys_ports; ++i) {
> +		port = lan966x->ports[i];
> +		if (!port)
> +			continue;
> +
> +		netif_tx_disable(port->dev);
> +	}
> +}
> +
> +static int lan966x_fdma_pci_rx_alloc(struct lan966x_rx *rx)
> +{
> +	struct lan966x *lan966x = rx->lan966x;
> +	struct fdma *fdma = &rx->fdma;
> +	int err;
> +
> +	err = fdma_alloc_coherent_and_map(lan966x->dma_dev, fdma,
> +					  &lan966x->atu);
> +	if (err)
> +		return err;
> +
> +	err = fdma_dcbs_init(fdma,
> +			     FDMA_DCB_INFO_DATAL(fdma->db_size - XDP_PACKET_HEADROOM),
> +			     FDMA_DCB_STATUS_INTR);
> +	if (err) {
> +		fdma_free_coherent_and_unmap(lan966x->dma_dev, fdma);
> +		return err;
> +	}
> +
> +	lan966x_fdma_llp_configure(lan966x,
> +				   fdma->atu_region->base_addr,
> +				   fdma->channel_id);
> +
> +	return 0;
> +}
> +
> +static int lan966x_fdma_pci_tx_alloc(struct lan966x_tx *tx)
> +{
> +	struct lan966x *lan966x = tx->lan966x;
> +	struct fdma *fdma = &tx->fdma;
> +	int err;
> +
> +	err = fdma_alloc_coherent_and_map(lan966x->dma_dev, fdma,
> +					  &lan966x->atu);
> +	if (err)
> +		return err;
> +
> +	err = fdma_dcbs_init(fdma,
> +			     FDMA_DCB_INFO_DATAL(fdma->db_size),
> +			     FDMA_DCB_STATUS_DONE);
> +	if (err) {
> +		fdma_free_coherent_and_unmap(lan966x->dma_dev, fdma);
> +		return err;
> +	}
> +
> +	lan966x_fdma_llp_configure(lan966x,
> +				   fdma->atu_region->base_addr,
> +				   fdma->channel_id);
> +
> +	return 0;
> +}
> +
> +static int lan966x_fdma_pci_get_next_dcb(struct fdma *fdma)
> +{
> +	struct fdma_db *db;
> +
> +	for (int i = 0; i < fdma->n_dcbs; i++) {
> +		db = fdma_db_get(fdma, i, 0);
> +
> +		if (!fdma_db_is_done(db))
> +			continue;
> +		if (fdma_is_last(fdma, &fdma->dcbs[i]))
> +			continue;
> +
> +		return i;
> +	}
> +
> +	return -ENOSPC;
> +}
> +
> +/* TX slot layout (sizes in bytes):
> + *
> + *  +---------------------+-----+---------+-----+
> + *  | XDP_PACKET_HEADROOM | IFH | payload | FCS |
> + *  |         256         |  28 |   len   |   4 |
> + *  +---------------------+-----+---------+-----+
> + *  |<---------------- db_size ----------------->|
> + *
> + * Return true if the frame plus required overhead fits.
> + */
> +static bool lan966x_fdma_pci_tx_size_fits(struct fdma *fdma, u32 len)
> +{
> +	return XDP_PACKET_HEADROOM + IFH_LEN_BYTES + len + ETH_FCS_LEN <=
> +	       fdma->db_size;
> +}
> +
> +/* Return true if blockl is a valid RX frame size. */
> +static bool lan966x_fdma_pci_rx_size_fits(struct fdma *fdma, u32 blockl)
> +{
> +	return blockl >= IFH_LEN_BYTES + ETH_HLEN + ETH_FCS_LEN &&
> +	       blockl <= fdma->db_size - XDP_PACKET_HEADROOM;
> +}
> +
> +static int lan966x_fdma_pci_rx_check_frame(struct lan966x_rx *rx, u64 *src_port)
> +{
> +	struct lan966x *lan966x = rx->lan966x;
> +	struct fdma *fdma = &rx->fdma;
> +	struct lan966x_port *port;
> +	struct fdma_db *db;
> +	void *virt_addr;
> +	u32 blockl;
> +
> +	/* virt_addr points to the IFH. */
> +	virt_addr = fdma_dataptr_virt_addr_contiguous(fdma,
> +						      fdma->dcb_index,
> +						      fdma->db_index);
> +
> +	lan966x_ifh_get_src_port(virt_addr, src_port);
> +
> +	if (*src_port >= lan966x->num_phys_ports)
> +		return FDMA_ERROR;
> +
> +	port = lan966x->ports[*src_port];
> +	if (!port)
> +		return FDMA_ERROR;
> +
> +	db = fdma_db_next_get(fdma);
> +
> +	/* BLOCKL is a 16-bit HW-populated field; reject obviously-bad
> +	 * values before they feed memcpy/XDP sizes.
> +	 */
> +	blockl = FDMA_DCB_STATUS_BLOCKL(db->status);
> +	if (!lan966x_fdma_pci_rx_size_fits(fdma, blockl))
> +		return FDMA_ERROR;
> +
> +	return FDMA_PASS;
> +}
> +
> +static struct sk_buff *lan966x_fdma_pci_rx_get_frame(struct lan966x_rx *rx,
> +						     u64 src_port)
> +{
> +	struct lan966x *lan966x = rx->lan966x;
> +	struct fdma *fdma = &rx->fdma;
> +	struct sk_buff *skb;
> +	struct fdma_db *db;
> +	u32 data_len;
> +
> +	/* Get the received frame and create an SKB for it. */
> +	db = fdma_db_next_get(fdma);
> +	data_len = FDMA_DCB_STATUS_BLOCKL(db->status);
> +
> +	skb = napi_alloc_skb(&lan966x->napi, data_len);
> +	if (unlikely(!skb))
> +		return NULL;
> +
> +	memcpy(skb->data,
> +	       fdma_dataptr_virt_addr_contiguous(fdma,
> +						 fdma->dcb_index,
> +						 fdma->db_index),
> +						 data_len);
> +
> +	skb_put(skb, data_len);
> +
> +	skb->dev = lan966x->ports[src_port]->dev;
> +	skb_pull(skb, IFH_LEN_BYTES);
> +
> +	skb_trim(skb, skb->len - ETH_FCS_LEN);
> +
> +	skb->protocol = eth_type_trans(skb, skb->dev);
> +
> +	if (lan966x->bridge_mask & BIT(src_port)) {
> +		skb->offload_fwd_mark = 1;
> +
> +		skb_reset_network_header(skb);
> +		if (!lan966x_hw_offload(lan966x, src_port, skb))
> +			skb->offload_fwd_mark = 0;
> +	}
> +
> +	skb->dev->stats.rx_bytes += skb->len;
> +	skb->dev->stats.rx_packets++;
> +
> +	return skb;
> +}
> +
> +static int lan966x_fdma_pci_xmit(struct sk_buff *skb, __be32 *ifh,
> +				 struct net_device *dev)
> +{
> +	struct lan966x_port *port = netdev_priv(dev);
> +	struct lan966x *lan966x = port->lan966x;
> +	struct lan966x_tx *tx = &lan966x->tx;
> +	struct fdma *fdma = &tx->fdma;
> +	int next_to_use;
> +	void *virt_addr;
> +
> +	next_to_use = lan966x_fdma_pci_get_next_dcb(fdma);
> +
> +	if (next_to_use < 0) {
> +		netif_stop_queue(dev);
> +		return NETDEV_TX_BUSY;
> +	}
> +
> +	if (skb_put_padto(skb, ETH_ZLEN)) {
> +		dev->stats.tx_dropped++;
> +		return NETDEV_TX_OK;
> +	}
> +
> +	if (!lan966x_fdma_pci_tx_size_fits(fdma, skb->len)) {
> +		dev_kfree_skb_any(skb);
> +		dev->stats.tx_dropped++;
> +		return NETDEV_TX_OK;
> +	}
> +
> +	skb_tx_timestamp(skb);
> +
> +	/* virt_addr points to the IFH. */
> +	virt_addr = fdma_dataptr_virt_addr_contiguous(fdma, next_to_use, 0);
> +	memcpy(virt_addr, ifh, IFH_LEN_BYTES);
> +	memcpy(virt_addr + IFH_LEN_BYTES, skb->data, skb->len);
> +
> +	/* Order frame write before DCB status write below. */
> +	dma_wmb();
> +
> +	fdma_dcb_add(fdma,
> +		     next_to_use,
> +		     0,
> +		     FDMA_DCB_STATUS_INTR |
> +		     FDMA_DCB_STATUS_SOF |
> +		     FDMA_DCB_STATUS_EOF |
> +		     FDMA_DCB_STATUS_BLOCKO(0) |
> +		     FDMA_DCB_STATUS_BLOCKL(IFH_LEN_BYTES + skb->len + ETH_FCS_LEN));
> +
> +	/* Start the transmission. */
> +	lan966x_fdma_tx_start(tx);
> +
> +	dev->stats.tx_bytes += skb->len;
> +	dev->stats.tx_packets++;
> +
> +	/* Safe to free: PTP is not supported on the PCIe path yet,
> +	 * so lan966x->ptp is always 0 here.
> +	 */
> +	dev_consume_skb_any(skb);
> +
> +	return NETDEV_TX_OK;
> +}
> +
> +static int lan966x_fdma_pci_napi_poll(struct napi_struct *napi, int weight)
> +{
> +	struct lan966x *lan966x = container_of(napi, struct lan966x, napi);
> +	struct lan966x_rx *rx = &lan966x->rx;
> +	struct fdma *fdma = &rx->fdma;
> +	int dcb_reload, old_dcb;
> +	struct sk_buff *skb;
> +	int counter = 0;
> +	u64 src_port;
> +
> +	/* Wake any stopped TX queues if a TX DCB is available. */
> +	spin_lock(&lan966x->tx_lock);
> +	if (lan966x_fdma_pci_get_next_dcb(&lan966x->tx.fdma) >= 0)
> +		lan966x_fdma_wakeup_netdev(lan966x);
> +	spin_unlock(&lan966x->tx_lock);
> +
> +	dcb_reload = fdma->dcb_index;
> +
> +	/* Get all received skbs. */
> +	while (counter < weight) {
> +		if (!fdma_has_frames(fdma))
> +			break;
> +		/* Order DONE read before DCB/frame reads below. */
> +		dma_rmb();
> +		counter++;
> +		switch (lan966x_fdma_pci_rx_check_frame(rx, &src_port)) {
> +		case FDMA_PASS:
> +			break;
> +		case FDMA_ERROR:
> +			/* No rx_dropped increment here because src_port is
> +			 * invalid.
> +			 */
> +			fdma_dcb_advance(fdma);
> +			continue;
> +		}
> +		skb = lan966x_fdma_pci_rx_get_frame(rx, src_port);
> +		fdma_dcb_advance(fdma);
> +		if (!skb) {
> +			lan966x->ports[src_port]->dev->stats.rx_dropped++;
> +			continue;
> +		}
> +
> +		napi_gro_receive(&lan966x->napi, skb);
> +	}
> +	while (dcb_reload != fdma->dcb_index) {
> +		old_dcb = dcb_reload;
> +		dcb_reload++;
> +		dcb_reload &= fdma->n_dcbs - 1;
> +
> +		fdma_dcb_add(fdma,
> +			     old_dcb,
> +			     FDMA_DCB_INFO_DATAL(fdma->db_size - XDP_PACKET_HEADROOM),
> +			     FDMA_DCB_STATUS_INTR);
> +
> +		lan966x_fdma_rx_reload(rx);
> +	}
> +
> +	if (counter < weight && napi_complete_done(napi, counter))
> +		lan_wr(0xff, lan966x, FDMA_INTR_DB_ENA);
> +
> +	return counter;
> +}
> +
> +static int lan966x_fdma_pci_init(struct lan966x *lan966x)
> +{
> +	struct fdma *rx_fdma = &lan966x->rx.fdma;
> +	struct fdma *tx_fdma = &lan966x->tx.fdma;
> +	int err;
> +
> +	if (!lan966x->fdma)
> +		return 0;
> +
> +	lan_wr(FDMA_CTRL_NRESET_SET(0), lan966x, FDMA_CTRL);
> +	lan_wr(FDMA_CTRL_NRESET_SET(1), lan966x, FDMA_CTRL);
> +
> +	fdma_pci_atu_init(&lan966x->atu, lan966x->regs[TARGET_PCIE_DBI]);
> +
> +	lan966x->rx.lan966x = lan966x;
> +	lan966x->rx.max_mtu = lan966x_fdma_get_max_frame(lan966x);
> +	rx_fdma->channel_id = FDMA_XTR_CHANNEL;
> +	rx_fdma->n_dcbs = FDMA_DCB_MAX;
> +	rx_fdma->n_dbs = FDMA_RX_DCB_MAX_DBS;
> +	rx_fdma->priv = lan966x;
> +	rx_fdma->db_size = FDMA_PCI_DB_SIZE(lan966x->rx.max_mtu);
> +	rx_fdma->size = fdma_get_size_contiguous(rx_fdma);
> +	rx_fdma->ops.nextptr_cb = &lan966x_fdma_pci_nextptr_cb;
> +	rx_fdma->ops.dataptr_cb = &lan966x_fdma_pci_dataptr_cb;
> +
> +	lan966x->tx.lan966x = lan966x;
> +	tx_fdma->channel_id = FDMA_INJ_CHANNEL;
> +	tx_fdma->n_dcbs = FDMA_DCB_MAX;
> +	tx_fdma->n_dbs = FDMA_TX_DCB_MAX_DBS;
> +	tx_fdma->priv = lan966x;
> +	tx_fdma->db_size = FDMA_PCI_DB_SIZE(lan966x->rx.max_mtu);
> +	tx_fdma->size = fdma_get_size_contiguous(tx_fdma);
> +	tx_fdma->ops.nextptr_cb = &lan966x_fdma_pci_nextptr_cb;
> +	tx_fdma->ops.dataptr_cb = &lan966x_fdma_pci_dataptr_cb;
> +
> +	err = lan966x_fdma_pci_rx_alloc(&lan966x->rx);
> +	if (err)
> +		return err;
> +
> +	err = lan966x_fdma_pci_tx_alloc(&lan966x->tx);
> +	if (err) {
> +		fdma_free_coherent_and_unmap(lan966x->dma_dev, rx_fdma);
> +		return err;
> +	}
> +
> +	lan966x_fdma_rx_start(&lan966x->rx);
> +
> +	return 0;
> +}
> +
> +static int lan966x_fdma_pci_resize(struct lan966x *lan966x)
> +{
> +	return -EOPNOTSUPP;
> +}
> +
> +static void lan966x_fdma_pci_deinit(struct lan966x *lan966x)
> +{
> +	if (!lan966x->fdma)
> +		return;
> +
> +	if (lan966x->fdma_ndev)
> +		napi_disable(&lan966x->napi);
> +
> +	lan966x_fdma_tx_disable_netdev(lan966x);
> +	lan966x_fdma_rx_disable(&lan966x->rx);
> +	lan966x_fdma_tx_disable(&lan966x->tx);
> +
> +	fdma_free_coherent_and_unmap(lan966x->dma_dev, &lan966x->rx.fdma);
> +	fdma_free_coherent_and_unmap(lan966x->dma_dev, &lan966x->tx.fdma);
> +}
> +
> +const struct lan966x_fdma_ops lan966x_fdma_pci_ops = {
> +	.fdma_init = &lan966x_fdma_pci_init,
> +	.fdma_deinit = &lan966x_fdma_pci_deinit,
> +	.fdma_xmit = &lan966x_fdma_pci_xmit,
> +	.fdma_poll = &lan966x_fdma_pci_napi_poll,
> +	.fdma_resize = &lan966x_fdma_pci_resize,
> +};

[Severity: Medium]
Is rx_bytes meant to count the frame as it arrived on the wire?

By the time this runs, skb->len has already been reduced twice: the
skb_trim() above drops ETH_FCS_LEN, and eth_type_trans() pulls the
MAC header out of the linear region, so skb->len is short by at least
ETH_HLEN. If lan966x_hw_offload() ends up untagging a VLAN header,
that is another four bytes gone. So every packet delivered through
lan966x_fdma_pci_rx_get_frame() undercounts rx_bytes by 14 bytes or
more, which is visible to userspace via ip -s link.

The frame length is available before any of that surgery happens --
data_len from FDMA_DCB_STATUS_BLOCKL(db->status), or skb->len right
after the skb_pull(skb, IFH_LEN_BYTES) -- so accounting could be done
there instead.

I realise this mirrors what the existing register/page path in
lan966x_fdma.c does, so if the intent is to keep the two backends
byte-for-byte consistent, please say so; otherwise it would be good
not to copy the miscount into the new file.

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260918-lan966x-pci-fdma-v7-0-0ecc179c8a2c%40microchip.com

Re: [PATCH net-next v7 10/14] net: lan966x: add PCIe FDMA support

[Daniel Machon]

> Thank you for your contribution! Sashiko AI review found 6 potential
> issue(s) to consider.
> 
> Critical: 0 · High: 0 · Medium: 4 (1) · Low: 2
> 
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
> 
> - [Medium] DISCARDED (resolved later in the series): claim that the new {
>   TARGET_PCIE_DBI, 0x400000, 0 } iomap entry points 3 MiB past the end…
> - [Medium] DISCARDED (resolved later in the series): claim that
>   lan966x_fdma_pci_resize() returning -EOPNOTSUPP unconditionally makes…
> - [Medium] The PCIe FDMA path places hardware descriptors in host memory
>   and lets the LAN966x endpoint fetch them over PCIe, but every…
> - [Medium] net: lan966x: rx_bytes statistic undercounts received frame
>   size
> - [Low] DISCARDED (resolved later in the series): claim that the PCIe
>   FDMA backend is dead code because drivers/misc/lan966x_pci.dtso…
> - [Low] In lan966x_fdma_pci_napi_poll() the FDMA_ERROR arm carries the
>   comment "No rx_dropped increment here because src_port is invalid.",…
> 
> Pre-existing issues:
> - [Medium] DISCARDED: claim that __fdma_dcb_add() links a new DCB into
>   the live hardware chain (writing fdma->last_dcb->nextptr) before…
> 
> --
> 
> net: lan966x: add PCIe FDMA support
> 
> This adds a second FDMA backend for lan966x that is selected when the
> switch is enumerated over PCIe. It uses contiguous coherent DMA buffers
> mapped through the endpoint ATU and memcpy-based frame transfer, and it
> opts out of XDP and PTP on that path.
> 
> A couple of questions about the new path below.
> 
> > diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> > new file mode 100644
> > index 000000000000..5d6902459f20
> > --- /dev/null
> > +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> > @@ -0,0 +1,421 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +
> > +#include "fdma_api.h"
> > +#include "lan966x_main.h"
> > +
> > +static int lan966x_fdma_pci_dataptr_cb(struct fdma *fdma, int dcb, int db,
> > +                                    u64 *dataptr)
> > +{
> > +     u64 addr;
> > +
> > +     addr = fdma_dataptr_dma_addr_contiguous(fdma, dcb, db);
> > +
> > +     *dataptr = fdma_pci_atu_translate_addr(fdma->atu_region, addr);
> > +
> > +     return 0;
> > +}
> > +
> > +static int lan966x_fdma_pci_nextptr_cb(struct fdma *fdma, int dcb, u64 *nextptr)
> > +{
> > +     u64 addr;
> > +
> > +     fdma_nextptr_cb(fdma, dcb, &addr);
> > +
> > +     *nextptr = fdma_pci_atu_translate_addr(fdma->atu_region, addr);
> > +
> > +     return 0;
> > +}
> 
> [Severity: Medium]
> Is this path expected to work on a big-endian host?
> 
> Until now the descriptor producer and the FDMA engine were both on the
> little-endian SoC, so the native-endian descriptor layout in
> drivers/net/ethernet/microchip/fdma/fdma_api.h was fine:
> 
>   struct fdma_db {
>         u64 dataptr;
>         u64 status;
>   };
> 
>   struct fdma_dcb {
>         u64 nextptr;
>         u64 info;
>         struct fdma_db db[FDMA_DB_MAX];
>   };
> 
> With PCIe FDMA the descriptors live in host memory and are fetched by the
> endpoint, so the host and the engine can disagree on byte order. The
> translated addresses written here, and the status/info words written by
> __fdma_db_add()/__fdma_dcb_add(), all go out in host byte order, and the
> HW-written DONE/BLOCKL fields are read back the same way in
> lan966x_fdma_pci_get_next_dcb() and lan966x_fdma_pci_rx_check_frame().
> 
> CONFIG_MCHP_LAN966X_PCI in drivers/misc/Kconfig only has
> 
>   depends on PCI
>   depends on OF_OVERLAY
> 
> so a big-endian host (e.g. powerpc) can select it. On such a host, would
> the engine see byte-swapped nextptr/dataptr and length fields, i.e. would
> RX/TX not work at all? Should the descriptor fields become explicit
> little-endian types with accessors at the hardware boundary, or should the
> Kconfig entry gain a little-endian dependency?

Hmm. Never tested on PowerPC, not this driver nor the DT overlay mechanism it
relies on for PCI deployment, which has only been exercised on ARM and x86 so
far (AFAICT) [1].

[1] https://lore.kernel.org/all/20240430183301.46568e35@bootlin.com/

> 
> [ ... ]
> 
> > +static int lan966x_fdma_pci_rx_check_frame(struct lan966x_rx *rx, u64 *src_port)
> > +{
> [ ... ]
> > +     lan966x_ifh_get_src_port(virt_addr, src_port);
> > +
> > +     if (*src_port >= lan966x->num_phys_ports)
> > +             return FDMA_ERROR;
> > +
> > +     port = lan966x->ports[*src_port];
> > +     if (!port)
> > +             return FDMA_ERROR;
> > +
> > +     db = fdma_db_next_get(fdma);
> > +
> > +     /* BLOCKL is a 16-bit HW-populated field; reject obviously-bad
> > +      * values before they feed memcpy/XDP sizes.
> > +      */
> > +     blockl = FDMA_DCB_STATUS_BLOCKL(db->status);
> > +     if (!lan966x_fdma_pci_rx_size_fits(fdma, blockl))
> > +             return FDMA_ERROR;
> > +
> > +     return FDMA_PASS;
> > +}
> 
> [ ... ]
> 
> > +             switch (lan966x_fdma_pci_rx_check_frame(rx, &src_port)) {
> > +             case FDMA_PASS:
> > +                     break;
> > +             case FDMA_ERROR:
> > +                     /* No rx_dropped increment here because src_port is
> > +                      * invalid.
> > +                      */
> > +                     fdma_dcb_advance(fdma);
> > +                     continue;
> > +             }
> 
> [Severity: Low]
> Is this comment accurate for all FDMA_ERROR cases?
> 
> lan966x_fdma_pci_rx_check_frame() also returns FDMA_ERROR for a BLOCKL
> value rejected by lan966x_fdma_pci_rx_size_fits(), and that check runs
> after *src_port and lan966x->ports[*src_port] have already been validated.
> 
> So for a frame whose BLOCKL is below IFH_LEN_BYTES + ETH_HLEN +
> ETH_FCS_LEN or above db_size - XDP_PACKET_HEADROOM, src_port is known
> good, yet the frame is dropped without incrementing rx_dropped on
> lan966x->ports[src_port]->dev.
> 
> Would it make sense to distinguish the two failures so the size-rejected
> frames get counted, and adjust the comment accordingly?
> 
> [ ... ]
> 
> > @@ -0,0 +1,421 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +
> > +#include "fdma_api.h"
> > +#include "lan966x_main.h"
> > +
> > +static int lan966x_fdma_pci_dataptr_cb(struct fdma *fdma, int dcb, int db,
> > +                                    u64 *dataptr)
> > +{
> > +     u64 addr;
> > +
> > +     addr = fdma_dataptr_dma_addr_contiguous(fdma, dcb, db);
> > +
> > +     *dataptr = fdma_pci_atu_translate_addr(fdma->atu_region, addr);
> > +
> > +     return 0;
> > +}
> > +
> > +static int lan966x_fdma_pci_nextptr_cb(struct fdma *fdma, int dcb, u64 *nextptr)
> > +{
> > +     u64 addr;
> > +
> > +     fdma_nextptr_cb(fdma, dcb, &addr);
> > +
> > +     *nextptr = fdma_pci_atu_translate_addr(fdma->atu_region, addr);
> > +
> > +     return 0;
> > +}
> > +
> > +/* Stop the TX queues on every port, so nothing feeds the injection channel
> > + * while it is torn down or resized.
> > + */
> > +static void lan966x_fdma_tx_disable_netdev(struct lan966x *lan966x)
> > +{
> > +     struct lan966x_port *port;
> > +     int i;
> > +
> > +     for (i = 0; i < lan966x->num_phys_ports; ++i) {
> > +             port = lan966x->ports[i];
> > +             if (!port)
> > +                     continue;
> > +
> > +             netif_tx_disable(port->dev);
> > +     }
> > +}
> > +
> > +static int lan966x_fdma_pci_rx_alloc(struct lan966x_rx *rx)
> > +{
> > +     struct lan966x *lan966x = rx->lan966x;
> > +     struct fdma *fdma = &rx->fdma;
> > +     int err;
> > +
> > +     err = fdma_alloc_coherent_and_map(lan966x->dma_dev, fdma,
> > +                                       &lan966x->atu);
> > +     if (err)
> > +             return err;
> > +
> > +     err = fdma_dcbs_init(fdma,
> > +                          FDMA_DCB_INFO_DATAL(fdma->db_size - XDP_PACKET_HEADROOM),
> > +                          FDMA_DCB_STATUS_INTR);
> > +     if (err) {
> > +             fdma_free_coherent_and_unmap(lan966x->dma_dev, fdma);
> > +             return err;
> > +     }
> > +
> > +     lan966x_fdma_llp_configure(lan966x,
> > +                                fdma->atu_region->base_addr,
> > +                                fdma->channel_id);
> > +
> > +     return 0;
> > +}
> > +
> > +static int lan966x_fdma_pci_tx_alloc(struct lan966x_tx *tx)
> > +{
> > +     struct lan966x *lan966x = tx->lan966x;
> > +     struct fdma *fdma = &tx->fdma;
> > +     int err;
> > +
> > +     err = fdma_alloc_coherent_and_map(lan966x->dma_dev, fdma,
> > +                                       &lan966x->atu);
> > +     if (err)
> > +             return err;
> > +
> > +     err = fdma_dcbs_init(fdma,
> > +                          FDMA_DCB_INFO_DATAL(fdma->db_size),
> > +                          FDMA_DCB_STATUS_DONE);
> > +     if (err) {
> > +             fdma_free_coherent_and_unmap(lan966x->dma_dev, fdma);
> > +             return err;
> > +     }
> > +
> > +     lan966x_fdma_llp_configure(lan966x,
> > +                                fdma->atu_region->base_addr,
> > +                                fdma->channel_id);
> > +
> > +     return 0;
> > +}
> > +
> > +static int lan966x_fdma_pci_get_next_dcb(struct fdma *fdma)
> > +{
> > +     struct fdma_db *db;
> > +
> > +     for (int i = 0; i < fdma->n_dcbs; i++) {
> > +             db = fdma_db_get(fdma, i, 0);
> > +
> > +             if (!fdma_db_is_done(db))
> > +                     continue;
> > +             if (fdma_is_last(fdma, &fdma->dcbs[i]))
> > +                     continue;
> > +
> > +             return i;
> > +     }
> > +
> > +     return -ENOSPC;
> > +}
> > +
> > +/* TX slot layout (sizes in bytes):
> > + *
> > + *  +---------------------+-----+---------+-----+
> > + *  | XDP_PACKET_HEADROOM | IFH | payload | FCS |
> > + *  |         256         |  28 |   len   |   4 |
> > + *  +---------------------+-----+---------+-----+
> > + *  |<---------------- db_size ----------------->|
> > + *
> > + * Return true if the frame plus required overhead fits.
> > + */
> > +static bool lan966x_fdma_pci_tx_size_fits(struct fdma *fdma, u32 len)
> > +{
> > +     return XDP_PACKET_HEADROOM + IFH_LEN_BYTES + len + ETH_FCS_LEN <=
> > +            fdma->db_size;
> > +}
> > +
> > +/* Return true if blockl is a valid RX frame size. */
> > +static bool lan966x_fdma_pci_rx_size_fits(struct fdma *fdma, u32 blockl)
> > +{
> > +     return blockl >= IFH_LEN_BYTES + ETH_HLEN + ETH_FCS_LEN &&
> > +            blockl <= fdma->db_size - XDP_PACKET_HEADROOM;
> > +}
> > +
> > +static int lan966x_fdma_pci_rx_check_frame(struct lan966x_rx *rx, u64 *src_port)
> > +{
> > +     struct lan966x *lan966x = rx->lan966x;
> > +     struct fdma *fdma = &rx->fdma;
> > +     struct lan966x_port *port;
> > +     struct fdma_db *db;
> > +     void *virt_addr;
> > +     u32 blockl;
> > +
> > +     /* virt_addr points to the IFH. */
> > +     virt_addr = fdma_dataptr_virt_addr_contiguous(fdma,
> > +                                                   fdma->dcb_index,
> > +                                                   fdma->db_index);
> > +
> > +     lan966x_ifh_get_src_port(virt_addr, src_port);
> > +
> > +     if (*src_port >= lan966x->num_phys_ports)
> > +             return FDMA_ERROR;
> > +
> > +     port = lan966x->ports[*src_port];
> > +     if (!port)
> > +             return FDMA_ERROR;
> > +
> > +     db = fdma_db_next_get(fdma);
> > +
> > +     /* BLOCKL is a 16-bit HW-populated field; reject obviously-bad
> > +      * values before they feed memcpy/XDP sizes.
> > +      */
> > +     blockl = FDMA_DCB_STATUS_BLOCKL(db->status);
> > +     if (!lan966x_fdma_pci_rx_size_fits(fdma, blockl))
> > +             return FDMA_ERROR;
> > +
> > +     return FDMA_PASS;
> > +}
> > +
> > +static struct sk_buff *lan966x_fdma_pci_rx_get_frame(struct lan966x_rx *rx,
> > +                                                  u64 src_port)
> > +{
> > +     struct lan966x *lan966x = rx->lan966x;
> > +     struct fdma *fdma = &rx->fdma;
> > +     struct sk_buff *skb;
> > +     struct fdma_db *db;
> > +     u32 data_len;
> > +
> > +     /* Get the received frame and create an SKB for it. */
> > +     db = fdma_db_next_get(fdma);
> > +     data_len = FDMA_DCB_STATUS_BLOCKL(db->status);
> > +
> > +     skb = napi_alloc_skb(&lan966x->napi, data_len);
> > +     if (unlikely(!skb))
> > +             return NULL;
> > +
> > +     memcpy(skb->data,
> > +            fdma_dataptr_virt_addr_contiguous(fdma,
> > +                                              fdma->dcb_index,
> > +                                              fdma->db_index),
> > +                                              data_len);
> > +
> > +     skb_put(skb, data_len);
> > +
> > +     skb->dev = lan966x->ports[src_port]->dev;
> > +     skb_pull(skb, IFH_LEN_BYTES);
> > +
> > +     skb_trim(skb, skb->len - ETH_FCS_LEN);
> > +
> > +     skb->protocol = eth_type_trans(skb, skb->dev);
> > +
> > +     if (lan966x->bridge_mask & BIT(src_port)) {
> > +             skb->offload_fwd_mark = 1;
> > +
> > +             skb_reset_network_header(skb);
> > +             if (!lan966x_hw_offload(lan966x, src_port, skb))
> > +                     skb->offload_fwd_mark = 0;
> > +     }
> > +
> > +     skb->dev->stats.rx_bytes += skb->len;
> > +     skb->dev->stats.rx_packets++;
> > +
> > +     return skb;
> > +}
> > +
> > +static int lan966x_fdma_pci_xmit(struct sk_buff *skb, __be32 *ifh,
> > +                              struct net_device *dev)
> > +{
> > +     struct lan966x_port *port = netdev_priv(dev);
> > +     struct lan966x *lan966x = port->lan966x;
> > +     struct lan966x_tx *tx = &lan966x->tx;
> > +     struct fdma *fdma = &tx->fdma;
> > +     int next_to_use;
> > +     void *virt_addr;
> > +
> > +     next_to_use = lan966x_fdma_pci_get_next_dcb(fdma);
> > +
> > +     if (next_to_use < 0) {
> > +             netif_stop_queue(dev);
> > +             return NETDEV_TX_BUSY;
> > +     }
> > +
> > +     if (skb_put_padto(skb, ETH_ZLEN)) {
> > +             dev->stats.tx_dropped++;
> > +             return NETDEV_TX_OK;
> > +     }
> > +
> > +     if (!lan966x_fdma_pci_tx_size_fits(fdma, skb->len)) {
> > +             dev_kfree_skb_any(skb);
> > +             dev->stats.tx_dropped++;
> > +             return NETDEV_TX_OK;
> > +     }
> > +
> > +     skb_tx_timestamp(skb);
> > +
> > +     /* virt_addr points to the IFH. */
> > +     virt_addr = fdma_dataptr_virt_addr_contiguous(fdma, next_to_use, 0);
> > +     memcpy(virt_addr, ifh, IFH_LEN_BYTES);
> > +     memcpy(virt_addr + IFH_LEN_BYTES, skb->data, skb->len);
> > +
> > +     /* Order frame write before DCB status write below. */
> > +     dma_wmb();
> > +
> > +     fdma_dcb_add(fdma,
> > +                  next_to_use,
> > +                  0,
> > +                  FDMA_DCB_STATUS_INTR |
> > +                  FDMA_DCB_STATUS_SOF |
> > +                  FDMA_DCB_STATUS_EOF |
> > +                  FDMA_DCB_STATUS_BLOCKO(0) |
> > +                  FDMA_DCB_STATUS_BLOCKL(IFH_LEN_BYTES + skb->len + ETH_FCS_LEN));
> > +
> > +     /* Start the transmission. */
> > +     lan966x_fdma_tx_start(tx);
> > +
> > +     dev->stats.tx_bytes += skb->len;
> > +     dev->stats.tx_packets++;
> > +
> > +     /* Safe to free: PTP is not supported on the PCIe path yet,
> > +      * so lan966x->ptp is always 0 here.
> > +      */
> > +     dev_consume_skb_any(skb);
> > +
> > +     return NETDEV_TX_OK;
> > +}
> > +
> > +static int lan966x_fdma_pci_napi_poll(struct napi_struct *napi, int weight)
> > +{
> > +     struct lan966x *lan966x = container_of(napi, struct lan966x, napi);
> > +     struct lan966x_rx *rx = &lan966x->rx;
> > +     struct fdma *fdma = &rx->fdma;
> > +     int dcb_reload, old_dcb;
> > +     struct sk_buff *skb;
> > +     int counter = 0;
> > +     u64 src_port;
> > +
> > +     /* Wake any stopped TX queues if a TX DCB is available. */
> > +     spin_lock(&lan966x->tx_lock);
> > +     if (lan966x_fdma_pci_get_next_dcb(&lan966x->tx.fdma) >= 0)
> > +             lan966x_fdma_wakeup_netdev(lan966x);
> > +     spin_unlock(&lan966x->tx_lock);
> > +
> > +     dcb_reload = fdma->dcb_index;
> > +
> > +     /* Get all received skbs. */
> > +     while (counter < weight) {
> > +             if (!fdma_has_frames(fdma))
> > +                     break;
> > +             /* Order DONE read before DCB/frame reads below. */
> > +             dma_rmb();
> > +             counter++;
> > +             switch (lan966x_fdma_pci_rx_check_frame(rx, &src_port)) {
> > +             case FDMA_PASS:
> > +                     break;
> > +             case FDMA_ERROR:
> > +                     /* No rx_dropped increment here because src_port is
> > +                      * invalid.
> > +                      */
> > +                     fdma_dcb_advance(fdma);
> > +                     continue;
> > +             }
> > +             skb = lan966x_fdma_pci_rx_get_frame(rx, src_port);
> > +             fdma_dcb_advance(fdma);
> > +             if (!skb) {
> > +                     lan966x->ports[src_port]->dev->stats.rx_dropped++;
> > +                     continue;
> > +             }
> > +
> > +             napi_gro_receive(&lan966x->napi, skb);
> > +     }
> > +     while (dcb_reload != fdma->dcb_index) {
> > +             old_dcb = dcb_reload;
> > +             dcb_reload++;
> > +             dcb_reload &= fdma->n_dcbs - 1;
> > +
> > +             fdma_dcb_add(fdma,
> > +                          old_dcb,
> > +                          FDMA_DCB_INFO_DATAL(fdma->db_size - XDP_PACKET_HEADROOM),
> > +                          FDMA_DCB_STATUS_INTR);
> > +
> > +             lan966x_fdma_rx_reload(rx);
> > +     }
> > +
> > +     if (counter < weight && napi_complete_done(napi, counter))
> > +             lan_wr(0xff, lan966x, FDMA_INTR_DB_ENA);
> > +
> > +     return counter;
> > +}
> > +
> > +static int lan966x_fdma_pci_init(struct lan966x *lan966x)
> > +{
> > +     struct fdma *rx_fdma = &lan966x->rx.fdma;
> > +     struct fdma *tx_fdma = &lan966x->tx.fdma;
> > +     int err;
> > +
> > +     if (!lan966x->fdma)
> > +             return 0;
> > +
> > +     lan_wr(FDMA_CTRL_NRESET_SET(0), lan966x, FDMA_CTRL);
> > +     lan_wr(FDMA_CTRL_NRESET_SET(1), lan966x, FDMA_CTRL);
> > +
> > +     fdma_pci_atu_init(&lan966x->atu, lan966x->regs[TARGET_PCIE_DBI]);
> > +
> > +     lan966x->rx.lan966x = lan966x;
> > +     lan966x->rx.max_mtu = lan966x_fdma_get_max_frame(lan966x);
> > +     rx_fdma->channel_id = FDMA_XTR_CHANNEL;
> > +     rx_fdma->n_dcbs = FDMA_DCB_MAX;
> > +     rx_fdma->n_dbs = FDMA_RX_DCB_MAX_DBS;
> > +     rx_fdma->priv = lan966x;
> > +     rx_fdma->db_size = FDMA_PCI_DB_SIZE(lan966x->rx.max_mtu);
> > +     rx_fdma->size = fdma_get_size_contiguous(rx_fdma);
> > +     rx_fdma->ops.nextptr_cb = &lan966x_fdma_pci_nextptr_cb;
> > +     rx_fdma->ops.dataptr_cb = &lan966x_fdma_pci_dataptr_cb;
> > +
> > +     lan966x->tx.lan966x = lan966x;
> > +     tx_fdma->channel_id = FDMA_INJ_CHANNEL;
> > +     tx_fdma->n_dcbs = FDMA_DCB_MAX;
> > +     tx_fdma->n_dbs = FDMA_TX_DCB_MAX_DBS;
> > +     tx_fdma->priv = lan966x;
> > +     tx_fdma->db_size = FDMA_PCI_DB_SIZE(lan966x->rx.max_mtu);
> > +     tx_fdma->size = fdma_get_size_contiguous(tx_fdma);
> > +     tx_fdma->ops.nextptr_cb = &lan966x_fdma_pci_nextptr_cb;
> > +     tx_fdma->ops.dataptr_cb = &lan966x_fdma_pci_dataptr_cb;
> > +
> > +     err = lan966x_fdma_pci_rx_alloc(&lan966x->rx);
> > +     if (err)
> > +             return err;
> > +
> > +     err = lan966x_fdma_pci_tx_alloc(&lan966x->tx);
> > +     if (err) {
> > +             fdma_free_coherent_and_unmap(lan966x->dma_dev, rx_fdma);
> > +             return err;
> > +     }
> > +
> > +     lan966x_fdma_rx_start(&lan966x->rx);
> > +
> > +     return 0;
> > +}
> > +
> > +static int lan966x_fdma_pci_resize(struct lan966x *lan966x)
> > +{
> > +     return -EOPNOTSUPP;
> > +}
> > +
> > +static void lan966x_fdma_pci_deinit(struct lan966x *lan966x)
> > +{
> > +     if (!lan966x->fdma)
> > +             return;
> > +
> > +     if (lan966x->fdma_ndev)
> > +             napi_disable(&lan966x->napi);
> > +
> > +     lan966x_fdma_tx_disable_netdev(lan966x);
> > +     lan966x_fdma_rx_disable(&lan966x->rx);
> > +     lan966x_fdma_tx_disable(&lan966x->tx);
> > +
> > +     fdma_free_coherent_and_unmap(lan966x->dma_dev, &lan966x->rx.fdma);
> > +     fdma_free_coherent_and_unmap(lan966x->dma_dev, &lan966x->tx.fdma);
> > +}
> > +
> > +const struct lan966x_fdma_ops lan966x_fdma_pci_ops = {
> > +     .fdma_init = &lan966x_fdma_pci_init,
> > +     .fdma_deinit = &lan966x_fdma_pci_deinit,
> > +     .fdma_xmit = &lan966x_fdma_pci_xmit,
> > +     .fdma_poll = &lan966x_fdma_pci_napi_poll,
> > +     .fdma_resize = &lan966x_fdma_pci_resize,
> > +};
> 
> [Severity: Medium]
> Is rx_bytes meant to count the frame as it arrived on the wire?
> 
> By the time this runs, skb->len has already been reduced twice: the
> skb_trim() above drops ETH_FCS_LEN, and eth_type_trans() pulls the
> MAC header out of the linear region, so skb->len is short by at least
> ETH_HLEN. If lan966x_hw_offload() ends up untagging a VLAN header,
> that is another four bytes gone. So every packet delivered through
> lan966x_fdma_pci_rx_get_frame() undercounts rx_bytes by 14 bytes or
> more, which is visible to userspace via ip -s link.
> 
> The frame length is available before any of that surgery happens --
> data_len from FDMA_DCB_STATUS_BLOCKL(db->status), or skb->len right
> after the skb_pull(skb, IFH_LEN_BYTES) -- so accounting could be done
> there instead.
> 
> I realise this mirrors what the existing register/page path in
> lan966x_fdma.c does, so if the intent is to keep the two backends
> byte-for-byte consistent, please say so; otherwise it would be good
> not to copy the miscount into the new file.

Not only lan966x, but sparx5 and lan969x does the exact same thing, increasing
rx_bytes after headers are pulled.  The undercount is real, but not visible to
userspace. Both implementations (platform and PCI) read hardware counters directly

> --
> Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260918-lan966x-pci-fdma-v7-0-0ecc179c8a2c%40microchip.com

Re: [PATCH net-next v7 10/14] net: lan966x: add PCIe FDMA support

[Simon Horman]

On Wed, Sep 23, 2026 at 10:45:38AM +0200, Daniel Machon wrote:

...

> > [Severity: Medium]
> > Is this path expected to work on a big-endian host?
> > 
> > Until now the descriptor producer and the FDMA engine were both on the
> > little-endian SoC, so the native-endian descriptor layout in
> > drivers/net/ethernet/microchip/fdma/fdma_api.h was fine:
> > 
> >   struct fdma_db {
> >         u64 dataptr;
> >         u64 status;
> >   };
> > 
> >   struct fdma_dcb {
> >         u64 nextptr;
> >         u64 info;
> >         struct fdma_db db[FDMA_DB_MAX];
> >   };
> > 
> > With PCIe FDMA the descriptors live in host memory and are fetched by the
> > endpoint, so the host and the engine can disagree on byte order. The
> > translated addresses written here, and the status/info words written by
> > __fdma_db_add()/__fdma_dcb_add(), all go out in host byte order, and the
> > HW-written DONE/BLOCKL fields are read back the same way in
> > lan966x_fdma_pci_get_next_dcb() and lan966x_fdma_pci_rx_check_frame().
> > 
> > CONFIG_MCHP_LAN966X_PCI in drivers/misc/Kconfig only has
> > 
> >   depends on PCI
> >   depends on OF_OVERLAY
> > 
> > so a big-endian host (e.g. powerpc) can select it. On such a host, would
> > the engine see byte-swapped nextptr/dataptr and length fields, i.e. would
> > RX/TX not work at all? Should the descriptor fields become explicit
> > little-endian types with accessors at the hardware boundary, or should the
> > Kconfig entry gain a little-endian dependency?
> 
> Hmm. Never tested on PowerPC, not this driver nor the DT overlay mechanism it
> relies on for PCI deployment, which has only been exercised on ARM and x86 so
> far (AFAICT) [1].
> 
> [1] https://lore.kernel.org/all/20240430183301.46568e35@bootlin.com/

I don't think that the baseline expectation is that drivers are tested
on big-endian systems, but rather that reasonable effort is made to ensure
that byte-order usage is correct.

In this case I suggest that will involve using __le64 instead of u64,
coupled with calling le64_to_cpu() and cpu_to_le64() as appropriate.

Sparse can aid with getting this right.

...

> > [Severity: Medium]
> > Is rx_bytes meant to count the frame as it arrived on the wire?
> > 
> > By the time this runs, skb->len has already been reduced twice: the
> > skb_trim() above drops ETH_FCS_LEN, and eth_type_trans() pulls the
> > MAC header out of the linear region, so skb->len is short by at least
> > ETH_HLEN. If lan966x_hw_offload() ends up untagging a VLAN header,
> > that is another four bytes gone. So every packet delivered through
> > lan966x_fdma_pci_rx_get_frame() undercounts rx_bytes by 14 bytes or
> > more, which is visible to userspace via ip -s link.
> > 
> > The frame length is available before any of that surgery happens --
> > data_len from FDMA_DCB_STATUS_BLOCKL(db->status), or skb->len right
> > after the skb_pull(skb, IFH_LEN_BYTES) -- so accounting could be done
> > there instead.
> > 
> > I realise this mirrors what the existing register/page path in
> > lan966x_fdma.c does, so if the intent is to keep the two backends
> > byte-for-byte consistent, please say so; otherwise it would be good
> > not to copy the miscount into the new file.
> 
> Not only lan966x, but sparx5 and lan969x does the exact same thing, increasing
> rx_bytes after headers are pulled.  The undercount is real, but not visible to
> userspace. Both implementations (platform and PCI) read hardware counters directly

I'm a little unsure, but if it's consistent then I guess that is ok.
It's an old interface anyway.

Re: [PATCH net-next v7 10/14] net: lan966x: add PCIe FDMA support

[Daniel Machon]

> On Wed, Sep 23, 2026 at 10:45:38AM +0200, Daniel Machon wrote:
> 
> ...
> 
> > > [Severity: Medium]
> > > Is this path expected to work on a big-endian host?
> > >
> > > Until now the descriptor producer and the FDMA engine were both on the
> > > little-endian SoC, so the native-endian descriptor layout in
> > > drivers/net/ethernet/microchip/fdma/fdma_api.h was fine:
> > >
> > >   struct fdma_db {
> > >         u64 dataptr;
> > >         u64 status;
> > >   };
> > >
> > >   struct fdma_dcb {
> > >         u64 nextptr;
> > >         u64 info;
> > >         struct fdma_db db[FDMA_DB_MAX];
> > >   };
> > >
> > > With PCIe FDMA the descriptors live in host memory and are fetched by the
> > > endpoint, so the host and the engine can disagree on byte order. The
> > > translated addresses written here, and the status/info words written by
> > > __fdma_db_add()/__fdma_dcb_add(), all go out in host byte order, and the
> > > HW-written DONE/BLOCKL fields are read back the same way in
> > > lan966x_fdma_pci_get_next_dcb() and lan966x_fdma_pci_rx_check_frame().
> > >
> > > CONFIG_MCHP_LAN966X_PCI in drivers/misc/Kconfig only has
> > >
> > >   depends on PCI
> > >   depends on OF_OVERLAY
> > >
> > > so a big-endian host (e.g. powerpc) can select it. On such a host, would
> > > the engine see byte-swapped nextptr/dataptr and length fields, i.e. would
> > > RX/TX not work at all? Should the descriptor fields become explicit
> > > little-endian types with accessors at the hardware boundary, or should the
> > > Kconfig entry gain a little-endian dependency?
> >
> > Hmm. Never tested on PowerPC, not this driver nor the DT overlay mechanism it
> > relies on for PCI deployment, which has only been exercised on ARM and x86 so
> > far (AFAICT) [1].
> >
> > [1] https://lore.kernel.org/all/20240430183301.46568e35@bootlin.com/
> 
> I don't think that the baseline expectation is that drivers are tested
> on big-endian systems, but rather that reasonable effort is made to ensure
> that byte-order usage is correct.
> 
> In this case I suggest that will involve using __le64 instead of u64,
> coupled with calling le64_to_cpu() and cpu_to_le64() as appropriate.
> 
> Sparse can aid with getting this right.

Ack.

I am a little reluctant, when I cant really test it properly. Sashiko gives
another solution - adding a LE dependency to the Kconfig of the misc PCI driver,
maybe that'll do?

> 
> ...
> 
> > > [Severity: Medium]
> > > Is rx_bytes meant to count the frame as it arrived on the wire?
> > >
> > > By the time this runs, skb->len has already been reduced twice: the
> > > skb_trim() above drops ETH_FCS_LEN, and eth_type_trans() pulls the
> > > MAC header out of the linear region, so skb->len is short by at least
> > > ETH_HLEN. If lan966x_hw_offload() ends up untagging a VLAN header,
> > > that is another four bytes gone. So every packet delivered through
> > > lan966x_fdma_pci_rx_get_frame() undercounts rx_bytes by 14 bytes or
> > > more, which is visible to userspace via ip -s link.
> > >
> > > The frame length is available before any of that surgery happens --
> > > data_len from FDMA_DCB_STATUS_BLOCKL(db->status), or skb->len right
> > > after the skb_pull(skb, IFH_LEN_BYTES) -- so accounting could be done
> > > there instead.
> > >
> > > I realise this mirrors what the existing register/page path in
> > > lan966x_fdma.c does, so if the intent is to keep the two backends
> > > byte-for-byte consistent, please say so; otherwise it would be good
> > > not to copy the miscount into the new file.
> >
> > Not only lan966x, but sparx5 and lan969x does the exact same thing, increasing
> > rx_bytes after headers are pulled.  The undercount is real, but not visible to
> > userspace. Both implementations (platform and PCI) read hardware counters directly
> 
> I'm a little unsure, but if it's consistent then I guess that is ok.
> It's an old interface anyway.

[PATCH net-next v7 11/14] net: lan966x: add PCIe FDMA MTU change support

[Daniel Machon]

Add MTU change support for the PCIe FDMA path: on an MTU change, the
contiguous ATU-mapped RX and TX buffers are reallocated at the new
size, falling back to the existing buffers on failure.

Cap the PCIe DCB ring at 256 (FDMA_PCI_DCB_MAX): 512 DCBs would
overflow MAX_PAGE_ORDER at jumbo MTU.

The ring must fit one MAX_PAGE_ORDER block after ATU padding, and
db_size is handed to the FDMA in the 16-bit DCB DATAL field.
Advertise the resulting limit in dev->max_mtu (FDMA_PCI_MAX_MTU)
when the FDMA is in use - a switch with no "fdma" interrupt named
uses the unconstrained register-based path instead, so the cap is
gated on lan966x->fdma, not lan966x_is_pci() alone. On a 4KB-page,
MAX_PAGE_ORDER=10 build this is MTU 15498; the overhead is shared
with lan966x_fdma_get_max_frame() via FDMA_OVERHEAD.

Skip the resize until lan966x_fdma_pci_init() has built the rings;
it runs after the netdevs register and sizes them from
DEV_MAC_MAXLEN_CFG, already programmed by the caller.

Tested-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
---
 .../net/ethernet/microchip/lan966x/lan966x_fdma.c  |   6 +-
 .../ethernet/microchip/lan966x/lan966x_fdma_pci.c  | 153 ++++++++++++++++++++-
 .../net/ethernet/microchip/lan966x/lan966x_main.c  |   3 +-
 .../net/ethernet/microchip/lan966x/lan966x_main.h  |  28 ++++
 4 files changed, 181 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
index 6fb2482eeb17..81103b94e36f 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
@@ -889,11 +889,7 @@ static int lan966x_fdma_reload(struct lan966x *lan966x, int new_mtu)
 
 int lan966x_fdma_get_max_frame(struct lan966x *lan966x)
 {
-	return lan966x_fdma_get_max_mtu(lan966x) +
-	       IFH_LEN_BYTES +
-	       SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) +
-	       VLAN_HLEN * 2 +
-	       XDP_PACKET_HEADROOM;
+	return lan966x_fdma_get_max_mtu(lan966x) + FDMA_OVERHEAD;
 }
 
 static int __lan966x_fdma_reload(struct lan966x *lan966x, int max_mtu)
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
index 5d6902459f20..940425beec2f 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
@@ -358,7 +358,7 @@ static int lan966x_fdma_pci_init(struct lan966x *lan966x)
 	lan966x->rx.lan966x = lan966x;
 	lan966x->rx.max_mtu = lan966x_fdma_get_max_frame(lan966x);
 	rx_fdma->channel_id = FDMA_XTR_CHANNEL;
-	rx_fdma->n_dcbs = FDMA_DCB_MAX;
+	rx_fdma->n_dcbs = FDMA_PCI_DCB_MAX;
 	rx_fdma->n_dbs = FDMA_RX_DCB_MAX_DBS;
 	rx_fdma->priv = lan966x;
 	rx_fdma->db_size = FDMA_PCI_DB_SIZE(lan966x->rx.max_mtu);
@@ -368,7 +368,7 @@ static int lan966x_fdma_pci_init(struct lan966x *lan966x)
 
 	lan966x->tx.lan966x = lan966x;
 	tx_fdma->channel_id = FDMA_INJ_CHANNEL;
-	tx_fdma->n_dcbs = FDMA_DCB_MAX;
+	tx_fdma->n_dcbs = FDMA_PCI_DCB_MAX;
 	tx_fdma->n_dbs = FDMA_TX_DCB_MAX_DBS;
 	tx_fdma->priv = lan966x;
 	tx_fdma->db_size = FDMA_PCI_DB_SIZE(lan966x->rx.max_mtu);
@@ -391,9 +391,156 @@ static int lan966x_fdma_pci_init(struct lan966x *lan966x)
 	return 0;
 }
 
+/* Reset existing rx and tx buffers. */
+static void lan966x_fdma_pci_reset_mem(struct lan966x *lan966x)
+{
+	struct lan966x_rx *rx = &lan966x->rx;
+	struct lan966x_tx *tx = &lan966x->tx;
+
+	memset(rx->fdma.dcbs, 0, rx->fdma.size);
+	memset(tx->fdma.dcbs, 0, tx->fdma.size);
+
+	fdma_dcbs_init(&rx->fdma,
+		       FDMA_DCB_INFO_DATAL(rx->fdma.db_size - XDP_PACKET_HEADROOM),
+		       FDMA_DCB_STATUS_INTR);
+
+	fdma_dcbs_init(&tx->fdma,
+		       FDMA_DCB_INFO_DATAL(tx->fdma.db_size),
+		       FDMA_DCB_STATUS_DONE);
+
+	lan966x_fdma_llp_configure(lan966x,
+				   tx->fdma.atu_region->base_addr,
+				   tx->fdma.channel_id);
+	lan966x_fdma_llp_configure(lan966x,
+				   rx->fdma.atu_region->base_addr,
+				   rx->fdma.channel_id);
+}
+
+/* Wake all TX queues on every port (undoes lan966x_fdma_tx_disable_netdev). */
+static void lan966x_fdma_pci_wakeup_netdev(struct lan966x *lan966x)
+{
+	for (int i = 0; i < lan966x->num_phys_ports; ++i) {
+		struct lan966x_port *port = lan966x->ports[i];
+
+		if (port)
+			netif_tx_wake_all_queues(port->dev);
+	}
+}
+
+static int lan966x_fdma_pci_reload(struct lan966x *lan966x, int new_mtu)
+{
+	struct fdma tx_fdma_old = lan966x->tx.fdma;
+	struct fdma rx_fdma_old = lan966x->rx.fdma;
+	u32 old_mtu = lan966x->rx.max_mtu;
+	int err;
+
+	napi_disable(&lan966x->napi);
+	lan966x_fdma_tx_disable_netdev(lan966x);
+	lan966x_fdma_rx_disable(&lan966x->rx);
+	lan966x_fdma_tx_disable(&lan966x->tx);
+
+	lan966x->rx.max_mtu = new_mtu;
+
+	/* Must be NULL'ed in order to realloc them. */
+	lan966x->rx.fdma.atu_region = NULL;
+	lan966x->tx.fdma.atu_region = NULL;
+
+	lan966x->tx.fdma.db_size = FDMA_PCI_DB_SIZE(lan966x->rx.max_mtu);
+	lan966x->tx.fdma.size = fdma_get_size_contiguous(&lan966x->tx.fdma);
+	lan966x->rx.fdma.db_size = FDMA_PCI_DB_SIZE(lan966x->rx.max_mtu);
+	lan966x->rx.fdma.size = fdma_get_size_contiguous(&lan966x->rx.fdma);
+
+	err = lan966x_fdma_pci_rx_alloc(&lan966x->rx);
+	if (err)
+		goto restore;
+
+	err = lan966x_fdma_pci_tx_alloc(&lan966x->tx);
+	if (err) {
+		fdma_free_coherent_and_unmap(lan966x->dma_dev,
+					     &lan966x->rx.fdma);
+		goto restore;
+	}
+
+	/* Free and unmap old memory. */
+	fdma_free_coherent_and_unmap(lan966x->dma_dev, &rx_fdma_old);
+	fdma_free_coherent_and_unmap(lan966x->dma_dev, &tx_fdma_old);
+
+	/* Order matters: napi_enable() must precede the wakes, or a TX that
+	 * completes first clears FDMA_INTR_DB_ENA with nothing scheduled to
+	 * restore it, leaving RX dead until the next reload.
+	 */
+	napi_enable(&lan966x->napi);
+	lan966x_fdma_rx_start(&lan966x->rx);
+	lan966x_fdma_pci_wakeup_netdev(lan966x);
+
+	return err;
+restore:
+
+	/* No new buffers are allocated at this point. Use the old buffers,
+	 * but reset them before starting the FDMA again.
+	 */
+
+	memcpy(&lan966x->tx.fdma, &tx_fdma_old, sizeof(struct fdma));
+	memcpy(&lan966x->rx.fdma, &rx_fdma_old, sizeof(struct fdma));
+
+	lan966x->rx.max_mtu = old_mtu;
+
+	lan966x_fdma_pci_reset_mem(lan966x);
+
+	napi_enable(&lan966x->napi);
+	lan966x_fdma_rx_start(&lan966x->rx);
+	lan966x_fdma_pci_wakeup_netdev(lan966x);
+
+	return err;
+}
+
+static int __lan966x_fdma_pci_reload(struct lan966x *lan966x, int max_mtu)
+{
+	int err;
+	u32 val;
+
+	/* Disable the CPU port. */
+	lan_rmw(QSYS_SW_PORT_MODE_PORT_ENA_SET(0),
+		QSYS_SW_PORT_MODE_PORT_ENA,
+		lan966x, QSYS_SW_PORT_MODE(CPU_PORT));
+
+	/* Flush the CPU queues. */
+	readx_poll_timeout(lan966x_qsys_sw_status,
+			   lan966x,
+			   val,
+			   !(QSYS_SW_STATUS_EQ_AVAIL_GET(val)),
+			   READL_SLEEP_US, READL_TIMEOUT_US);
+
+	/* Add a sleep in case there are frames between the queues and the CPU
+	 * port
+	 */
+	usleep_range(USEC_PER_MSEC, 2 * USEC_PER_MSEC);
+
+	err = lan966x_fdma_pci_reload(lan966x, max_mtu);
+
+	/* Enable back the CPU port. */
+	lan_rmw(QSYS_SW_PORT_MODE_PORT_ENA_SET(1),
+		QSYS_SW_PORT_MODE_PORT_ENA,
+		lan966x, QSYS_SW_PORT_MODE(CPU_PORT));
+
+	return err;
+}
+
 static int lan966x_fdma_pci_resize(struct lan966x *lan966x)
 {
-	return -EOPNOTSUPP;
+	int max_mtu;
+
+	/* Nothing to resize until fdma_pci_init() has built the rings; it
+	 * sizes them from DEV_MAC_MAXLEN_CFG, which the caller already set.
+	 */
+	if (!lan966x->rx.lan966x)
+		return 0;
+
+	max_mtu = lan966x_fdma_get_max_frame(lan966x);
+	if (max_mtu == lan966x->rx.max_mtu)
+		return 0;
+
+	return __lan966x_fdma_pci_reload(lan966x, max_mtu);
 }
 
 static void lan966x_fdma_pci_deinit(struct lan966x *lan966x)
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
index c803619d83e2..2177e2bbfbd3 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
@@ -823,7 +823,8 @@ static int lan966x_probe_port(struct lan966x *lan966x, u32 p,
 	port->chip_port = p;
 	lan966x->ports[p] = port;
 
-	dev->max_mtu = ETH_MAX_MTU;
+	dev->max_mtu = lan966x_is_pci(lan966x) && lan966x->fdma ?
+		       FDMA_PCI_MAX_MTU : ETH_MAX_MTU;
 
 	dev->netdev_ops = &lan966x_port_netdev_ops;
 	dev->ethtool_ops = &lan966x_ethtool_ops;
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.h b/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
index 16bc28c8f11f..1877f1916d71 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
@@ -7,6 +7,7 @@
 #include <linux/etherdevice.h>
 #include <linux/if_vlan.h>
 #include <linux/jiffies.h>
+#include <linux/mmzone.h>
 #include <linux/phy.h>
 #include <linux/phylink.h>
 #include <linux/ptp_clock_kernel.h>
@@ -87,6 +88,33 @@
 #define FDMA_INJ_CHANNEL		0
 #define FDMA_DCB_MAX			512
 
+/* Ring must fit in one MAX_PAGE_ORDER DMA block; 512 DCBs overflows
+ * at jumbo MTU.
+ */
+#define FDMA_PCI_DCB_MAX		256
+
+#define FDMA_OVERHEAD							\
+	(IFH_LEN_BYTES +						\
+	 SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) +		\
+	 VLAN_HLEN * 2 +						\
+	 XDP_PACKET_HEADROOM)
+
+/* Largest db_size keeping the ATU-padded ring inside one MAX_PAGE_ORDER
+ * block and within the 16-bit DCB DATAL field. Inverts ALIGN(x, R) <= L
+ * into x <= ALIGN_DOWN(L, R) to bound x directly.
+ */
+#define FDMA_PCI_DB_SIZE_MAX						\
+	MIN_T(u32,							\
+	      (ALIGN_DOWN(PAGE_SIZE << MAX_PAGE_ORDER,			\
+			  FDMA_PCI_ATU_REGION_ALIGN) -			\
+	       FDMA_PCI_DCB_MAX * sizeof(struct fdma_dcb)) /		\
+	      (FDMA_PCI_DCB_MAX * FDMA_RX_DCB_MAX_DBS),			\
+	      ALIGN_DOWN(GENMASK(15, 0), FDMA_PCI_DB_ALIGN))
+
+#define FDMA_PCI_MAX_MTU						\
+	(FDMA_PCI_DB_SIZE_MAX - FDMA_OVERHEAD -				\
+	 (ETH_HLEN + ETH_FCS_LEN))
+
 #define SE_IDX_QUEUE			0  /* 0-79 : Queue scheduler elements */
 #define SE_IDX_PORT			80 /* 80-89 : Port schedular elements */
 

-- 
2.34.1

Re: [PATCH net-next v7 11/14] net: lan966x: add PCIe FDMA MTU change support

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 4 potential
issue(s) to consider.

Critical: 0 · High: 2 (2) · Medium: 1 (1) · Low: 1

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [High] MTU change during or after PCIe FDMA teardown runs the full
  reload on freed/quiesced state: unbounded napi_disable() while holding…
- [High] The new resize readiness check publishes lan966x->rx.lan966x
  before the PCI FDMA rings exist, so an MTU change can race with ring…
- [Medium] The new PCIe resize path retires DMA rings and tears down
  their ATU outbound window without ever confirming the hardware is…
- [Low] FDMA_PCI_DB_SIZE_MAX / FDMA_PCI_MAX_MTU perform unsigned
  arithmetic with no underflow guard and no BUILD_BUG_ON, even though…

Pre-existing issues:
- [High] The hazard the new PCIe reload path documents and avoids is
  still live in the sibling platform reload path, which this series…
- [High] The two implementers of lan966x_fdma_ops::fdma_resize now
  disagree about the 'rings not built yet' precondition, and the…
- [Medium] Window in which DEV_MAC_MAXLEN_CFG exceeds the DCB buffer
  size, combined with a missing SOF/EOF check in…

--

net: lan966x: add PCIe FDMA MTU change support

This adds MTU change support to the PCIe FDMA path by reallocating the
contiguous ATU-mapped RX and TX rings at the new size and falling back to
the old buffers on failure.  It also caps the PCIe DCB ring at 256 entries
and advertises a derived dev->max_mtu (FDMA_PCI_MAX_MTU) when the FDMA is
in use.

A few questions below about the new reload path and the new size macros.

> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> index 5d6902459f20..940425beec2f 100644
> --- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> @@ -358,7 +358,7 @@ static int lan966x_fdma_pci_init(struct lan966x *lan966x)
>  	lan966x->rx.lan966x = lan966x;
>  	lan966x->rx.max_mtu = lan966x_fdma_get_max_frame(lan966x);
>  	rx_fdma->channel_id = FDMA_XTR_CHANNEL;
> -	rx_fdma->n_dcbs = FDMA_DCB_MAX;
> +	rx_fdma->n_dcbs = FDMA_PCI_DCB_MAX;
>  	rx_fdma->n_dbs = FDMA_RX_DCB_MAX_DBS;
>  	rx_fdma->priv = lan966x;
>  	rx_fdma->db_size = FDMA_PCI_DB_SIZE(lan966x->rx.max_mtu);

[Severity: High]
Can an MTU change race with ring construction here?  lan966x_fdma_pci_init()
sets rx.lan966x before it fills in channel_id/n_dcbs/n_dbs/db_size/size and
before the two sleeping allocations in lan966x_fdma_pci_rx_alloc() and
lan966x_fdma_pci_tx_alloc().

The netdevs are already live at that point: lan966x_probe() runs the whole
port loop, including lan966x_probe_port()->register_netdev() and
lan966x_port_init()->lan966x_fdma_netdev_init()->netif_napi_add()+
napi_enable(), and only calls ops->fdma_init() afterwards, without holding
RTNL.

So an rtnl-held ndo_change_mtu in that window sees rx.lan966x != NULL, passes
the new guard in lan966x_fdma_pci_resize(), finds a max_mtu that differs from
the partially initialised rx.max_mtu, and enters __lan966x_fdma_pci_reload().
Both contexts then write the same lan966x->rx.fdma / lan966x->tx.fdma:

  lan966x_fdma_pci_reload()
      lan966x_fdma_rx_disable(&lan966x->rx)   /* channel_id still 0 */
      lan966x->rx.fdma.atu_region = NULL;     /* under probe's feet */
      lan966x_fdma_pci_rx_alloc(&lan966x->rx) /* second ring */

Does this leak probe's ring plus its ATU region (only
FDMA_PCI_ATU_REGION_MAX == 6 exist), or trip WARN_ON(fdma->atu_region) /
-ENOSPC in fdma_pci_atu_region_map()?  And on the failure branch,
lan966x_fdma_pci_reset_mem() dereferences tx->fdma.atu_region->base_addr,
which is NULL in a snapshot taken before probe allocated it.

[ ... ]

> @@ -391,9 +391,156 @@ static int lan966x_fdma_pci_init(struct lan966x *lan966x)
>  	return 0;
>  }
>  
> +/* Reset existing rx and tx buffers. */
> +static void lan966x_fdma_pci_reset_mem(struct lan966x *lan966x)
> +{
> +	struct lan966x_rx *rx = &lan966x->rx;
> +	struct lan966x_tx *tx = &lan966x->tx;
> +
> +	memset(rx->fdma.dcbs, 0, rx->fdma.size);
> +	memset(tx->fdma.dcbs, 0, tx->fdma.size);
> +
> +	fdma_dcbs_init(&rx->fdma,
> +		       FDMA_DCB_INFO_DATAL(rx->fdma.db_size - XDP_PACKET_HEADROOM),
> +		       FDMA_DCB_STATUS_INTR);
> +
> +	fdma_dcbs_init(&tx->fdma,
> +		       FDMA_DCB_INFO_DATAL(tx->fdma.db_size),
> +		       FDMA_DCB_STATUS_DONE);
> +
> +	lan966x_fdma_llp_configure(lan966x,
> +				   tx->fdma.atu_region->base_addr,
> +				   tx->fdma.channel_id);
> +	lan966x_fdma_llp_configure(lan966x,
> +				   rx->fdma.atu_region->base_addr,
> +				   rx->fdma.channel_id);
> +}
> +

[ ... ]

> +static int lan966x_fdma_pci_reload(struct lan966x *lan966x, int new_mtu)
> +{
> +	struct fdma tx_fdma_old = lan966x->tx.fdma;
> +	struct fdma rx_fdma_old = lan966x->rx.fdma;
> +	u32 old_mtu = lan966x->rx.max_mtu;
> +	int err;
> +
> +	napi_disable(&lan966x->napi);
> +	lan966x_fdma_tx_disable_netdev(lan966x);
> +	lan966x_fdma_rx_disable(&lan966x->rx);
> +	lan966x_fdma_tx_disable(&lan966x->tx);

[Severity: High]
What happens if an MTU change lands after the PCIe FDMA has already been torn
down?  lan966x_fdma_pci_deinit() disables NAPI and frees both coherent rings,
but it leaves lan966x->rx.lan966x set, lan966x->fdma true and fdma->dcbs
dangling.  It also runs before the netdevs are unregistered and without RTNL:

  lan966x_remove()
      lan966x->ops->fdma_deinit(lan966x);
      lan966x_cleanup_ports(lan966x);   /* unregister_netdev() here */

The new guard in lan966x_fdma_pci_resize() only rejects "rings not built
yet", so an ndo_change_mtu in that window passes it and reaches this
function.  Three things then follow in order:

napi_disable(&lan966x->napi) on an already-disabled NAPI.  Does
napi_disable_locked() spin forever in

	while (val & (NAPIF_STATE_SCHED | NAPIF_STATE_NPSVC))
		usleep_range(20, 200);

since nothing clears those bits until napi_enable()?  That task holds RTNL,
so unregister_netdev() in lan966x_remove() can never complete.

If that is somehow passed, the success path below calls
fdma_free_coherent_and_unmap() on the stale rx_fdma_old/tx_fdma_old
snapshots, so dma_free_coherent(dev, fdma->size, fdma->dcbs, fdma->dma) runs
a second time on the multi-MB blocks deinit already released.

And the restore: path calls lan966x_fdma_pci_reset_mem(), which memsets up to
rx->fdma.size bytes into freed DMA memory and then dereferences
tx->fdma.atu_region->base_addr, which fdma_free_coherent_and_unmap() already
set to NULL.

Would a "rings are live" state check (or clearing rx.lan966x and dcbs in
deinit, or unregistering the netdevs before fdma_deinit) close this?

[Severity: Medium]
Is the hardware guaranteed to be quiesced at this point?  Both
lan966x_fdma_rx_disable() and lan966x_fdma_tx_disable() are void and swallow
the result of

	readx_poll_timeout_atomic(lan966x_fdma_channel_active, lan966x,
				  val, !(val & BIT(fdma->channel_id)),
				  READL_SLEEP_US, READL_TIMEOUT_US);

so a -ETIMEDOUT never reaches this caller, and the EQ_AVAIL drain poll in
__lan966x_fdma_pci_reload() is discarded too (see below).  If either poll
times out, the extraction/injection engine still owns the old DCB ring while
this function reprograms FDMA_DCB_LLP and then calls
fdma_free_coherent_and_unmap(&rx_fdma_old), which does:

  fdma_free_coherent_and_unmap()
      fdma_pci_atu_region_unmap(fdma->atu_region);  /* ENA=0, translation cleared */
      fdma->atu_region = NULL;
      fdma_free_coherent(dev, fdma);                /* pages returned */

On the PCIe path the ATU window is the address translation itself, so
in-flight writes land on a disabled outbound window or into memory already
handed back to the DMA allocator.  Should a timeout abort the resize and
propagate the error so the MTU change is rejected instead?

> +
> +	lan966x->rx.max_mtu = new_mtu;
> +
> +	/* Must be NULL'ed in order to realloc them. */
> +	lan966x->rx.fdma.atu_region = NULL;
> +	lan966x->tx.fdma.atu_region = NULL;
> +
> +	lan966x->tx.fdma.db_size = FDMA_PCI_DB_SIZE(lan966x->rx.max_mtu);
> +	lan966x->tx.fdma.size = fdma_get_size_contiguous(&lan966x->tx.fdma);
> +	lan966x->rx.fdma.db_size = FDMA_PCI_DB_SIZE(lan966x->rx.max_mtu);
> +	lan966x->rx.fdma.size = fdma_get_size_contiguous(&lan966x->rx.fdma);
> +
> +	err = lan966x_fdma_pci_rx_alloc(&lan966x->rx);
> +	if (err)
> +		goto restore;
> +
> +	err = lan966x_fdma_pci_tx_alloc(&lan966x->tx);
> +	if (err) {
> +		fdma_free_coherent_and_unmap(lan966x->dma_dev,
> +					     &lan966x->rx.fdma);
> +		goto restore;
> +	}
> +
> +	/* Free and unmap old memory. */
> +	fdma_free_coherent_and_unmap(lan966x->dma_dev, &rx_fdma_old);
> +	fdma_free_coherent_and_unmap(lan966x->dma_dev, &tx_fdma_old);
> +
> +	/* Order matters: napi_enable() must precede the wakes, or a TX that
> +	 * completes first clears FDMA_INTR_DB_ENA with nothing scheduled to
> +	 * restore it, leaving RX dead until the next reload.
> +	 */
> +	napi_enable(&lan966x->napi);
> +	lan966x_fdma_rx_start(&lan966x->rx);
> +	lan966x_fdma_pci_wakeup_netdev(lan966x);

[Severity: High]
This isn't a bug introduced by this patch, but the hazard this comment
describes looks like it is still live in the sibling register-path reload,
which the series leaves untouched and the commit message does not mention.

lan966x_fdma_reload() uses exactly the order this comment forbids, in both
its success and its restore path:

	lan966x_fdma_rx_start(&lan966x->rx);	/* re-arms RX bit in DB_ENA */
	... page_pool_put_full_page() over 512 DCBs ...
	fdma_free_coherent();
	page_pool_destroy();
	lan966x_fdma_wakeup_netdev(lan966x);
	napi_enable(&lan966x->napi);

The mechanism matches what the comment states.  lan966x_fdma_irq_handler()
does:

	if (db) {
		lan_wr(0, lan966x, FDMA_INTR_DB_ENA);
		lan_wr(db, lan966x, FDMA_INTR_DB);

		napi_schedule(&lan966x->napi);
	}

With NAPI disabled, napi_schedule_prep() returns false and only sets
NAPIF_STATE_MISSED; napi_enable_locked() clears SCHED/NPSVC but does not
re-check MISSED, so no poll runs and the only code that restores DB_ENA
(the lan_wr(0xff, lan966x, FDMA_INTR_DB_ENA) after napi_complete_done()) is
never reached.  Since DB_ENA is now 0, no further DB interrupt can be raised
either.

The TX channel is not disabled during that window, so an in-flight TX
completion or RX DB interrupt there appears to mask all FDMA interrupts
permanently until another MTU change happens to reload.  Should the platform
path get the same ordering fix?

> +
> +	return err;
> +restore:
> +
> +	/* No new buffers are allocated at this point. Use the old buffers,
> +	 * but reset them before starting the FDMA again.
> +	 */
> +
> +	memcpy(&lan966x->tx.fdma, &tx_fdma_old, sizeof(struct fdma));
> +	memcpy(&lan966x->rx.fdma, &rx_fdma_old, sizeof(struct fdma));
> +
> +	lan966x->rx.max_mtu = old_mtu;
> +
> +	lan966x_fdma_pci_reset_mem(lan966x);
> +
> +	napi_enable(&lan966x->napi);
> +	lan966x_fdma_rx_start(&lan966x->rx);
> +	lan966x_fdma_pci_wakeup_netdev(lan966x);
> +
> +	return err;
> +}

[Severity: Medium]
This is a pre-existing ordering issue, but does this patch widen it
noticeably?  lan966x_port_change_mtu() programs the new frame length before
the buffers are grown:

	lan_wr(DEV_MAC_MAXLEN_CFG_MAX_LEN_SET(LAN966X_HW_MTU(new_mtu)),
	       lan966x, DEV_MAC_MAXLEN_CFG(port->chip_port));
	WRITE_ONCE(dev->mtu, new_mtu);

	if (!lan966x->fdma)
		return 0;

	err = lan966x->ops->fdma_resize(lan966x);

and only restores the old value after the callback returns.  On the PCIe path
the callback now does real work: the CPU-queue flush, a
usleep_range(USEC_PER_MSEC, 2 * USEC_PER_MSEC), two multi-megabyte coherent
allocations, and on this restore: path a full RX/TX restart with db_size and
DATAL back at the old smaller value while the larger MAXLEN is still
programmed.

With n_dbs == 1 the FDMA bounds each write by DATAL but continues an
oversized frame in the next DCB, and lan966x_fdma_pci_rx_check_frame() only
validates BLOCKL:

	blockl = FDMA_DCB_STATUS_BLOCKL(db->status);
	if (!lan966x_fdma_pci_rx_size_fits(fdma, blockl))
		return FDMA_ERROR;

It never checks FDMA_DCB_STATUS_SOF/EOF, so a continuation DB is treated as a
complete frame and lan966x_ifh_get_src_port(virt_addr, src_port) parses
payload bytes as the IFH source port.  src_port is range-checked and data_len
is bounded, so this is not an out-of-bounds access, but can a remote sender
that injects an oversized frame in this window get frames delivered to the
stack attributed to a source port of its choosing?

> +
> +static int __lan966x_fdma_pci_reload(struct lan966x *lan966x, int max_mtu)
> +{
> +	int err;
> +	u32 val;
> +
> +	/* Disable the CPU port. */
> +	lan_rmw(QSYS_SW_PORT_MODE_PORT_ENA_SET(0),
> +		QSYS_SW_PORT_MODE_PORT_ENA,
> +		lan966x, QSYS_SW_PORT_MODE(CPU_PORT));
> +
> +	/* Flush the CPU queues. */
> +	readx_poll_timeout(lan966x_qsys_sw_status,
> +			   lan966x,
> +			   val,
> +			   !(QSYS_SW_STATUS_EQ_AVAIL_GET(val)),
> +			   READL_SLEEP_US, READL_TIMEOUT_US);

[Severity: Medium]
The return value of this readx_poll_timeout() is discarded, so "CPU queues
drained" is assumed rather than verified before the rings are retired in
lan966x_fdma_pci_reload().  Should a -ETIMEDOUT here abort the resize?

> +
> +	/* Add a sleep in case there are frames between the queues and the CPU
> +	 * port
> +	 */
> +	usleep_range(USEC_PER_MSEC, 2 * USEC_PER_MSEC);
> +
> +	err = lan966x_fdma_pci_reload(lan966x, max_mtu);
> +
> +	/* Enable back the CPU port. */
> +	lan_rmw(QSYS_SW_PORT_MODE_PORT_ENA_SET(1),
> +		QSYS_SW_PORT_MODE_PORT_ENA,
> +		lan966x, QSYS_SW_PORT_MODE(CPU_PORT));
> +
> +	return err;
> +}
> +
>  static int lan966x_fdma_pci_resize(struct lan966x *lan966x)
>  {
> -	return -EOPNOTSUPP;
> +	int max_mtu;
> +
> +	/* Nothing to resize until fdma_pci_init() has built the rings; it
> +	 * sizes them from DEV_MAC_MAXLEN_CFG, which the caller already set.
> +	 */
> +	if (!lan966x->rx.lan966x)
> +		return 0;

[Severity: High]
This is a pre-existing gap in the other callback rather than something this
patch introduces, but the two implementers of
lan966x_fdma_ops::fdma_resize now disagree about this precondition.  The
platform one has no equivalent check:

lan966x_fdma.c:lan966x_fdma_change_mtu() {
	max_mtu = lan966x_fdma_get_max_frame(lan966x);
	if (max_mtu == lan966x->rx.max_mtu)
		return 0;

	return __lan966x_fdma_reload(lan966x, max_mtu);
}

lan966x_fdma_init() sets rx.lan966x = lan966x only at its own start, so in
the window between register_netdev() in lan966x_probe_port() and
ops->fdma_init() in lan966x_probe(), rx.max_mtu is 0, the comparison always
differs, and the reload runs against an unbuilt ring:

  __lan966x_fdma_reload()->lan966x_fdma_reload()
      lan966x_fdma_rx_disable(&lan966x->rx)
          struct lan966x *lan966x = rx->lan966x;   /* NULL */
          lan_rmw(..., lan966x, FDMA_CH_DISABLE);  /* lan966x->regs */

lan966x->fdma is already true before the port loop and the NAPI instance is
added and enabled by lan966x_port_init()->lan966x_fdma_netdev_init(), so
nothing else stops the path.  Would the guard be better placed once in the
shared caller lan966x_port_change_mtu(), or duplicated in both callbacks?

> +
> +	max_mtu = lan966x_fdma_get_max_frame(lan966x);
> +	if (max_mtu == lan966x->rx.max_mtu)
> +		return 0;
> +
> +	return __lan966x_fdma_pci_reload(lan966x, max_mtu);
>  }
>  
>  static void lan966x_fdma_pci_deinit(struct lan966x *lan966x)
> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
> index c803619d83e2..2177e2bbfbd3 100644
> --- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
> @@ -823,7 +823,8 @@ static int lan966x_probe_port(struct lan966x *lan966x, u32 p,
>  	port->chip_port = p;
>  	lan966x->ports[p] = port;
>  
> -	dev->max_mtu = ETH_MAX_MTU;
> +	dev->max_mtu = lan966x_is_pci(lan966x) && lan966x->fdma ?
> +		       FDMA_PCI_MAX_MTU : ETH_MAX_MTU;
>  
>  	dev->netdev_ops = &lan966x_port_netdev_ops;
>  	dev->ethtool_ops = &lan966x_ethtool_ops;
> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.h b/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
> index 16bc28c8f11f..1877f1916d71 100644
> --- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.h

[ ... ]

> @@ -87,6 +88,33 @@
>  #define FDMA_INJ_CHANNEL		0
>  #define FDMA_DCB_MAX			512
>  
> +/* Ring must fit in one MAX_PAGE_ORDER DMA block; 512 DCBs overflows
> + * at jumbo MTU.
> + */
> +#define FDMA_PCI_DCB_MAX		256
> +
> +#define FDMA_OVERHEAD							\
> +	(IFH_LEN_BYTES +						\
> +	 SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) +		\
> +	 VLAN_HLEN * 2 +						\
> +	 XDP_PACKET_HEADROOM)
> +
> +/* Largest db_size keeping the ATU-padded ring inside one MAX_PAGE_ORDER
> + * block and within the 16-bit DCB DATAL field. Inverts ALIGN(x, R) <= L
> + * into x <= ALIGN_DOWN(L, R) to bound x directly.
> + */
> +#define FDMA_PCI_DB_SIZE_MAX						\
> +	MIN_T(u32,							\
> +	      (ALIGN_DOWN(PAGE_SIZE << MAX_PAGE_ORDER,			\
> +			  FDMA_PCI_ATU_REGION_ALIGN) -			\
> +	       FDMA_PCI_DCB_MAX * sizeof(struct fdma_dcb)) /		\
> +	      (FDMA_PCI_DCB_MAX * FDMA_RX_DCB_MAX_DBS),			\
> +	      ALIGN_DOWN(GENMASK(15, 0), FDMA_PCI_DB_ALIGN))
> +
> +#define FDMA_PCI_MAX_MTU						\
> +	(FDMA_PCI_DB_SIZE_MAX - FDMA_OVERHEAD -				\
> +	 (ETH_HLEN + ETH_FCS_LEN))

[Severity: Low]
Would a BUILD_BUG_ON help here?  Both subtractions are unsigned and
unguarded, and this macro is the only enforcement point for the
MAX_PAGE_ORDER ring-size limit, the 16-bit DATAL limit, and dev->max_mtu.

FDMA_PCI_DCB_MAX * sizeof(struct fdma_dcb) is 256 * 256 = 65536.  If
PAGE_SIZE << MAX_PAGE_ORDER is at or below 128 KB, the first subtraction
wraps and MIN_T(u32, ...) then picks the 65408 branch.  In between, the
second subtraction wraps: with 4 KB pages and MAX_PAGE_ORDER == 5 the
quotient is 256 while FDMA_OVERHEAD + ETH_HLEN + ETH_FCS_LEN is 630, so
FDMA_PCI_MAX_MTU becomes roughly 4G and is assigned straight into
dev->max_mtu, so dev_validate_mtu() accepts anything up to INT_MAX and the
cap this patch installs disappears.

In the other direction, 4 KB pages with MAX_PAGE_ORDER 6 or 7 yield 138 and
1162, i.e. dev->max_mtu below ETH_DATA_LEN, so a plain 1500-byte MTU cannot
be set.  Nothing asserts FDMA_PCI_MAX_MTU >= ETH_DATA_LEN.

The default 4 KB-page, MAX_PAGE_ORDER=10 build does give 16128 and MTU 15498
as the commit message says, and arch/arm/Kconfig declares ARCH_FORCE_MAX_ORDER
as a plain int prompt with no range constraint (it already ships
default "8" if SA1111), so these values are at least legal.

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260918-lan966x-pci-fdma-v7-0-0ecc179c8a2c%40microchip.com

Re: [PATCH net-next v7 11/14] net: lan966x: add PCIe FDMA MTU change support

[Daniel Machon]

> Thank you for your contribution! Sashiko AI review found 4 potential
> issue(s) to consider.
> 
> Critical: 0 · High: 2 (2) · Medium: 1 (1) · Low: 1
> 
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
> 
> - [High] MTU change during or after PCIe FDMA teardown runs the full
>   reload on freed/quiesced state: unbounded napi_disable() while holding…
> - [High] The new resize readiness check publishes lan966x->rx.lan966x
>   before the PCI FDMA rings exist, so an MTU change can race with ring…
> - [Medium] The new PCIe resize path retires DMA rings and tears down
>   their ATU outbound window without ever confirming the hardware is…
> - [Low] FDMA_PCI_DB_SIZE_MAX / FDMA_PCI_MAX_MTU perform unsigned
>   arithmetic with no underflow guard and no BUILD_BUG_ON, even though…
> 
> Pre-existing issues:
> - [High] The hazard the new PCIe reload path documents and avoids is
>   still live in the sibling platform reload path, which this series…
> - [High] The two implementers of lan966x_fdma_ops::fdma_resize now
>   disagree about the 'rings not built yet' precondition, and the…
> - [Medium] Window in which DEV_MAC_MAXLEN_CFG exceeds the DCB buffer
>   size, combined with a missing SOF/EOF check in…
> 
> --
> 
> net: lan966x: add PCIe FDMA MTU change support
> 
> This adds MTU change support to the PCIe FDMA path by reallocating the
> contiguous ATU-mapped RX and TX rings at the new size and falling back to
> the old buffers on failure.  It also caps the PCIe DCB ring at 256 entries
> and advertises a derived dev->max_mtu (FDMA_PCI_MAX_MTU) when the FDMA is
> in use.
> 
> A few questions below about the new reload path and the new size macros.
> 
> > diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> > index 5d6902459f20..940425beec2f 100644
> > --- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> > +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> > @@ -358,7 +358,7 @@ static int lan966x_fdma_pci_init(struct lan966x *lan966x)
> >       lan966x->rx.lan966x = lan966x;
> >       lan966x->rx.max_mtu = lan966x_fdma_get_max_frame(lan966x);
> >       rx_fdma->channel_id = FDMA_XTR_CHANNEL;
> > -     rx_fdma->n_dcbs = FDMA_DCB_MAX;
> > +     rx_fdma->n_dcbs = FDMA_PCI_DCB_MAX;
> >       rx_fdma->n_dbs = FDMA_RX_DCB_MAX_DBS;
> >       rx_fdma->priv = lan966x;
> >       rx_fdma->db_size = FDMA_PCI_DB_SIZE(lan966x->rx.max_mtu);
> 
> [Severity: High]
> Can an MTU change race with ring construction here?  lan966x_fdma_pci_init()
> sets rx.lan966x before it fills in channel_id/n_dcbs/n_dbs/db_size/size and
> before the two sleeping allocations in lan966x_fdma_pci_rx_alloc() and
> lan966x_fdma_pci_tx_alloc().
> 
> The netdevs are already live at that point: lan966x_probe() runs the whole
> port loop, including lan966x_probe_port()->register_netdev() and
> lan966x_port_init()->lan966x_fdma_netdev_init()->netif_napi_add()+
> napi_enable(), and only calls ops->fdma_init() afterwards, without holding
> RTNL.
> 
> So an rtnl-held ndo_change_mtu in that window sees rx.lan966x != NULL, passes
> the new guard in lan966x_fdma_pci_resize(), finds a max_mtu that differs from
> the partially initialised rx.max_mtu, and enters __lan966x_fdma_pci_reload().
> Both contexts then write the same lan966x->rx.fdma / lan966x->tx.fdma:
> 
>   lan966x_fdma_pci_reload()
>       lan966x_fdma_rx_disable(&lan966x->rx)   /* channel_id still 0 */
>       lan966x->rx.fdma.atu_region = NULL;     /* under probe's feet */
>       lan966x_fdma_pci_rx_alloc(&lan966x->rx) /* second ring */
> 
> Does this leak probe's ring plus its ATU region (only
> FDMA_PCI_ATU_REGION_MAX == 6 exist), or trip WARN_ON(fdma->atu_region) /
> -ENOSPC in fdma_pci_atu_region_map()?  And on the failure branch,
> lan966x_fdma_pci_reset_mem() dereferences tx->fdma.atu_region->base_addr,
> which is NULL in a snapshot taken before probe allocated it.

Yes, same issue as adressed in #4. Theres a race because netdevs are registered
before initialization (in this case FDMA) has happened. The proper fix is a
reordering of the probe initialization.

> 
> [ ... ]
> 
> > @@ -391,9 +391,156 @@ static int lan966x_fdma_pci_init(struct lan966x *lan966x)
> >       return 0;
> >  }
> >
> > +/* Reset existing rx and tx buffers. */
> > +static void lan966x_fdma_pci_reset_mem(struct lan966x *lan966x)
> > +{
> > +     struct lan966x_rx *rx = &lan966x->rx;
> > +     struct lan966x_tx *tx = &lan966x->tx;
> > +
> > +     memset(rx->fdma.dcbs, 0, rx->fdma.size);
> > +     memset(tx->fdma.dcbs, 0, tx->fdma.size);
> > +
> > +     fdma_dcbs_init(&rx->fdma,
> > +                    FDMA_DCB_INFO_DATAL(rx->fdma.db_size - XDP_PACKET_HEADROOM),
> > +                    FDMA_DCB_STATUS_INTR);
> > +
> > +     fdma_dcbs_init(&tx->fdma,
> > +                    FDMA_DCB_INFO_DATAL(tx->fdma.db_size),
> > +                    FDMA_DCB_STATUS_DONE);
> > +
> > +     lan966x_fdma_llp_configure(lan966x,
> > +                                tx->fdma.atu_region->base_addr,
> > +                                tx->fdma.channel_id);
> > +     lan966x_fdma_llp_configure(lan966x,
> > +                                rx->fdma.atu_region->base_addr,
> > +                                rx->fdma.channel_id);
> > +}
> > +
> 
> [ ... ]
> 
> > +static int lan966x_fdma_pci_reload(struct lan966x *lan966x, int new_mtu)
> > +{
> > +     struct fdma tx_fdma_old = lan966x->tx.fdma;
> > +     struct fdma rx_fdma_old = lan966x->rx.fdma;
> > +     u32 old_mtu = lan966x->rx.max_mtu;
> > +     int err;
> > +
> > +     napi_disable(&lan966x->napi);
> > +     lan966x_fdma_tx_disable_netdev(lan966x);
> > +     lan966x_fdma_rx_disable(&lan966x->rx);
> > +     lan966x_fdma_tx_disable(&lan966x->tx);
> 
> [Severity: High]
> What happens if an MTU change lands after the PCIe FDMA has already been torn
> down?  lan966x_fdma_pci_deinit() disables NAPI and frees both coherent rings,
> but it leaves lan966x->rx.lan966x set, lan966x->fdma true and fdma->dcbs
> dangling.  It also runs before the netdevs are unregistered and without RTNL:
> 
>   lan966x_remove()
>       lan966x->ops->fdma_deinit(lan966x);
>       lan966x_cleanup_ports(lan966x);   /* unregister_netdev() here */
> 
> The new guard in lan966x_fdma_pci_resize() only rejects "rings not built
> yet", so an ndo_change_mtu in that window passes it and reaches this
> function.  Three things then follow in order:
> 
> napi_disable(&lan966x->napi) on an already-disabled NAPI.  Does
> napi_disable_locked() spin forever in
> 
>         while (val & (NAPIF_STATE_SCHED | NAPIF_STATE_NPSVC))
>                 usleep_range(20, 200);
> 
> since nothing clears those bits until napi_enable()?  That task holds RTNL,
> so unregister_netdev() in lan966x_remove() can never complete.
> 
> If that is somehow passed, the success path below calls
> fdma_free_coherent_and_unmap() on the stale rx_fdma_old/tx_fdma_old
> snapshots, so dma_free_coherent(dev, fdma->size, fdma->dcbs, fdma->dma) runs
> a second time on the multi-MB blocks deinit already released.
> 
> And the restore: path calls lan966x_fdma_pci_reset_mem(), which memsets up to
> rx->fdma.size bytes into freed DMA memory and then dereferences
> tx->fdma.atu_region->base_addr, which fdma_free_coherent_and_unmap() already
> set to NULL.
> 
> Would a "rings are live" state check (or clearing rx.lan966x and dcbs in
> deinit, or unregistering the netdevs before fdma_deinit) close this?

lan966x_remove() is not touched by this series (apart from calling
ops->fdma_deinit), so I'd say pre-existing. But I believe this issue will also
disappear, when we refactor probe init as described above.

> 
> [Severity: Medium]
> Is the hardware guaranteed to be quiesced at this point?  Both
> lan966x_fdma_rx_disable() and lan966x_fdma_tx_disable() are void and swallow
> the result of
> 
>         readx_poll_timeout_atomic(lan966x_fdma_channel_active, lan966x,
>                                   val, !(val & BIT(fdma->channel_id)),
>                                   READL_SLEEP_US, READL_TIMEOUT_US);
> 
> so a -ETIMEDOUT never reaches this caller, and the EQ_AVAIL drain poll in
> __lan966x_fdma_pci_reload() is discarded too (see below).  If either poll
> times out, the extraction/injection engine still owns the old DCB ring while
> this function reprograms FDMA_DCB_LLP and then calls
> fdma_free_coherent_and_unmap(&rx_fdma_old), which does:
> 
>   fdma_free_coherent_and_unmap()
>       fdma_pci_atu_region_unmap(fdma->atu_region);  /* ENA=0, translation cleared */
>       fdma->atu_region = NULL;
>       fdma_free_coherent(dev, fdma);                /* pages returned */
> 
> On the PCIe path the ATU window is the address translation itself, so
> in-flight writes land on a disabled outbound window or into memory already
> handed back to the DMA allocator.  Should a timeout abort the resize and
> propagate the error so the MTU change is rejected instead?

I believe the quiesce poll before teardown is also discarded on lan966x, lan969x
and sparx5 alltogether, same pattern.  READL_TIMEOUT_US is 100 seconds, so a
timeout means the channel was already wedged for a long time.

> 
> > +
> > +     lan966x->rx.max_mtu = new_mtu;
> > +
> > +     /* Must be NULL'ed in order to realloc them. */
> > +     lan966x->rx.fdma.atu_region = NULL;
> > +     lan966x->tx.fdma.atu_region = NULL;
> > +
> > +     lan966x->tx.fdma.db_size = FDMA_PCI_DB_SIZE(lan966x->rx.max_mtu);
> > +     lan966x->tx.fdma.size = fdma_get_size_contiguous(&lan966x->tx.fdma);
> > +     lan966x->rx.fdma.db_size = FDMA_PCI_DB_SIZE(lan966x->rx.max_mtu);
> > +     lan966x->rx.fdma.size = fdma_get_size_contiguous(&lan966x->rx.fdma);
> > +
> > +     err = lan966x_fdma_pci_rx_alloc(&lan966x->rx);
> > +     if (err)
> > +             goto restore;
> > +
> > +     err = lan966x_fdma_pci_tx_alloc(&lan966x->tx);
> > +     if (err) {
> > +             fdma_free_coherent_and_unmap(lan966x->dma_dev,
> > +                                          &lan966x->rx.fdma);
> > +             goto restore;
> > +     }
> > +
> > +     /* Free and unmap old memory. */
> > +     fdma_free_coherent_and_unmap(lan966x->dma_dev, &rx_fdma_old);
> > +     fdma_free_coherent_and_unmap(lan966x->dma_dev, &tx_fdma_old);
> > +
> > +     /* Order matters: napi_enable() must precede the wakes, or a TX that
> > +      * completes first clears FDMA_INTR_DB_ENA with nothing scheduled to
> > +      * restore it, leaving RX dead until the next reload.
> > +      */
> > +     napi_enable(&lan966x->napi);
> > +     lan966x_fdma_rx_start(&lan966x->rx);
> > +     lan966x_fdma_pci_wakeup_netdev(lan966x);
> 
> [Severity: High]
> This isn't a bug introduced by this patch, but the hazard this comment
> describes looks like it is still live in the sibling register-path reload,
> which the series leaves untouched and the commit message does not mention.
> 
> lan966x_fdma_reload() uses exactly the order this comment forbids, in both
> its success and its restore path:
> 
>         lan966x_fdma_rx_start(&lan966x->rx);    /* re-arms RX bit in DB_ENA */
>         ... page_pool_put_full_page() over 512 DCBs ...
>         fdma_free_coherent();
>         page_pool_destroy();
>         lan966x_fdma_wakeup_netdev(lan966x);
>         napi_enable(&lan966x->napi);
> 
> The mechanism matches what the comment states.  lan966x_fdma_irq_handler()
> does:
> 
>         if (db) {
>                 lan_wr(0, lan966x, FDMA_INTR_DB_ENA);
>                 lan_wr(db, lan966x, FDMA_INTR_DB);
> 
>                 napi_schedule(&lan966x->napi);
>         }
> 
> With NAPI disabled, napi_schedule_prep() returns false and only sets
> NAPIF_STATE_MISSED; napi_enable_locked() clears SCHED/NPSVC but does not
> re-check MISSED, so no poll runs and the only code that restores DB_ENA
> (the lan_wr(0xff, lan966x, FDMA_INTR_DB_ENA) after napi_complete_done()) is
> never reached.  Since DB_ENA is now 0, no further DB interrupt can be raised
> either.
> 
> The TX channel is not disabled during that window, so an in-flight TX
> completion or RX DB interrupt there appears to mask all FDMA interrupts
> permanently until another MTU change happens to reload.  Should the platform
> path get the same ordering fix?
> 
> > +
> > +     return err;
> > +restore:
> > +
> > +     /* No new buffers are allocated at this point. Use the old buffers,
> > +      * but reset them before starting the FDMA again.
> > +      */
> > +
> > +     memcpy(&lan966x->tx.fdma, &tx_fdma_old, sizeof(struct fdma));
> > +     memcpy(&lan966x->rx.fdma, &rx_fdma_old, sizeof(struct fdma));
> > +
> > +     lan966x->rx.max_mtu = old_mtu;
> > +
> > +     lan966x_fdma_pci_reset_mem(lan966x);
> > +
> > +     napi_enable(&lan966x->napi);
> > +     lan966x_fdma_rx_start(&lan966x->rx);
> > +     lan966x_fdma_pci_wakeup_netdev(lan966x);
> > +
> > +     return err;
> > +}
> 
> [Severity: Medium]
> This is a pre-existing ordering issue, but does this patch widen it
> noticeably?  lan966x_port_change_mtu() programs the new frame length before
> the buffers are grown:
> 
>         lan_wr(DEV_MAC_MAXLEN_CFG_MAX_LEN_SET(LAN966X_HW_MTU(new_mtu)),
>                lan966x, DEV_MAC_MAXLEN_CFG(port->chip_port));
>         WRITE_ONCE(dev->mtu, new_mtu);
> 
>         if (!lan966x->fdma)
>                 return 0;
> 
>         err = lan966x->ops->fdma_resize(lan966x);
> 
> and only restores the old value after the callback returns.  On the PCIe path
> the callback now does real work: the CPU-queue flush, a
> usleep_range(USEC_PER_MSEC, 2 * USEC_PER_MSEC), two multi-megabyte coherent
> allocations, and on this restore: path a full RX/TX restart with db_size and
> DATAL back at the old smaller value while the larger MAXLEN is still
> programmed.
> 
> With n_dbs == 1 the FDMA bounds each write by DATAL but continues an
> oversized frame in the next DCB, and lan966x_fdma_pci_rx_check_frame() only
> validates BLOCKL:
> 
>         blockl = FDMA_DCB_STATUS_BLOCKL(db->status);
>         if (!lan966x_fdma_pci_rx_size_fits(fdma, blockl))
>                 return FDMA_ERROR;
> 
> It never checks FDMA_DCB_STATUS_SOF/EOF, so a continuation DB is treated as a
> complete frame and lan966x_ifh_get_src_port(virt_addr, src_port) parses
> payload bytes as the IFH source port.  src_port is range-checked and data_len
> is bounded, so this is not an out-of-bounds access, but can a remote sender
> that injects an oversized frame in this window get frames delivered to the
> stack attributed to a source port of its choosing?
> 
> > +
> > +static int __lan966x_fdma_pci_reload(struct lan966x *lan966x, int max_mtu)
> > +{
> > +     int err;
> > +     u32 val;
> > +
> > +     /* Disable the CPU port. */
> > +     lan_rmw(QSYS_SW_PORT_MODE_PORT_ENA_SET(0),
> > +             QSYS_SW_PORT_MODE_PORT_ENA,
> > +             lan966x, QSYS_SW_PORT_MODE(CPU_PORT));
> > +
> > +     /* Flush the CPU queues. */
> > +     readx_poll_timeout(lan966x_qsys_sw_status,
> > +                        lan966x,
> > +                        val,
> > +                        !(QSYS_SW_STATUS_EQ_AVAIL_GET(val)),
> > +                        READL_SLEEP_US, READL_TIMEOUT_US);
> 
> [Severity: Medium]
> The return value of this readx_poll_timeout() is discarded, so "CPU queues
> drained" is assumed rather than verified before the rings are retired in
> lan966x_fdma_pci_reload().  Should a -ETIMEDOUT here abort the resize?
> 
> > +
> > +     /* Add a sleep in case there are frames between the queues and the CPU
> > +      * port
> > +      */
> > +     usleep_range(USEC_PER_MSEC, 2 * USEC_PER_MSEC);
> > +
> > +     err = lan966x_fdma_pci_reload(lan966x, max_mtu);
> > +
> > +     /* Enable back the CPU port. */
> > +     lan_rmw(QSYS_SW_PORT_MODE_PORT_ENA_SET(1),
> > +             QSYS_SW_PORT_MODE_PORT_ENA,
> > +             lan966x, QSYS_SW_PORT_MODE(CPU_PORT));
> > +
> > +     return err;
> > +}
> > +
> >  static int lan966x_fdma_pci_resize(struct lan966x *lan966x)
> >  {
> > -     return -EOPNOTSUPP;
> > +     int max_mtu;
> > +
> > +     /* Nothing to resize until fdma_pci_init() has built the rings; it
> > +      * sizes them from DEV_MAC_MAXLEN_CFG, which the caller already set.
> > +      */
> > +     if (!lan966x->rx.lan966x)
> > +             return 0;
> 
> [Severity: High]
> This is a pre-existing gap in the other callback rather than something this
> patch introduces, but the two implementers of
> lan966x_fdma_ops::fdma_resize now disagree about this precondition.  The
> platform one has no equivalent check:
> 
> lan966x_fdma.c:lan966x_fdma_change_mtu() {
>         max_mtu = lan966x_fdma_get_max_frame(lan966x);
>         if (max_mtu == lan966x->rx.max_mtu)
>                 return 0;
> 
>         return __lan966x_fdma_reload(lan966x, max_mtu);
> }
> 
> lan966x_fdma_init() sets rx.lan966x = lan966x only at its own start, so in
> the window between register_netdev() in lan966x_probe_port() and
> ops->fdma_init() in lan966x_probe(), rx.max_mtu is 0, the comparison always
> differs, and the reload runs against an unbuilt ring:
> 
>   __lan966x_fdma_reload()->lan966x_fdma_reload()
>       lan966x_fdma_rx_disable(&lan966x->rx)
>           struct lan966x *lan966x = rx->lan966x;   /* NULL */
>           lan_rmw(..., lan966x, FDMA_CH_DISABLE);  /* lan966x->regs */
> 
> lan966x->fdma is already true before the port loop and the NAPI instance is
> added and enabled by lan966x_port_init()->lan966x_fdma_netdev_init(), so
> nothing else stops the path.  Would the guard be better placed once in the
> shared caller lan966x_port_change_mtu(), or duplicated in both callbacks?
> 
> > +
> > +     max_mtu = lan966x_fdma_get_max_frame(lan966x);
> > +     if (max_mtu == lan966x->rx.max_mtu)
> > +             return 0;
> > +
> > +     return __lan966x_fdma_pci_reload(lan966x, max_mtu);
> >  }
> >
> >  static void lan966x_fdma_pci_deinit(struct lan966x *lan966x)
> > diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
> > index c803619d83e2..2177e2bbfbd3 100644
> > --- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
> > +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
> > @@ -823,7 +823,8 @@ static int lan966x_probe_port(struct lan966x *lan966x, u32 p,
> >       port->chip_port = p;
> >       lan966x->ports[p] = port;
> >
> > -     dev->max_mtu = ETH_MAX_MTU;
> > +     dev->max_mtu = lan966x_is_pci(lan966x) && lan966x->fdma ?
> > +                    FDMA_PCI_MAX_MTU : ETH_MAX_MTU;
> >
> >       dev->netdev_ops = &lan966x_port_netdev_ops;
> >       dev->ethtool_ops = &lan966x_ethtool_ops;
> > diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.h b/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
> > index 16bc28c8f11f..1877f1916d71 100644
> > --- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
> > +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
> 
> [ ... ]
> 
> > @@ -87,6 +88,33 @@
> >  #define FDMA_INJ_CHANNEL             0
> >  #define FDMA_DCB_MAX                 512
> >
> > +/* Ring must fit in one MAX_PAGE_ORDER DMA block; 512 DCBs overflows
> > + * at jumbo MTU.
> > + */
> > +#define FDMA_PCI_DCB_MAX             256
> > +
> > +#define FDMA_OVERHEAD                                                        \
> > +     (IFH_LEN_BYTES +                                                \
> > +      SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) +               \
> > +      VLAN_HLEN * 2 +                                                \
> > +      XDP_PACKET_HEADROOM)
> > +
> > +/* Largest db_size keeping the ATU-padded ring inside one MAX_PAGE_ORDER
> > + * block and within the 16-bit DCB DATAL field. Inverts ALIGN(x, R) <= L
> > + * into x <= ALIGN_DOWN(L, R) to bound x directly.
> > + */
> > +#define FDMA_PCI_DB_SIZE_MAX                                         \
> > +     MIN_T(u32,                                                      \
> > +           (ALIGN_DOWN(PAGE_SIZE << MAX_PAGE_ORDER,                  \
> > +                       FDMA_PCI_ATU_REGION_ALIGN) -                  \
> > +            FDMA_PCI_DCB_MAX * sizeof(struct fdma_dcb)) /            \
> > +           (FDMA_PCI_DCB_MAX * FDMA_RX_DCB_MAX_DBS),                 \
> > +           ALIGN_DOWN(GENMASK(15, 0), FDMA_PCI_DB_ALIGN))
> > +
> > +#define FDMA_PCI_MAX_MTU                                             \
> > +     (FDMA_PCI_DB_SIZE_MAX - FDMA_OVERHEAD -                         \
> > +      (ETH_HLEN + ETH_FCS_LEN))
> 
> [Severity: Low]
> Would a BUILD_BUG_ON help here?  Both subtractions are unsigned and
> unguarded, and this macro is the only enforcement point for the
> MAX_PAGE_ORDER ring-size limit, the 16-bit DATAL limit, and dev->max_mtu.
> 
> FDMA_PCI_DCB_MAX * sizeof(struct fdma_dcb) is 256 * 256 = 65536.  If
> PAGE_SIZE << MAX_PAGE_ORDER is at or below 128 KB, the first subtraction
> wraps and MIN_T(u32, ...) then picks the 65408 branch.  In between, the
> second subtraction wraps: with 4 KB pages and MAX_PAGE_ORDER == 5 the
> quotient is 256 while FDMA_OVERHEAD + ETH_HLEN + ETH_FCS_LEN is 630, so
> FDMA_PCI_MAX_MTU becomes roughly 4G and is assigned straight into
> dev->max_mtu, so dev_validate_mtu() accepts anything up to INT_MAX and the
> cap this patch installs disappears.
> 
> In the other direction, 4 KB pages with MAX_PAGE_ORDER 6 or 7 yield 138 and
> 1162, i.e. dev->max_mtu below ETH_DATA_LEN, so a plain 1500-byte MTU cannot
> be set.  Nothing asserts FDMA_PCI_MAX_MTU >= ETH_DATA_LEN.
> 
> The default 4 KB-page, MAX_PAGE_ORDER=10 build does give 16128 and MTU 15498
> as the commit message says, and arch/arm/Kconfig declares ARCH_FORCE_MAX_ORDER
> as a plain int prompt with no range constraint (it already ships
> default "8" if SA1111), so these values are at least legal.
> 
> --
> Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260918-lan966x-pci-fdma-v7-0-0ecc179c8a2c%40microchip.com

Re: [PATCH net-next v7 11/14] net: lan966x: add PCIe FDMA MTU change support

[Simon Horman]

On Wed, Sep 23, 2026 at 11:46:22AM +0200, Daniel Machon wrote:
> > Thank you for your contribution! Sashiko AI review found 4 potential
> > issue(s) to consider.
> > 
> > Critical: 0 · High: 2 (2) · Medium: 1 (1) · Low: 1
> > 
> > If you believe none of the issues are legitimate, please reply to each
> > issue of Medium severity or higher and explain why the AI is wrong.
> > If any of them are legitimate and you plan to respin, please let patchwork
> > know by including "pw-bot: cr" as a separate line at the end of your reply
> > (one such reply per series is enough).
> > 
> > - [High] MTU change during or after PCIe FDMA teardown runs the full
> >   reload on freed/quiesced state: unbounded napi_disable() while holding…
> > - [High] The new resize readiness check publishes lan966x->rx.lan966x
> >   before the PCI FDMA rings exist, so an MTU change can race with ring…
> > - [Medium] The new PCIe resize path retires DMA rings and tears down
> >   their ATU outbound window without ever confirming the hardware is…
> > - [Low] FDMA_PCI_DB_SIZE_MAX / FDMA_PCI_MAX_MTU perform unsigned
> >   arithmetic with no underflow guard and no BUILD_BUG_ON, even though…
> > 
> > Pre-existing issues:
> > - [High] The hazard the new PCIe reload path documents and avoids is
> >   still live in the sibling platform reload path, which this series…
> > - [High] The two implementers of lan966x_fdma_ops::fdma_resize now
> >   disagree about the 'rings not built yet' precondition, and the…
> > - [Medium] Window in which DEV_MAC_MAXLEN_CFG exceeds the DCB buffer
> >   size, combined with a missing SOF/EOF check in…
> > 
> > --
> > 
> > net: lan966x: add PCIe FDMA MTU change support
> > 
> > This adds MTU change support to the PCIe FDMA path by reallocating the
> > contiguous ATU-mapped RX and TX rings at the new size and falling back to
> > the old buffers on failure.  It also caps the PCIe DCB ring at 256 entries
> > and advertises a derived dev->max_mtu (FDMA_PCI_MAX_MTU) when the FDMA is
> > in use.
> > 
> > A few questions below about the new reload path and the new size macros.
> > 
> > > diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> > > index 5d6902459f20..940425beec2f 100644
> > > --- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> > > +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> > > @@ -358,7 +358,7 @@ static int lan966x_fdma_pci_init(struct lan966x *lan966x)
> > >       lan966x->rx.lan966x = lan966x;
> > >       lan966x->rx.max_mtu = lan966x_fdma_get_max_frame(lan966x);
> > >       rx_fdma->channel_id = FDMA_XTR_CHANNEL;
> > > -     rx_fdma->n_dcbs = FDMA_DCB_MAX;
> > > +     rx_fdma->n_dcbs = FDMA_PCI_DCB_MAX;
> > >       rx_fdma->n_dbs = FDMA_RX_DCB_MAX_DBS;
> > >       rx_fdma->priv = lan966x;
> > >       rx_fdma->db_size = FDMA_PCI_DB_SIZE(lan966x->rx.max_mtu);
> > 
> > [Severity: High]
> > Can an MTU change race with ring construction here?  lan966x_fdma_pci_init()
> > sets rx.lan966x before it fills in channel_id/n_dcbs/n_dbs/db_size/size and
> > before the two sleeping allocations in lan966x_fdma_pci_rx_alloc() and
> > lan966x_fdma_pci_tx_alloc().
> > 
> > The netdevs are already live at that point: lan966x_probe() runs the whole
> > port loop, including lan966x_probe_port()->register_netdev() and
> > lan966x_port_init()->lan966x_fdma_netdev_init()->netif_napi_add()+
> > napi_enable(), and only calls ops->fdma_init() afterwards, without holding
> > RTNL.
> > 
> > So an rtnl-held ndo_change_mtu in that window sees rx.lan966x != NULL, passes
> > the new guard in lan966x_fdma_pci_resize(), finds a max_mtu that differs from
> > the partially initialised rx.max_mtu, and enters __lan966x_fdma_pci_reload().
> > Both contexts then write the same lan966x->rx.fdma / lan966x->tx.fdma:
> > 
> >   lan966x_fdma_pci_reload()
> >       lan966x_fdma_rx_disable(&lan966x->rx)   /* channel_id still 0 */
> >       lan966x->rx.fdma.atu_region = NULL;     /* under probe's feet */
> >       lan966x_fdma_pci_rx_alloc(&lan966x->rx) /* second ring */
> > 
> > Does this leak probe's ring plus its ATU region (only
> > FDMA_PCI_ATU_REGION_MAX == 6 exist), or trip WARN_ON(fdma->atu_region) /
> > -ENOSPC in fdma_pci_atu_region_map()?  And on the failure branch,
> > lan966x_fdma_pci_reset_mem() dereferences tx->fdma.atu_region->base_addr,
> > which is NULL in a snapshot taken before probe allocated it.
> 
> Yes, same issue as adressed in #4. Theres a race because netdevs are registered
> before initialization (in this case FDMA) has happened. The proper fix is a
> reordering of the probe initialization.

Hi Daniel,

I'm wondering if you could expand on this a little. I'm unsure what #4
refers to. And I'm unclear if you are planing the reordering as part
of this patchset.

> 
> > 
> > [ ... ]
> > 
> > > @@ -391,9 +391,156 @@ static int lan966x_fdma_pci_init(struct lan966x *lan966x)
> > >       return 0;
> > >  }
> > >
> > > +/* Reset existing rx and tx buffers. */
> > > +static void lan966x_fdma_pci_reset_mem(struct lan966x *lan966x)
> > > +{
> > > +     struct lan966x_rx *rx = &lan966x->rx;
> > > +     struct lan966x_tx *tx = &lan966x->tx;
> > > +
> > > +     memset(rx->fdma.dcbs, 0, rx->fdma.size);
> > > +     memset(tx->fdma.dcbs, 0, tx->fdma.size);
> > > +
> > > +     fdma_dcbs_init(&rx->fdma,
> > > +                    FDMA_DCB_INFO_DATAL(rx->fdma.db_size - XDP_PACKET_HEADROOM),
> > > +                    FDMA_DCB_STATUS_INTR);
> > > +
> > > +     fdma_dcbs_init(&tx->fdma,
> > > +                    FDMA_DCB_INFO_DATAL(tx->fdma.db_size),
> > > +                    FDMA_DCB_STATUS_DONE);
> > > +
> > > +     lan966x_fdma_llp_configure(lan966x,
> > > +                                tx->fdma.atu_region->base_addr,
> > > +                                tx->fdma.channel_id);
> > > +     lan966x_fdma_llp_configure(lan966x,
> > > +                                rx->fdma.atu_region->base_addr,
> > > +                                rx->fdma.channel_id);
> > > +}
> > > +
> > 
> > [ ... ]
> > 
> > > +static int lan966x_fdma_pci_reload(struct lan966x *lan966x, int new_mtu)
> > > +{
> > > +     struct fdma tx_fdma_old = lan966x->tx.fdma;
> > > +     struct fdma rx_fdma_old = lan966x->rx.fdma;
> > > +     u32 old_mtu = lan966x->rx.max_mtu;
> > > +     int err;
> > > +
> > > +     napi_disable(&lan966x->napi);
> > > +     lan966x_fdma_tx_disable_netdev(lan966x);
> > > +     lan966x_fdma_rx_disable(&lan966x->rx);
> > > +     lan966x_fdma_tx_disable(&lan966x->tx);
> > 
> > [Severity: High]
> > What happens if an MTU change lands after the PCIe FDMA has already been torn
> > down?  lan966x_fdma_pci_deinit() disables NAPI and frees both coherent rings,
> > but it leaves lan966x->rx.lan966x set, lan966x->fdma true and fdma->dcbs
> > dangling.  It also runs before the netdevs are unregistered and without RTNL:
> > 
> >   lan966x_remove()
> >       lan966x->ops->fdma_deinit(lan966x);
> >       lan966x_cleanup_ports(lan966x);   /* unregister_netdev() here */
> > 
> > The new guard in lan966x_fdma_pci_resize() only rejects "rings not built
> > yet", so an ndo_change_mtu in that window passes it and reaches this
> > function.  Three things then follow in order:
> > 
> > napi_disable(&lan966x->napi) on an already-disabled NAPI.  Does
> > napi_disable_locked() spin forever in
> > 
> >         while (val & (NAPIF_STATE_SCHED | NAPIF_STATE_NPSVC))
> >                 usleep_range(20, 200);
> > 
> > since nothing clears those bits until napi_enable()?  That task holds RTNL,
> > so unregister_netdev() in lan966x_remove() can never complete.
> > 
> > If that is somehow passed, the success path below calls
> > fdma_free_coherent_and_unmap() on the stale rx_fdma_old/tx_fdma_old
> > snapshots, so dma_free_coherent(dev, fdma->size, fdma->dcbs, fdma->dma) runs
> > a second time on the multi-MB blocks deinit already released.
> > 
> > And the restore: path calls lan966x_fdma_pci_reset_mem(), which memsets up to
> > rx->fdma.size bytes into freed DMA memory and then dereferences
> > tx->fdma.atu_region->base_addr, which fdma_free_coherent_and_unmap() already
> > set to NULL.
> > 
> > Would a "rings are live" state check (or clearing rx.lan966x and dcbs in
> > deinit, or unregistering the netdevs before fdma_deinit) close this?
> 
> lan966x_remove() is not touched by this series (apart from calling
> ops->fdma_deinit), so I'd say pre-existing. But I believe this issue will also
> disappear, when we refactor probe init as described above.

...

Re: [PATCH net-next v7 11/14] net: lan966x: add PCIe FDMA MTU change support

[Daniel Machon]

> On Wed, Sep 23, 2026 at 11:46:22AM +0200, Daniel Machon wrote:
> > > Thank you for your contribution! Sashiko AI review found 4 potential
> > > issue(s) to consider.
> > >
> > > Critical: 0 · High: 2 (2) · Medium: 1 (1) · Low: 1
> > >
> > > If you believe none of the issues are legitimate, please reply to each
> > > issue of Medium severity or higher and explain why the AI is wrong.
> > > If any of them are legitimate and you plan to respin, please let patchwork
> > > know by including "pw-bot: cr" as a separate line at the end of your reply
> > > (one such reply per series is enough).
> > >
> > > - [High] MTU change during or after PCIe FDMA teardown runs the full
> > >   reload on freed/quiesced state: unbounded napi_disable() while holding…
> > > - [High] The new resize readiness check publishes lan966x->rx.lan966x
> > >   before the PCI FDMA rings exist, so an MTU change can race with ring…
> > > - [Medium] The new PCIe resize path retires DMA rings and tears down
> > >   their ATU outbound window without ever confirming the hardware is…
> > > - [Low] FDMA_PCI_DB_SIZE_MAX / FDMA_PCI_MAX_MTU perform unsigned
> > >   arithmetic with no underflow guard and no BUILD_BUG_ON, even though…
> > >
> > > Pre-existing issues:
> > > - [High] The hazard the new PCIe reload path documents and avoids is
> > >   still live in the sibling platform reload path, which this series…
> > > - [High] The two implementers of lan966x_fdma_ops::fdma_resize now
> > >   disagree about the 'rings not built yet' precondition, and the…
> > > - [Medium] Window in which DEV_MAC_MAXLEN_CFG exceeds the DCB buffer
> > >   size, combined with a missing SOF/EOF check in…
> > >
> > > --
> > >
> > > net: lan966x: add PCIe FDMA MTU change support
> > >
> > > This adds MTU change support to the PCIe FDMA path by reallocating the
> > > contiguous ATU-mapped RX and TX rings at the new size and falling back to
> > > the old buffers on failure.  It also caps the PCIe DCB ring at 256 entries
> > > and advertises a derived dev->max_mtu (FDMA_PCI_MAX_MTU) when the FDMA is
> > > in use.
> > >
> > > A few questions below about the new reload path and the new size macros.
> > >
> > > > diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> > > > index 5d6902459f20..940425beec2f 100644
> > > > --- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> > > > +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> > > > @@ -358,7 +358,7 @@ static int lan966x_fdma_pci_init(struct lan966x *lan966x)
> > > >       lan966x->rx.lan966x = lan966x;
> > > >       lan966x->rx.max_mtu = lan966x_fdma_get_max_frame(lan966x);
> > > >       rx_fdma->channel_id = FDMA_XTR_CHANNEL;
> > > > -     rx_fdma->n_dcbs = FDMA_DCB_MAX;
> > > > +     rx_fdma->n_dcbs = FDMA_PCI_DCB_MAX;
> > > >       rx_fdma->n_dbs = FDMA_RX_DCB_MAX_DBS;
> > > >       rx_fdma->priv = lan966x;
> > > >       rx_fdma->db_size = FDMA_PCI_DB_SIZE(lan966x->rx.max_mtu);
> > >
> > > [Severity: High]
> > > Can an MTU change race with ring construction here?  lan966x_fdma_pci_init()
> > > sets rx.lan966x before it fills in channel_id/n_dcbs/n_dbs/db_size/size and
> > > before the two sleeping allocations in lan966x_fdma_pci_rx_alloc() and
> > > lan966x_fdma_pci_tx_alloc().
> > >
> > > The netdevs are already live at that point: lan966x_probe() runs the whole
> > > port loop, including lan966x_probe_port()->register_netdev() and
> > > lan966x_port_init()->lan966x_fdma_netdev_init()->netif_napi_add()+
> > > napi_enable(), and only calls ops->fdma_init() afterwards, without holding
> > > RTNL.
> > >
> > > So an rtnl-held ndo_change_mtu in that window sees rx.lan966x != NULL, passes
> > > the new guard in lan966x_fdma_pci_resize(), finds a max_mtu that differs from
> > > the partially initialised rx.max_mtu, and enters __lan966x_fdma_pci_reload().
> > > Both contexts then write the same lan966x->rx.fdma / lan966x->tx.fdma:
> > >
> > >   lan966x_fdma_pci_reload()
> > >       lan966x_fdma_rx_disable(&lan966x->rx)   /* channel_id still 0 */
> > >       lan966x->rx.fdma.atu_region = NULL;     /* under probe's feet */
> > >       lan966x_fdma_pci_rx_alloc(&lan966x->rx) /* second ring */
> > >
> > > Does this leak probe's ring plus its ATU region (only
> > > FDMA_PCI_ATU_REGION_MAX == 6 exist), or trip WARN_ON(fdma->atu_region) /
> > > -ENOSPC in fdma_pci_atu_region_map()?  And on the failure branch,
> > > lan966x_fdma_pci_reset_mem() dereferences tx->fdma.atu_region->base_addr,
> > > which is NULL in a snapshot taken before probe allocated it.
> >
> > Yes, same issue as adressed in #4. Theres a race because netdevs are registered
> > before initialization (in this case FDMA) has happened. The proper fix is a
> > reordering of the probe initialization.
> 
> Hi Daniel,
> 
> I'm wondering if you could expand on this a little. I'm unsure what #4
> refers to. And I'm unclear if you are planing the reordering as part
> of this patchset.

Hi Simon,

Yes, sorry for being vague here.

#4 refers to patch 4, where I explained that the issue reported there was really
due to the existing probe initialization order and netdev registration order.
Sashiko seems to report multiple race issues that can happen since the netdevs
are registered before the HW is fully initialized. This is real, and something
that needs to be fixed, just not in this series, IMHO.

For Sparx5 and lan969x, I fixed this not long ago, and made sure that netdevs
were registered last in probe, as they should be. Now, lan966x should get the
same treatment, as a separate fix series for net. :-)

Thanks for the review!

> 
> >
> > >
> > > [ ... ]
> > >
> > > > @@ -391,9 +391,156 @@ static int lan966x_fdma_pci_init(struct lan966x *lan966x)
> > > >       return 0;
> > > >  }
> > > >
> > > > +/* Reset existing rx and tx buffers. */
> > > > +static void lan966x_fdma_pci_reset_mem(struct lan966x *lan966x)
> > > > +{
> > > > +     struct lan966x_rx *rx = &lan966x->rx;
> > > > +     struct lan966x_tx *tx = &lan966x->tx;
> > > > +
> > > > +     memset(rx->fdma.dcbs, 0, rx->fdma.size);
> > > > +     memset(tx->fdma.dcbs, 0, tx->fdma.size);
> > > > +
> > > > +     fdma_dcbs_init(&rx->fdma,
> > > > +                    FDMA_DCB_INFO_DATAL(rx->fdma.db_size - XDP_PACKET_HEADROOM),
> > > > +                    FDMA_DCB_STATUS_INTR);
> > > > +
> > > > +     fdma_dcbs_init(&tx->fdma,
> > > > +                    FDMA_DCB_INFO_DATAL(tx->fdma.db_size),
> > > > +                    FDMA_DCB_STATUS_DONE);
> > > > +
> > > > +     lan966x_fdma_llp_configure(lan966x,
> > > > +                                tx->fdma.atu_region->base_addr,
> > > > +                                tx->fdma.channel_id);
> > > > +     lan966x_fdma_llp_configure(lan966x,
> > > > +                                rx->fdma.atu_region->base_addr,
> > > > +                                rx->fdma.channel_id);
> > > > +}
> > > > +
> > >
> > > [ ... ]
> > >
> > > > +static int lan966x_fdma_pci_reload(struct lan966x *lan966x, int new_mtu)
> > > > +{
> > > > +     struct fdma tx_fdma_old = lan966x->tx.fdma;
> > > > +     struct fdma rx_fdma_old = lan966x->rx.fdma;
> > > > +     u32 old_mtu = lan966x->rx.max_mtu;
> > > > +     int err;
> > > > +
> > > > +     napi_disable(&lan966x->napi);
> > > > +     lan966x_fdma_tx_disable_netdev(lan966x);
> > > > +     lan966x_fdma_rx_disable(&lan966x->rx);
> > > > +     lan966x_fdma_tx_disable(&lan966x->tx);
> > >
> > > [Severity: High]
> > > What happens if an MTU change lands after the PCIe FDMA has already been torn
> > > down?  lan966x_fdma_pci_deinit() disables NAPI and frees both coherent rings,
> > > but it leaves lan966x->rx.lan966x set, lan966x->fdma true and fdma->dcbs
> > > dangling.  It also runs before the netdevs are unregistered and without RTNL:
> > >
> > >   lan966x_remove()
> > >       lan966x->ops->fdma_deinit(lan966x);
> > >       lan966x_cleanup_ports(lan966x);   /* unregister_netdev() here */
> > >
> > > The new guard in lan966x_fdma_pci_resize() only rejects "rings not built
> > > yet", so an ndo_change_mtu in that window passes it and reaches this
> > > function.  Three things then follow in order:
> > >
> > > napi_disable(&lan966x->napi) on an already-disabled NAPI.  Does
> > > napi_disable_locked() spin forever in
> > >
> > >         while (val & (NAPIF_STATE_SCHED | NAPIF_STATE_NPSVC))
> > >                 usleep_range(20, 200);
> > >
> > > since nothing clears those bits until napi_enable()?  That task holds RTNL,
> > > so unregister_netdev() in lan966x_remove() can never complete.
> > >
> > > If that is somehow passed, the success path below calls
> > > fdma_free_coherent_and_unmap() on the stale rx_fdma_old/tx_fdma_old
> > > snapshots, so dma_free_coherent(dev, fdma->size, fdma->dcbs, fdma->dma) runs
> > > a second time on the multi-MB blocks deinit already released.
> > >
> > > And the restore: path calls lan966x_fdma_pci_reset_mem(), which memsets up to
> > > rx->fdma.size bytes into freed DMA memory and then dereferences
> > > tx->fdma.atu_region->base_addr, which fdma_free_coherent_and_unmap() already
> > > set to NULL.
> > >
> > > Would a "rings are live" state check (or clearing rx.lan966x and dcbs in
> > > deinit, or unregistering the netdevs before fdma_deinit) close this?
> >
> > lan966x_remove() is not touched by this series (apart from calling
> > ops->fdma_deinit), so I'd say pre-existing. But I believe this issue will also
> > disappear, when we refactor probe init as described above.
> 
> ...

[PATCH net-next v7 12/14] net: lan966x: add PCIe FDMA XDP support

[Daniel Machon]

Add XDP support for the PCIe FDMA path. The implementation operates on
contiguous ATU-mapped buffers with memcpy-based XDP_TX, unlike the
platform path which uses page_pool.

XDP sees the frame with IFH and FCS stripped. These are removed in
lan966x_fdma_pci_rx_check_frame() before the BPF program runs, because
after the program returns the driver cannot tell whether the tail
region was modified. The skb_pull/skb_trim previously done in
lan966x_fdma_pci_rx_get_frame() are removed for the same reason; the
frame pointer and length are pre-computed by rx_check_frame() and
passed through rx_get_frame() and lan966x_xdp_pci_run() to the caller.

lan966x_fdma_pci_xmit_xdpf() handles XDP_TX: it rebuilds a fresh IFH
in the TX slot, copies the post-XDP frame after it, and lets HW insert
a new FCS.

lan966x_xdp_setup() is extended so the PCIe path skips the page_pool
reload that the platform path needs.

Only XDP_ACT_BASIC is supported.

Tested-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
---
 .../ethernet/microchip/lan966x/lan966x_fdma_pci.c  | 167 ++++++++++++++++++---
 .../net/ethernet/microchip/lan966x/lan966x_main.c  |  12 +-
 .../net/ethernet/microchip/lan966x/lan966x_xdp.c   |  12 +-
 3 files changed, 160 insertions(+), 31 deletions(-)

diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
index 940425beec2f..e833dbb4fcf0 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
@@ -1,5 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 
+#include <linux/bpf_trace.h>
+
 #include "fdma_api.h"
 #include "lan966x_main.h"
 
@@ -136,7 +138,123 @@ static bool lan966x_fdma_pci_rx_size_fits(struct fdma *fdma, u32 blockl)
 	       blockl <= fdma->db_size - XDP_PACKET_HEADROOM;
 }
 
-static int lan966x_fdma_pci_rx_check_frame(struct lan966x_rx *rx, u64 *src_port)
+static int lan966x_fdma_pci_xmit_xdpf(struct lan966x_port *port,
+				      void *ptr, u32 len)
+{
+	struct lan966x *lan966x = port->lan966x;
+	struct lan966x_tx *tx = &lan966x->tx;
+	struct fdma *fdma = &tx->fdma;
+	int next_to_use, ret = 0;
+	void *virt_addr;
+
+	spin_lock(&lan966x->tx_lock);
+
+	next_to_use = lan966x_fdma_pci_get_next_dcb(fdma);
+
+	if (next_to_use < 0) {
+		netif_stop_queue(port->dev);
+		port->dev->stats.tx_dropped++;
+		ret = NETDEV_TX_BUSY;
+		goto out;
+	}
+
+	/* Only the upper bound is enforced: XDP owns the frame contents and
+	 * length, so a program that shrinks below ETH_ZLEN gets what it asked
+	 * for.
+	 */
+	if (!lan966x_fdma_pci_tx_size_fits(fdma, len)) {
+		port->dev->stats.tx_dropped++;
+		ret = -EINVAL;
+		goto out;
+	}
+
+	/* virt_addr points to the IFH. */
+	virt_addr = fdma_dataptr_virt_addr_contiguous(fdma, next_to_use, 0);
+
+	/* Construct a fresh IFH. */
+	memset(virt_addr, 0, IFH_LEN_BYTES);
+	lan966x_ifh_set_bypass(virt_addr, 1);
+	lan966x_ifh_set_port(virt_addr, BIT_ULL(port->chip_port));
+
+	/* Copy the (post-XDP) frame after the IFH. */
+	memcpy(virt_addr + IFH_LEN_BYTES, ptr, len);
+
+	/* Order frame write before DCB status write below. */
+	dma_wmb();
+
+	/* Reserve ETH_FCS_LEN for the HW-inserted FCS (len is FCS-stripped). */
+	fdma_dcb_add(fdma,
+		     next_to_use,
+		     0,
+		     FDMA_DCB_STATUS_INTR |
+		     FDMA_DCB_STATUS_SOF |
+		     FDMA_DCB_STATUS_EOF |
+		     FDMA_DCB_STATUS_BLOCKO(0) |
+		     FDMA_DCB_STATUS_BLOCKL(IFH_LEN_BYTES + len + ETH_FCS_LEN));
+
+	/* Start the transmission. */
+	lan966x_fdma_tx_start(tx);
+
+	port->dev->stats.tx_bytes += len;
+	port->dev->stats.tx_packets++;
+
+out:
+	spin_unlock(&lan966x->tx_lock);
+
+	return ret;
+}
+
+static int lan966x_xdp_pci_run(struct lan966x_port *port, void *data,
+			       u32 data_len, void **xdp_data, u32 *xdp_len)
+{
+	/* Read once so the NULL check and bpf_prog_run_xdp() see the same
+	 * pointer.
+	 */
+	struct bpf_prog *xdp_prog = READ_ONCE(port->xdp_prog);
+	struct lan966x *lan966x = port->lan966x;
+	struct fdma *fdma = &lan966x->rx.fdma;
+	struct xdp_buff xdp;
+	u32 act;
+
+	if (!xdp_prog)
+		return FDMA_PASS;
+
+	xdp_init_buff(&xdp, fdma->db_size, &port->xdp_rxq);
+
+	/* hard_start is set to slot start (virt_addr is XDP_PACKET_HEADROOM
+	 * into the slot). Headroom includes the IFH; BPF may grow into it
+	 * via adjust_head. IFH is rebuilt on XDP_TX and unread on XDP_PASS.
+	 */
+	xdp_prepare_buff(&xdp,
+			 data - XDP_PACKET_HEADROOM,
+			 XDP_PACKET_HEADROOM + IFH_LEN_BYTES,
+			 data_len,
+			 false);
+
+	act = bpf_prog_run_xdp(xdp_prog, &xdp);
+
+	*xdp_data = xdp.data;
+	*xdp_len = xdp.data_end - xdp.data;
+
+	switch (act) {
+	case XDP_PASS:
+		return FDMA_PASS;
+	case XDP_TX:
+		return lan966x_fdma_pci_xmit_xdpf(port, *xdp_data, *xdp_len) ?
+		       FDMA_DROP : FDMA_TX;
+	default:
+		bpf_warn_invalid_xdp_action(port->dev, xdp_prog, act);
+		fallthrough;
+	case XDP_ABORTED:
+		trace_xdp_exception(port->dev, xdp_prog, act);
+		fallthrough;
+	case XDP_DROP:
+		return FDMA_DROP;
+	}
+}
+
+static int lan966x_fdma_pci_rx_check_frame(struct lan966x_rx *rx, u64 *src_port,
+					   void **data, u32 *data_len)
 {
 	struct lan966x *lan966x = rx->lan966x;
 	struct fdma *fdma = &rx->fdma;
@@ -168,38 +286,33 @@ static int lan966x_fdma_pci_rx_check_frame(struct lan966x_rx *rx, u64 *src_port)
 	if (!lan966x_fdma_pci_rx_size_fits(fdma, blockl))
 		return FDMA_ERROR;
 
-	return FDMA_PASS;
+	/* Present the Ethernet frame (no IFH, no FCS). HW re-inserts the
+	 * FCS on TX; see lan966x_fdma_pci_xmit_xdpf(). May be overridden
+	 * by XDP. The FCS strip is unconditional because NETIF_F_RXFCS
+	 * is not advertised in hw_features.
+	 */
+	*data = virt_addr + IFH_LEN_BYTES;
+	*data_len = blockl - IFH_LEN_BYTES - ETH_FCS_LEN;
+
+	return lan966x_xdp_pci_run(port, virt_addr, *data_len, data, data_len);
 }
 
 static struct sk_buff *lan966x_fdma_pci_rx_get_frame(struct lan966x_rx *rx,
-						     u64 src_port)
+						     u64 src_port, void *data,
+						     u32 data_len)
 {
 	struct lan966x *lan966x = rx->lan966x;
-	struct fdma *fdma = &rx->fdma;
 	struct sk_buff *skb;
-	struct fdma_db *db;
-	u32 data_len;
-
-	/* Get the received frame and create an SKB for it. */
-	db = fdma_db_next_get(fdma);
-	data_len = FDMA_DCB_STATUS_BLOCKL(db->status);
 
 	skb = napi_alloc_skb(&lan966x->napi, data_len);
 	if (unlikely(!skb))
 		return NULL;
 
-	memcpy(skb->data,
-	       fdma_dataptr_virt_addr_contiguous(fdma,
-						 fdma->dcb_index,
-						 fdma->db_index),
-						 data_len);
+	memcpy(skb->data, data, data_len);
 
 	skb_put(skb, data_len);
 
 	skb->dev = lan966x->ports[src_port]->dev;
-	skb_pull(skb, IFH_LEN_BYTES);
-
-	skb_trim(skb, skb->len - ETH_FCS_LEN);
 
 	skb->protocol = eth_type_trans(skb, skb->dev);
 
@@ -287,6 +400,8 @@ static int lan966x_fdma_pci_napi_poll(struct napi_struct *napi, int weight)
 	struct sk_buff *skb;
 	int counter = 0;
 	u64 src_port;
+	u32 data_len;
+	void *data;
 
 	/* Wake any stopped TX queues if a TX DCB is available. */
 	spin_lock(&lan966x->tx_lock);
@@ -303,7 +418,10 @@ static int lan966x_fdma_pci_napi_poll(struct napi_struct *napi, int weight)
 		/* Order DONE read before DCB/frame reads below. */
 		dma_rmb();
 		counter++;
-		switch (lan966x_fdma_pci_rx_check_frame(rx, &src_port)) {
+		switch (lan966x_fdma_pci_rx_check_frame(rx,
+							&src_port,
+							&data,
+							&data_len)) {
 		case FDMA_PASS:
 			break;
 		case FDMA_ERROR:
@@ -312,8 +430,17 @@ static int lan966x_fdma_pci_napi_poll(struct napi_struct *napi, int weight)
 			 */
 			fdma_dcb_advance(fdma);
 			continue;
+		case FDMA_TX:
+			fdma_dcb_advance(fdma);
+			continue;
+		case FDMA_DROP:
+			fdma_dcb_advance(fdma);
+			continue;
 		}
-		skb = lan966x_fdma_pci_rx_get_frame(rx, src_port);
+		skb = lan966x_fdma_pci_rx_get_frame(rx,
+						    src_port,
+						    data,
+						    data_len);
 		fdma_dcb_advance(fdma);
 		if (!skb) {
 			lan966x->ports[src_port]->dev->stats.rx_dropped++;
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
index 2177e2bbfbd3..7812d495f753 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
@@ -875,11 +875,13 @@ static int lan966x_probe_port(struct lan966x *lan966x, u32 p,
 
 	port->phylink = phylink;
 
-	/* XDP is not supported on the PCIe FDMA path. */
-	if (lan966x->fdma && !lan966x_is_pci(lan966x))
-		dev->xdp_features = NETDEV_XDP_ACT_BASIC |
-				    NETDEV_XDP_ACT_REDIRECT |
-				    NETDEV_XDP_ACT_NDO_XMIT;
+	if (lan966x->fdma) {
+		dev->xdp_features = NETDEV_XDP_ACT_BASIC;
+
+		if (!lan966x_is_pci(lan966x))
+			dev->xdp_features |= NETDEV_XDP_ACT_REDIRECT |
+					     NETDEV_XDP_ACT_NDO_XMIT;
+	}
 
 	err = register_netdev(dev);
 	if (err) {
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_xdp.c b/drivers/net/ethernet/microchip/lan966x/lan966x_xdp.c
index e63634887f64..b98426afc785 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_xdp.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_xdp.c
@@ -20,16 +20,16 @@ static int lan966x_xdp_setup(struct net_device *dev, struct netdev_bpf *xdp)
 		return -EOPNOTSUPP;
 	}
 
-	if (lan966x_is_pci(lan966x)) {
-		NL_SET_ERR_MSG_MOD(xdp->extack,
-				   "XDP is not supported on the PCIe FDMA path");
-		return -EOPNOTSUPP;
-	}
-
 	old_xdp = lan966x_xdp_present(lan966x);
 	old_prog = xchg(&port->xdp_prog, xdp->prog);
 	new_xdp = lan966x_xdp_present(lan966x);
 
+	/* PCIe FDMA uses contiguous buffers, so no page_pool reload
+	 * is needed.
+	 */
+	if (lan966x_is_pci(lan966x))
+		goto out;
+
 	if (old_xdp == new_xdp)
 		goto out;
 

-- 
2.34.1

Re: [PATCH net-next v7 12/14] net: lan966x: add PCIe FDMA XDP support

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 3 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 3 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] The same lan966x driver now presents two different XDP frame
  views depending on the FDMA back-end.
- [Medium] lan966x_xdp_pci_run()
  (drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c) has no…
- [Medium] lan966x_fdma_pci_napi_poll() bounds its RX loop only by the
  caller-supplied weight, and clears the DONE bits solely in the…

--

net: lan966x: add PCIe FDMA XDP support

This adds XDP support to the lan966x PCIe FDMA path, running the BPF
program on the contiguous ATU-mapped RX buffer and implementing XDP_TX by
rebuilding the IFH and memcpy'ing the post-XDP frame into a TX slot. The
IFH and FCS are now stripped in lan966x_fdma_pci_rx_check_frame() before
the program runs, and lan966x_xdp_setup() no longer rejects programs on
the PCIe path.

A few questions below.

> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> index 940425beec2f..e833dbb4fcf0 100644
> --- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c

[ ... ]

> +static int lan966x_xdp_pci_run(struct lan966x_port *port, void *data,
> +			       u32 data_len, void **xdp_data, u32 *xdp_len)
> +{

[ ... ]

> +	act = bpf_prog_run_xdp(xdp_prog, &xdp);
> +
> +	*xdp_data = xdp.data;
> +	*xdp_len = xdp.data_end - xdp.data;
> +
> +	switch (act) {
> +	case XDP_PASS:
> +		return FDMA_PASS;
> +	case XDP_TX:
> +		return lan966x_fdma_pci_xmit_xdpf(port, *xdp_data, *xdp_len) ?
> +		       FDMA_DROP : FDMA_TX;
> +	default:
> +		bpf_warn_invalid_xdp_action(port->dev, xdp_prog, act);

[Severity: Medium]
Should this switch have an XDP_REDIRECT arm, at least for the bonding
case?  XDP_TX can be rewritten into XDP_REDIRECT inside
bpf_prog_run_xdp() before the driver sees the action:

include/net/xdp.h:bpf_prog_run_xdp() {
	u32 act = __bpf_prog_run(prog, xdp, BPF_DISPATCHER_FUNC(xdp));

	if (static_branch_unlikely(&bpf_master_redirect_enabled_key)) {
		if (act == XDP_TX && netif_is_bond_slave(xdp->rxq->dev))
			act = xdp_master_redirect(xdp);
	}
	...
}

bond_xdp_set() increments bpf_master_redirect_enabled_key and only
requires the slave to provide ndo_bpf and ndo_xdp_xmit, both of which
lan966x_port_netdev_ops provides on the PCIe path as well.  Before this
patch lan966x_xdp_setup() rejected any program on the PCIe path, so this
combination was not reachable; now it is.

With no XDP_REDIRECT case, a program returning XDP_TX on a bonded PCIe
port lands in the default arm, so the frame is dropped,
bpf_warn_invalid_xdp_action() prints "Driver unsupported XDP return value
4", trace_xdp_exception() fires, and the per-CPU redirect info stashed by
xdp_master_redirect() is never consumed - while lan966x_probe_port() now
advertises NETDEV_XDP_ACT_BASIC (XDP_TX) for exactly this path.

The other implementer of the same lan966x_fdma_action values,
lan966x_xdp_run() in lan966x_xdp.c, does handle XDP_REDIRECT, so the two
sides of the shared enum disagree.

> +		fallthrough;
> +	case XDP_ABORTED:
> +		trace_xdp_exception(port->dev, xdp_prog, act);
> +		fallthrough;
> +	case XDP_DROP:
> +		return FDMA_DROP;
> +	}
> +}
> +
> +static int lan966x_fdma_pci_rx_check_frame(struct lan966x_rx *rx, u64 *src_port,
> +					   void **data, u32 *data_len)
>  {
>  	struct lan966x *lan966x = rx->lan966x;
>  	struct fdma *fdma = &rx->fdma;
> @@ -168,38 +286,33 @@ static int lan966x_fdma_pci_rx_check_frame(struct lan966x_rx *rx, u64 *src_port)
>  	if (!lan966x_fdma_pci_rx_size_fits(fdma, blockl))
>  		return FDMA_ERROR;
>  
> -	return FDMA_PASS;
> +	/* Present the Ethernet frame (no IFH, no FCS). HW re-inserts the
> +	 * FCS on TX; see lan966x_fdma_pci_xmit_xdpf(). May be overridden
> +	 * by XDP. The FCS strip is unconditional because NETIF_F_RXFCS
> +	 * is not advertised in hw_features.
> +	 */
> +	*data = virt_addr + IFH_LEN_BYTES;
> +	*data_len = blockl - IFH_LEN_BYTES - ETH_FCS_LEN;
> +
> +	return lan966x_xdp_pci_run(port, virt_addr, *data_len, data, data_len);
>  }

[Severity: Medium]
The commit message states:

    XDP sees the frame with IFH and FCS stripped.

Is that only true for the PCIe back-end?  The platform back-end of the
same driver hands the FCS to the program:

drivers/net/ethernet/microchip/lan966x/lan966x_xdp.c:lan966x_xdp_run() {
	...
	xdp_prepare_buff(&xdp, page_address(page),
			 IFH_LEN_BYTES + XDP_PACKET_HEADROOM,
			 data_len - IFH_LEN_BYTES, false);
	...
}

and the trailing 4 bytes are only removed afterwards, once the program has
already run:

drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c:lan966x_fdma_rx_get_frame() {
	...
	if (likely(!(skb->dev->features & NETIF_F_RXFCS)))
		skb_trim(skb, skb->len - ETH_FCS_LEN);
	...
}

So one XDP program keyed on xdp->data_end - xdp->data, or doing an IP
total-length cross-check or tail parsing, sees 4 extra bytes on a platform
lan966x and not on a PCIe lan966x, and for XDP_TX the platform path
re-sends the stale FCS as payload while the PCIe path strips it and lets
HW insert a fresh one.

Could either the platform path be harmonized in this series, or the commit
message say that the divergence is known and intentional?

[ ... ]

> @@ -287,6 +400,8 @@ static int lan966x_fdma_pci_napi_poll(struct napi_struct *napi, int weight)
>  	struct sk_buff *skb;
>  	int counter = 0;
>  	u64 src_port;
> +	u32 data_len;
> +	void *data;
>  
>  	/* Wake any stopped TX queues if a TX DCB is available. */
>  	spin_lock(&lan966x->tx_lock);
> @@ -303,7 +418,10 @@ static int lan966x_fdma_pci_napi_poll(struct napi_struct *napi, int weight)
>  		/* Order DONE read before DCB/frame reads below. */
>  		dma_rmb();
>  		counter++;
> -		switch (lan966x_fdma_pci_rx_check_frame(rx, &src_port)) {
> +		switch (lan966x_fdma_pci_rx_check_frame(rx,
> +							&src_port,
> +							&data,
> +							&data_len)) {
>  		case FDMA_PASS:
>  			break;
>  		case FDMA_ERROR:
> @@ -312,8 +430,17 @@ static int lan966x_fdma_pci_napi_poll(struct napi_struct *napi, int weight)
>  			 */
>  			fdma_dcb_advance(fdma);
>  			continue;
> +		case FDMA_TX:
> +			fdma_dcb_advance(fdma);
> +			continue;
> +		case FDMA_DROP:
> +			fdma_dcb_advance(fdma);
> +			continue;
>  		}

[Severity: Medium]
Can the same descriptors be processed twice when the RX loop consumes the
whole ring in one poll?

The RX loop is bounded only by the caller-supplied weight, and the DONE
bits are cleared solely by the fdma_dcb_add() in the replenish loop, whose
trip count comes from a wrapped index comparison:

lan966x_fdma_pci_napi_poll() {
	dcb_reload = fdma->dcb_index;

	while (counter < weight) {
		if (!fdma_has_frames(fdma))
			break;
		...
	}
	while (dcb_reload != fdma->dcb_index) {
		old_dcb = dcb_reload;
		dcb_reload++;
		dcb_reload &= fdma->n_dcbs - 1;

		fdma_dcb_add(fdma, old_dcb, ...);
		lan966x_fdma_rx_reload(rx);
	}
	...
}

The PCIe ring has FDMA_PCI_DCB_MAX = 256 descriptors.  With all 256 DONE
and weight >= 256, fdma_dcb_advance() wraps fdma->dcb_index back to
dcb_reload, so the replenish loop runs zero iterations: nothing is
re-armed and no DONE bit is cleared.  counter == weight also suppresses
napi_complete_done(), so the next poll re-processes the same 256
descriptors - duplicate skbs via napi_gro_receive(), and with this patch
the same frames are re-run through the BPF program and re-transmitted by
lan966x_fdma_pci_xmit_xdpf() on XDP_TX.

A weight >= 256 is reachable through busy polling: SO_BUSY_POLL_BUDGET
accepts up to U16_MAX (CAP_NET_ADMIN needed to raise it) and
__napi_busy_loop() passes that budget straight into napi->poll():

net/core/dev.c:__napi_busy_loop() {
	...
	work = napi_poll(napi, budget);
	...
}

The loop shape itself came in with "net: lan966x: add PCIe FDMA support"
earlier in this series, and the platform twin lan966x_fdma_napi_poll() has
the same shape with 512 DCBs; this patch extends the switch with
FDMA_TX/FDMA_DROP, which adds the repeated XDP execution and repeated
transmit to the effects.  Would counting consumed descriptors and capping
the loop at fdma->n_dcbs address this?

> -		skb = lan966x_fdma_pci_rx_get_frame(rx, src_port);
> +		skb = lan966x_fdma_pci_rx_get_frame(rx,
> +						    src_port,
> +						    data,
> +						    data_len);
>  		fdma_dcb_advance(fdma);
>  		if (!skb) {
>  			lan966x->ports[src_port]->dev->stats.rx_dropped++;

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260918-lan966x-pci-fdma-v7-0-0ecc179c8a2c%40microchip.com

Re: [PATCH net-next v7 12/14] net: lan966x: add PCIe FDMA XDP support

[Daniel Machon]

> Thank you for your contribution! Sashiko AI review found 3 potential
> issue(s) to consider.
> 
> Critical: 0 · High: 0 · Medium: 3 · Low: 0
> 
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
> 
> - [Medium] The same lan966x driver now presents two different XDP frame
>   views depending on the FDMA back-end.
> - [Medium] lan966x_xdp_pci_run()
>   (drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c) has no…
> - [Medium] lan966x_fdma_pci_napi_poll() bounds its RX loop only by the
>   caller-supplied weight, and clears the DONE bits solely in the…
> 
> --
> 
> net: lan966x: add PCIe FDMA XDP support
> 
> This adds XDP support to the lan966x PCIe FDMA path, running the BPF
> program on the contiguous ATU-mapped RX buffer and implementing XDP_TX by
> rebuilding the IFH and memcpy'ing the post-XDP frame into a TX slot. The
> IFH and FCS are now stripped in lan966x_fdma_pci_rx_check_frame() before
> the program runs, and lan966x_xdp_setup() no longer rejects programs on
> the PCIe path.
> 
> A few questions below.
> 
> > diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> > index 940425beec2f..e833dbb4fcf0 100644
> > --- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> > +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> 
> [ ... ]
> 
> > +static int lan966x_xdp_pci_run(struct lan966x_port *port, void *data,
> > +                            u32 data_len, void **xdp_data, u32 *xdp_len)
> > +{
> 
> [ ... ]
> 
> > +     act = bpf_prog_run_xdp(xdp_prog, &xdp);
> > +
> > +     *xdp_data = xdp.data;
> > +     *xdp_len = xdp.data_end - xdp.data;
> > +
> > +     switch (act) {
> > +     case XDP_PASS:
> > +             return FDMA_PASS;
> > +     case XDP_TX:
> > +             return lan966x_fdma_pci_xmit_xdpf(port, *xdp_data, *xdp_len) ?
> > +                    FDMA_DROP : FDMA_TX;
> > +     default:
> > +             bpf_warn_invalid_xdp_action(port->dev, xdp_prog, act);
> 
> [Severity: Medium]
> Should this switch have an XDP_REDIRECT arm, at least for the bonding
> case?  XDP_TX can be rewritten into XDP_REDIRECT inside
> bpf_prog_run_xdp() before the driver sees the action:
> 
> include/net/xdp.h:bpf_prog_run_xdp() {
>         u32 act = __bpf_prog_run(prog, xdp, BPF_DISPATCHER_FUNC(xdp));
> 
>         if (static_branch_unlikely(&bpf_master_redirect_enabled_key)) {
>                 if (act == XDP_TX && netif_is_bond_slave(xdp->rxq->dev))
>                         act = xdp_master_redirect(xdp);
>         }
>         ...
> }
> 
> bond_xdp_set() increments bpf_master_redirect_enabled_key and only
> requires the slave to provide ndo_bpf and ndo_xdp_xmit, both of which
> lan966x_port_netdev_ops provides on the PCIe path as well.  Before this
> patch lan966x_xdp_setup() rejected any program on the PCIe path, so this
> combination was not reachable; now it is.
> 
> With no XDP_REDIRECT case, a program returning XDP_TX on a bonded PCIe
> port lands in the default arm, so the frame is dropped,
> bpf_warn_invalid_xdp_action() prints "Driver unsupported XDP return value
> 4", trace_xdp_exception() fires, and the per-CPU redirect info stashed by
> xdp_master_redirect() is never consumed - while lan966x_probe_port() now
> advertises NETDEV_XDP_ACT_BASIC (XDP_TX) for exactly this path.
> 
> The other implementer of the same lan966x_fdma_action values,
> lan966x_xdp_run() in lan966x_xdp.c, does handle XDP_REDIRECT, so the two
> sides of the shared enum disagree.
> 

I think this is fine. We explicitly tell (through dev->xdp_features) that we do
not support NETDEV_XDP_ACT_REDIRECT in the PCI path, so falling back to a
warning seems OK to me.

> > +             fallthrough;
> > +     case XDP_ABORTED:
> > +             trace_xdp_exception(port->dev, xdp_prog, act);
> > +             fallthrough;
> > +     case XDP_DROP:
> > +             return FDMA_DROP;
> > +     }
> > +}
> > +
> > +static int lan966x_fdma_pci_rx_check_frame(struct lan966x_rx *rx, u64 *src_port,
> > +                                        void **data, u32 *data_len)
> >  {
> >       struct lan966x *lan966x = rx->lan966x;
> >       struct fdma *fdma = &rx->fdma;
> > @@ -168,38 +286,33 @@ static int lan966x_fdma_pci_rx_check_frame(struct lan966x_rx *rx, u64 *src_port)
> >       if (!lan966x_fdma_pci_rx_size_fits(fdma, blockl))
> >               return FDMA_ERROR;
> >
> > -     return FDMA_PASS;
> > +     /* Present the Ethernet frame (no IFH, no FCS). HW re-inserts the
> > +      * FCS on TX; see lan966x_fdma_pci_xmit_xdpf(). May be overridden
> > +      * by XDP. The FCS strip is unconditional because NETIF_F_RXFCS
> > +      * is not advertised in hw_features.
> > +      */
> > +     *data = virt_addr + IFH_LEN_BYTES;
> > +     *data_len = blockl - IFH_LEN_BYTES - ETH_FCS_LEN;
> > +
> > +     return lan966x_xdp_pci_run(port, virt_addr, *data_len, data, data_len);
> >  }
> 
> [Severity: Medium]
> The commit message states:
> 
>     XDP sees the frame with IFH and FCS stripped.
> 
> Is that only true for the PCIe back-end?  The platform back-end of the
> same driver hands the FCS to the program:
> 
> drivers/net/ethernet/microchip/lan966x/lan966x_xdp.c:lan966x_xdp_run() {
>         ...
>         xdp_prepare_buff(&xdp, page_address(page),
>                          IFH_LEN_BYTES + XDP_PACKET_HEADROOM,
>                          data_len - IFH_LEN_BYTES, false);
>         ...
> }
> 
> and the trailing 4 bytes are only removed afterwards, once the program has
> already run:
> 
> drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c:lan966x_fdma_rx_get_frame() {
>         ...
>         if (likely(!(skb->dev->features & NETIF_F_RXFCS)))
>                 skb_trim(skb, skb->len - ETH_FCS_LEN);
>         ...
> }
> 
> So one XDP program keyed on xdp->data_end - xdp->data, or doing an IP
> total-length cross-check or tail parsing, sees 4 extra bytes on a platform
> lan966x and not on a PCIe lan966x, and for XDP_TX the platform path
> re-sends the stale FCS as payload while the PCIe path strips it and lets
> HW insert a fresh one.
> 
> Could either the platform path be harmonized in this series, or the commit
> message say that the divergence is known and intentional?

Same as my reply to v6. I believe the correct handling (as done here) is to
strip the FCS before the program runs. Also, the platform path does not even use
the post-program length, so its not really compareable.

> 
> [ ... ]
> 
> > @@ -287,6 +400,8 @@ static int lan966x_fdma_pci_napi_poll(struct napi_struct *napi, int weight)
> >       struct sk_buff *skb;
> >       int counter = 0;
> >       u64 src_port;
> > +     u32 data_len;
> > +     void *data;
> >
> >       /* Wake any stopped TX queues if a TX DCB is available. */
> >       spin_lock(&lan966x->tx_lock);
> > @@ -303,7 +418,10 @@ static int lan966x_fdma_pci_napi_poll(struct napi_struct *napi, int weight)
> >               /* Order DONE read before DCB/frame reads below. */
> >               dma_rmb();
> >               counter++;
> > -             switch (lan966x_fdma_pci_rx_check_frame(rx, &src_port)) {
> > +             switch (lan966x_fdma_pci_rx_check_frame(rx,
> > +                                                     &src_port,
> > +                                                     &data,
> > +                                                     &data_len)) {
> >               case FDMA_PASS:
> >                       break;
> >               case FDMA_ERROR:
> > @@ -312,8 +430,17 @@ static int lan966x_fdma_pci_napi_poll(struct napi_struct *napi, int weight)
> >                        */
> >                       fdma_dcb_advance(fdma);
> >                       continue;
> > +             case FDMA_TX:
> > +                     fdma_dcb_advance(fdma);
> > +                     continue;
> > +             case FDMA_DROP:
> > +                     fdma_dcb_advance(fdma);
> > +                     continue;
> >               }
> 
> [Severity: Medium]
> Can the same descriptors be processed twice when the RX loop consumes the
> whole ring in one poll?
> 
> The RX loop is bounded only by the caller-supplied weight, and the DONE
> bits are cleared solely by the fdma_dcb_add() in the replenish loop, whose
> trip count comes from a wrapped index comparison:
> 
> lan966x_fdma_pci_napi_poll() {
>         dcb_reload = fdma->dcb_index;
> 
>         while (counter < weight) {
>                 if (!fdma_has_frames(fdma))
>                         break;
>                 ...
>         }
>         while (dcb_reload != fdma->dcb_index) {
>                 old_dcb = dcb_reload;
>                 dcb_reload++;
>                 dcb_reload &= fdma->n_dcbs - 1;
> 
>                 fdma_dcb_add(fdma, old_dcb, ...);
>                 lan966x_fdma_rx_reload(rx);
>         }
>         ...
> }
> 
> The PCIe ring has FDMA_PCI_DCB_MAX = 256 descriptors.  With all 256 DONE
> and weight >= 256, fdma_dcb_advance() wraps fdma->dcb_index back to
> dcb_reload, so the replenish loop runs zero iterations: nothing is
> re-armed and no DONE bit is cleared.  counter == weight also suppresses
> napi_complete_done(), so the next poll re-processes the same 256
> descriptors - duplicate skbs via napi_gro_receive(), and with this patch
> the same frames are re-run through the BPF program and re-transmitted by
> lan966x_fdma_pci_xmit_xdpf() on XDP_TX.
> 
> A weight >= 256 is reachable through busy polling: SO_BUSY_POLL_BUDGET
> accepts up to U16_MAX (CAP_NET_ADMIN needed to raise it) and
> __napi_busy_loop() passes that budget straight into napi->poll():
> 
> net/core/dev.c:__napi_busy_loop() {
>         ...
>         work = napi_poll(napi, budget);
>         ...
> }
> 
> The loop shape itself came in with "net: lan966x: add"Can" PCIe FDMA support"
> earlier in this series, and the platform twin lan966x_fdma_napi_poll() has
> the same shape with 512 DCBs; this patch extends the switch with
> FDMA_TX/FDMA_DROP, which adds the repeated XDP execution and repeated
> transmit to the effects.  Would counting consumed descriptors and capping
> the loop at fdma->n_dcbs address this?
> 

Reachable only if budget is pushed above ring size. The PCI NAPI poll reuses the
same pattern as the platform path (and lan969x and sparx5), and no issues have
ever been observed or reported.

> > -             skb = lan966x_fdma_pci_rx_get_frame(rx, src_port);
> > +             skb = lan966x_fdma_pci_rx_get_frame(rx,
> > +                                                 src_port,
> > +                                                 data,
> > +                                                 data_len);
> >               fdma_dcb_advance(fdma);
> >               if (!skb) {
> >                       lan966x->ports[src_port]->dev->stats.rx_dropped++;
> 
> [ ... ]
> 
> --
> Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260918-lan966x-pci-fdma-v7-0-0ecc179c8a2c%40microchip.com

[PATCH net-next v7 13/14] misc: lan966x-pci: dts: extend cpu reg to cover PCIE DBI space

[Daniel Machon]

The ATU outbound windows used by the FDMA engine are programmed through
registers at offset 0x400000+, which falls outside the current cpu reg
mapping. Extend the cpu reg size from 0x100000 (1MB) to 0x800000 (8MB)
to cover the full PCIE DBI and iATU register space.

Tested-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
---
 drivers/misc/lan966x_pci.dtso | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/lan966x_pci.dtso b/drivers/misc/lan966x_pci.dtso
index 7b196b0a0eb6..7bb726550caf 100644
--- a/drivers/misc/lan966x_pci.dtso
+++ b/drivers/misc/lan966x_pci.dtso
@@ -135,7 +135,7 @@ lan966x_phy1: ethernet-lan966x_phy@2 {
 
 				switch: switch@e0000000 {
 					compatible = "microchip,lan966x-switch";
-					reg = <0xe0000000 0x0100000>,
+					reg = <0xe0000000 0x0800000>,
 					      <0xe2000000 0x0800000>;
 					reg-names = "cpu", "gcb";
 

-- 
2.34.1

Re: [PATCH net-next v7 13/14] misc: lan966x-pci: dts: extend cpu reg to cover PCIE DBI space

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] Claimed DT-overlay/driver mismatch: the overlay whose "cpu" reg
  is extended for the ATU registers still declares only interrupts = <12…

--

misc: lan966x-pci: dts: extend cpu reg to cover PCIE DBI space

This grows the "cpu" reg region of the lan966x switch node in the PCI
overlay from 0x100000 to 0x800000 so the iATU outbound window registers
at offset 0x400000+ fall inside the mapping.

> diff --git a/drivers/misc/lan966x_pci.dtso b/drivers/misc/lan966x_pci.dtso
> index 7b196b0a0eb6..7bb726550caf 100644
> --- a/drivers/misc/lan966x_pci.dtso
> +++ b/drivers/misc/lan966x_pci.dtso
> @@ -135,7 +135,7 @@ lan966x_phy1: ethernet-lan966x_phy@2 {
>  
>  				switch: switch@e0000000 {
>  					compatible = "microchip,lan966x-switch";
> -					reg = <0xe0000000 0x0100000>,
> +					reg = <0xe0000000 0x0800000>,
>  					      <0xe2000000 0x0800000>;
>  					reg-names = "cpu", "gcb";
>  

[Severity: Low]
At this commit the same switch node still only declares:

	interrupts = <12 IRQ_TYPE_LEVEL_HIGH>,
		     <9 IRQ_TYPE_LEVEL_HIGH>;
	interrupt-names = "xtr", "ana";

so lan966x_probe() does not find a named "fdma" interrupt:

	lan966x->fdma_irq = platform_get_irq_byname(pdev, "fdma");
	if (lan966x->fdma_irq > 0) { ... lan966x->fdma = true; }

and lan966x_fdma_pci_init() returns early before the ATU setup:

	if (!lan966x->fdma)
		return 0;

which leaves the enlarged "cpu" window without a consumer until the next
patch in the series, "misc: lan966x-pci: dts: add fdma interrupt to
overlay", adds <14 IRQ_TYPE_LEVEL_HIGH> and the "fdma" name to this node.

Is it worth folding the two overlay changes into one patch, or ordering
the interrupt patch first, so the tree is never in the intermediate state?
The driver falls back to register based extraction/injection in the
meantime, so this looks harmless either way.

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260918-lan966x-pci-fdma-v7-0-0ecc179c8a2c%40microchip.com

[PATCH net-next v7 14/14] misc: lan966x-pci: dts: add fdma interrupt to overlay

[Daniel Machon]

Add the fdma interrupt (OIC interrupt 14) to the lan966x PCI device
tree overlay, enabling FDMA-based frame injection/extraction when
the switch is connected over PCIe.

Tested-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
---
 drivers/misc/lan966x_pci.dtso | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/lan966x_pci.dtso b/drivers/misc/lan966x_pci.dtso
index 7bb726550caf..5bb12dbc0843 100644
--- a/drivers/misc/lan966x_pci.dtso
+++ b/drivers/misc/lan966x_pci.dtso
@@ -141,8 +141,9 @@ switch: switch@e0000000 {
 
 					interrupt-parent = <&oic>;
 					interrupts = <12 IRQ_TYPE_LEVEL_HIGH>,
+						     <14 IRQ_TYPE_LEVEL_HIGH>,
 						     <9 IRQ_TYPE_LEVEL_HIGH>;
-					interrupt-names = "xtr", "ana";
+					interrupt-names = "xtr", "fdma", "ana";
 
 					resets = <&reset 0>;
 					reset-names = "switch";

-- 
2.34.1

Re: [PATCH net-next v7 14/14] misc: lan966x-pci: dts: add fdma interrupt to overlay

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] Concern retained for combined policy, but my verification says
  FALSE POSITIVE.

--

misc: lan966x-pci: dts: add fdma interrupt to overlay

This adds OIC interrupt 14 to the switch node of the lan966x PCI device tree
overlay and names it "fdma". With the name present, the lan966x driver picks
up the FDMA interrupt and uses the FDMA-based injection/extraction path for
PCIe instances.

> diff --git a/drivers/misc/lan966x_pci.dtso b/drivers/misc/lan966x_pci.dtso
> index 7bb726550caf..5bb12dbc0843 100644
> --- a/drivers/misc/lan966x_pci.dtso
> +++ b/drivers/misc/lan966x_pci.dtso
> @@ -141,8 +141,9 @@ switch: switch@e0000000 {
>  
>  					interrupt-parent = <&oic>;
>  					interrupts = <12 IRQ_TYPE_LEVEL_HIGH>,
> +						     <14 IRQ_TYPE_LEVEL_HIGH>,
>  						     <9 IRQ_TYPE_LEVEL_HIGH>;
> -					interrupt-names = "xtr", "ana";
> +					interrupt-names = "xtr", "fdma", "ana";

[Severity: Low]
This isn't a bug, but would it be worth spelling out in the commit message
that this line alone changes behaviour for every existing PCIe deployment?

The overlay is built into the module (drivers/misc/Makefile adds
lan966x_pci.dtbo.o and lan966x_pci_load_overlay() applies it from
__dtbo_lan966x_pci_begin), so there is no way for a user to opt out of the
new name.

In lan966x_probe() the presence of the name is the only thing that selects
the data path:

	lan966x->fdma_irq = platform_get_irq_byname(pdev, "fdma");
	if (lan966x->fdma_irq > 0) {
		...
		lan966x->fdma = true;

and lan966x_probe_port() then derives the advertised MTU ceiling from it:

	dev->max_mtu = lan966x_is_pci(lan966x) && lan966x->fdma ?
		       FDMA_PCI_MAX_MTU : ETH_MAX_MTU;

So after this patch PCIe ports report FDMA_PCI_MAX_MTU instead of
ETH_MAX_MTU, and ndo_change_mtu rejects values above that cap.

FDMA_PCI_MAX_MTU is derived from PAGE_SIZE << MAX_PAGE_ORDER, which the
preceding commit "net: lan966x: add PCIe FDMA MTU change support" documents
as 15498 on a 4KB-page, MAX_PAGE_ORDER=10 build, i.e. above any practical
jumbo value, so the change looks intentional and harmless in practice.
Would a sentence in this commit message noting the switch to FDMA and the
resulting max_mtu change make the series easier to bisect against later?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260918-lan966x-pci-fdma-v7-0-0ecc179c8a2c%40microchip.com