public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: lukasz.majewski@mailbox.org
Cc: Jakub Kicinski <kuba@kernel.org>,
	festevam@gmail.com, linux-arm-kernel@lists.infradead.org,
	s.hauer@pengutronix.de, kernel@pengutronix.de, horms@kernel.org,
	shawnguo@kernel.org, imx@lists.linux.dev,
	linux-kernel@vger.kernel.org, conor+dt@kernel.org,
	devicetree@vger.kernel.org, wahrenst@gmx.net, pabeni@redhat.com,
	davem@davemloft.net, netdev@vger.kernel.org,
	richardcochran@gmail.com, edumazet@google.com,
	andrew+netdev@lunn.ch, robh@kernel.org, krzk+dt@kernel.org,
	andrew@lunn.ch
Subject: Re: [net-next,v20,2/7] net: mtip: The L2 switch driver for imx287
Date: Tue, 27 Jan 2026 18:25:49 -0800	[thread overview]
Message-ID: <20260128022549.4151341-1-kuba@kernel.org> (raw)
In-Reply-To: <20260126103400.1683125-3-lukasz.majewski@mailbox.org>

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net: mtip: The L2 switch driver for imx287

This patch adds support for the More Than IP L2 switch embedded in the
imx287 SoC. It creates a two-port switch driver that can be used
interchangeably with the FEC driver.

> diff --git a/drivers/net/ethernet/freescale/mtipsw/mtipl2sw.c b/drivers/net/ethernet/freescale/mtipsw/mtipl2sw.c
> new file mode 100644
> index 000000000000..03c5163d6508
> --- /dev/null
> +++ b/drivers/net/ethernet/freescale/mtipsw/mtipl2sw.c

[ ... ]

> +static void mtip_netif_stop_queues(struct switch_enet_private *fep)
> +{
> +	for (int i = 0; i < SWITCH_EPORT_NUMBER; i++)
> +		netif_stop_queue(fep->ndev[0]);
                                      ^^^

Should this be fep->ndev[i] instead of fep->ndev[0]? The loop iterates
with variable i but always uses index 0, so port 1's queue is never
stopped.

> +}
> +
> +static void mtip_netif_wake_queues(struct switch_enet_private *fep)
> +{
> +	for (int i = 0; i < SWITCH_EPORT_NUMBER; i++)
> +		netif_wake_queue(fep->ndev[0]);
                                      ^^^

Same here - should this be fep->ndev[i]?

> +}

[ ... ]

> +static int mtip_mii_probe(struct net_device *dev)
> +{
> +	struct mtip_ndev_priv *priv = netdev_priv(dev);
> +	struct switch_enet_private *fep = priv->fep;
> +	struct phy_device *phy_dev = NULL;
> +	int port_idx = priv->portnum - 1;
> +
> +	if (fep->phy_np[port_idx]) {
> +		phy_dev = of_phy_connect(dev, fep->phy_np[port_idx],
> +					 &mtip_adjust_link, 0,
> +					 fep->phy_interface[port_idx]);
> +		if (!phy_dev) {
> +			netdev_err(dev, "Unable to connect to phy\n");
> +			return -ENODEV;
> +		}
> +	}
> +
> +	phy_set_max_speed(phy_dev, 100);
                          ^^^^^^^

If fep->phy_np[port_idx] is NULL (no phy-handle in DT for this port),
the if block is skipped and phy_dev remains NULL. Can this cause a NULL
pointer dereference in phy_set_max_speed()?

> +	fep->phy_dev[port_idx] = phy_dev;

[ ... ]

> +static int mtip_parse_of(struct switch_enet_private *fep,
> +			 struct device_node *np)
> +{
> +	struct device_node *p;
> +	unsigned int port_num;
> +	int ret = 0;
> +
> +	p = of_get_child_by_name(np, "ethernet-ports");
> +
> +	for_each_available_child_of_node_scoped(p, port) {
> +		if (of_property_read_u32(port, "reg", &port_num))
> +			continue;
> +
> +		if (port_num > SWITCH_EPORT_NUMBER) {
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This only validates the upper bound. If the device tree contains
reg = <0>, would fep->mac[port_num - 1] access fep->mac[-1]? Perhaps
the check should also verify port_num is at least 1?

> +			dev_err(&fep->pdev->dev,
> +				"%s: The switch supports up to %d ports!\n",
> +				__func__, SWITCH_EPORT_NUMBER);
> +			goto of_get_err;
> +		}
> +
> +		fep->n_ports = port_num;
> +		ret = of_get_mac_address(port, &fep->mac[port_num - 1][0]);

[ ... ]

> +	ret = mtip_mii_init(fep, pdev);
> +	if (ret) {
> +		dev_err(&pdev->dev, "%s: Cannot init phy bus (%d)!\n", __func__,
> +			ret);
> +		goto dma_free_coherent_memory;
> +	}
> +
> +	ret = mtip_ndev_init(fep, pdev);
> +	if (ret) {
> +		dev_err(&pdev->dev, "%s: Failed to create virtual ndev (%d)\n",
> +			__func__, ret);
> +		goto mdiobus_free_memory;
> +	}

[ ... ]

> + mdiobus_free_memory:
> +	mdiobus_free(fep->mii_bus);

mtip_mii_init() calls of_mdiobus_register() which registers the bus.
Should mdiobus_unregister() be called here before mdiobus_free()?
Compare with mtip_mii_remove() which does call mdiobus_unregister().

> + dma_free_coherent_memory:
> +	dma_free_coherent(&fep->pdev->dev, PAGE_SIZE, fep->rx_bd_base,
> +			  fep->bd_dma);
> +	fep->rx_bd_base = NULL;
> +	fep->tx_bd_base = NULL;
> +
> +	return ret;
> +}
> +
> +static void mtip_sw_remove(struct platform_device *pdev)
> +{
> +	struct switch_enet_private *fep = platform_get_drvdata(pdev);
> +
> +	mtip_ndev_cleanup(fep);
> +
> +	mtip_mii_remove(fep);
> +
> +	timer_delete_sync(&fep->timer_mgnt);
> +	platform_set_drvdata(pdev, NULL);
> +}

mtip_sw_probe() allocates DMA memory with dma_alloc_coherent() in
mtip_switch_dma_init(), but mtip_sw_remove() does not appear to free it.
Is this a memory leak on driver removal?
-- 
pw-bot: cr

  reply	other threads:[~2026-01-28  2:25 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-26 10:33 [net-next v20 0/7] net: mtip: Add support for MTIP imx287 L2 switch driver Lukasz Majewski
2026-01-26 10:33 ` [net-next v20 1/7] dt-bindings: net: Add MTIP L2 switch description Lukasz Majewski
2026-01-26 10:33 ` [net-next v20 2/7] net: mtip: The L2 switch driver for imx287 Lukasz Majewski
2026-01-28  2:25   ` Jakub Kicinski [this message]
2026-01-28 21:41     ` [net-next,v20,2/7] " Łukasz Majewski
2026-01-28 22:00       ` Andrew Lunn
2026-01-28 22:47         ` Łukasz Majewski
2026-01-26 10:33 ` [net-next v20 3/7] net: mtip: Add buffers management functions to the L2 switch driver Lukasz Majewski
2026-01-28  2:25   ` [net-next,v20,3/7] " Jakub Kicinski
2026-01-28 21:48     ` Łukasz Majewski
2026-01-26 10:33 ` [net-next v20 4/7] net: mtip: Add net_device_ops " Lukasz Majewski
2026-01-28  2:25   ` [net-next,v20,4/7] " Jakub Kicinski
2026-01-28 21:55     ` Łukasz Majewski
2026-01-29  2:05       ` Jakub Kicinski
2026-01-26 10:33 ` [net-next v20 5/7] net: mtip: Add mtip_switch_{rx|tx} " Lukasz Majewski
2026-01-26 10:33 ` [net-next v20 6/7] net: mtip: Extend the L2 switch driver with management operations Lukasz Majewski
2026-01-26 10:34 ` [net-next v20 7/7] net: mtip: Extend the L2 switch driver for imx287 with bridge operations Lukasz Majewski
2026-01-28  2:26   ` [net-next,v20,7/7] " Jakub Kicinski
2026-01-28 22:58     ` Łukasz Majewski

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=20260128022549.4151341-1-kuba@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=andrew@lunn.ch \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=festevam@gmail.com \
    --cc=horms@kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=kernel@pengutronix.de \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukasz.majewski@mailbox.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=richardcochran@gmail.com \
    --cc=robh@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=wahrenst@gmx.net \
    /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