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

[netdev-bot+sashiko@kernel.org]

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