Re: [PATCH net-next v9 14/15] 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] At this commit, the switch@e0000000 node in
  drivers/misc/lan966x_pci.dtso gets an 8MB "cpu" reg for the PCIe…

--

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

This commit grows the "cpu" reg region of the switch@e0000000 node in the
lan966x PCI overlay from 1MB to 8MB. The FDMA engine programs its ATU
outbound windows through registers at offset 0x400000 and above, and the
larger mapping covers the PCIe DBI and iATU space that holds them.

> diff --git a/drivers/misc/lan966x_pci.dtso b/drivers/misc/lan966x_pci.dtso
> index 7b196b0a0eb65..7bb726550cafd 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]
This isn't a bug, but is the larger mapping used at this point in the
series?

At this commit the same node still has only two interrupts:

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

lan966x_probe() enables FDMA only when the named "fdma" interrupt exists:

    lan966x->fdma_irq = platform_get_irq_byname(pdev, "fdma");

Without it, lan966x->fdma stays false and lan966x_fdma_pci_init() returns
before the ATU is programmed:

    if (!lan966x->fdma)
        return 0;

So nothing touches the extra DBI/iATU space until the next patch in the
series, "misc: lan966x-pci: dts: add fdma interrupt to overlay". That
patch adds <14 IRQ_TYPE_LEVEL_HIGH> as "fdma" between "xtr" and "ana",
which matches the binding order.

The in-between state is not a regression, because the driver keeps using
register-based extraction. This is only about how the series is split.

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