mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: daniel.machon@microchip.com
Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com, horatiu.vultur@microchip.com,
	steen.hegelund@microchip.com, UNGLinuxDriver@microchip.com,
	ast@kernel.org, daniel@iogearbox.net, hawk@kernel.org,
	john.fastabend@gmail.com, sdf@fomichev.me,
	herve.codina@bootlin.com, arnd@arndb.de,
	gregkh@linuxfoundation.org, mohsin.bashr@gmail.com,
	richardcochran@gmail.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH net-next v7 09/14] net: lan966x: add shutdown callback to stop the FDMA on reboot
Date: Tue, 22 Sep 2026 13:00:49 +0000	[thread overview]
Message-ID: <179008204979.2160803.8934931337596115008@kernel.org> (raw)
In-Reply-To: <20260918-lan966x-pci-fdma-v7-9-0ecc179c8a2c@microchip.com>

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

  reply	other threads:[~2026-09-22 13:00 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-18 11:33 [PATCH net-next v7 00/14] net: lan966x: add support for PCIe FDMA Daniel Machon
2026-09-18 11:33 ` [PATCH net-next v7 01/14] MAINTAINERS: add FDMA library to Sparx5 SoC entry Daniel Machon
2026-09-18 11:33 ` [PATCH net-next v7 02/14] net: microchip: fdma: rename contiguous dataptr helpers Daniel Machon
2026-09-18 11:33 ` [PATCH net-next v7 03/14] net: microchip: fdma: add PCIe ATU support Daniel Machon
2026-09-22 13:00   ` netdev-bot+sashiko
2026-09-18 11:33 ` [PATCH net-next v7 04/14] net: lan966x: add FDMA LLP register write helper Daniel Machon
2026-09-22 13:00   ` netdev-bot+sashiko
2026-09-18 11:33 ` [PATCH net-next v7 05/14] net: lan966x: export FDMA helpers for reuse Daniel Machon
2026-09-18 11:33 ` [PATCH net-next v7 06/14] net: lan966x: use a dedicated device for DMA operations Daniel Machon
2026-09-18 11:33 ` [PATCH net-next v7 07/14] net: lan966x: add FDMA ops dispatch for PCIe support Daniel Machon
2026-09-18 11:34 ` [PATCH net-next v7 08/14] net: lan966x: clear FDMA interrupt stickies after switch reset Daniel Machon
2026-09-22 13:00   ` netdev-bot+sashiko
2026-09-18 11:34 ` [PATCH net-next v7 09/14] net: lan966x: add shutdown callback to stop the FDMA on reboot Daniel Machon
2026-09-22 13:00   ` netdev-bot+sashiko [this message]
2026-09-18 11:34 ` [PATCH net-next v7 10/14] net: lan966x: add PCIe FDMA support Daniel Machon
2026-09-22 13:00   ` netdev-bot+sashiko
2026-09-18 11:34 ` [PATCH net-next v7 11/14] net: lan966x: add PCIe FDMA MTU change support Daniel Machon
2026-09-22 13:00   ` netdev-bot+sashiko
2026-09-18 11:34 ` [PATCH net-next v7 12/14] net: lan966x: add PCIe FDMA XDP support Daniel Machon
2026-09-22 13:00   ` netdev-bot+sashiko
2026-09-18 11:34 ` [PATCH net-next v7 13/14] misc: lan966x-pci: dts: extend cpu reg to cover PCIE DBI space Daniel Machon
2026-09-22 13:00   ` netdev-bot+sashiko
2026-09-18 11:34 ` [PATCH net-next v7 14/14] misc: lan966x-pci: dts: add fdma interrupt to overlay Daniel Machon
2026-09-22 13:00   ` netdev-bot+sashiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=179008204979.2160803.8934931337596115008@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=arnd@arndb.de \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel.machon@microchip.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hawk@kernel.org \
    --cc=herve.codina@bootlin.com \
    --cc=horatiu.vultur@microchip.com \
    --cc=john.fastabend@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mohsin.bashr@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=richardcochran@gmail.com \
    --cc=sdf@fomichev.me \
    --cc=steen.hegelund@microchip.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®