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

On Wed, Sep 23, 2026 at 10:11:55PM +0200, Daniel Machon wrote:

quoted

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

...

quoted

quoted

[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/ (local)

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?

I think that should be a last resort. I won't hold out on this,
but I would prefer the approach I suggested.

...