netdev - Re: [v4,1/4] net: stmmac: platform: read channels irq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260129050959.375635-1-kuba@kernel.org>
Date: Wed, 28 Jan 2026 21:09:59 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: jan.petrous@....nxp.com
Cc: Jakub Kicinski <kuba@...nel.org>,
	edumazet@...gle.com,
	shawnguo@...nel.org,
	kernel@...gutronix.de,
	krzk+dt@...nel.org,
	robh@...nel.org,
	andrew+netdev@...n.ch,
	mbrugger@...e.com,
	davem@...emloft.net,
	pabeni@...hat.com,
	linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	netdev@...r.kernel.org,
	s32@....com,
	imx@...ts.linux.dev,
	linux-stm32@...md-mailman.stormreply.com,
	s.hauer@...gutronix.de,
	conor+dt@...nel.org,
	chester62515@...il.com,
	festevam@...il.com,
	mcoquelin.stm32@...il.com,
	ghennadi.procopciuc@....nxp.com,
	devicetree@...r.kernel.org,
	alexandre.torgue@...s.st.com
Subject: Re: [v4,1/4] net: stmmac: platform: read channels irq

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: stmmac: platform: read channels irq

This patch reads IRQ resources for all rx/tx channels to allow Multi-IRQ
mode for platform glue drivers.

> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> index 8979a50b5507..94854bfb6e0d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c

[ ... ]

> +	/* RX channels irq */
> +	for (i = 0; i < MTL_MAX_RX_QUEUES; i++) {
> +		scnprintf(name, sizeof(name), "rx-queue-%d", i);
> +		stmmac_res->rx_irq[i] = platform_get_irq_byname_optional(pdev,
> +									 name);
> +		if (stmmac_res->rx_irq[i] <= 0) {
> +			if (stmmac_res->rx_irq[i] == -EPROBE_DEFER)
> +				return -EPROBE_DEFER;
> +			dev_dbg(&pdev->dev, "IRQ rx-queue-%d not found\n", i);
> +
> +			/* Stop on first unset rx-queue-%i property member */
> +			break;
> +		}
> +	}

When platform_get_irq_byname_optional() returns a negative error like
-ENXIO, that value is stored in stmmac_res->rx_irq[i] before the break.

In stmmac_request_irq_multi_msi(), the check is:

    if (priv->rx_irq[i] == 0)
        continue;
    ret = request_irq(priv->rx_irq[i], ...);

Should the negative value be cleared before the break? Otherwise if
rx_queues_to_use exceeds the number of defined IRQs, the negative error
code could be passed to request_irq().

> +
> +	/* TX channels irq */
> +	for (i = 0; i < MTL_MAX_TX_QUEUES; i++) {
> +		scnprintf(name, sizeof(name), "tx-queue-%d", i);
> +		stmmac_res->tx_irq[i] = platform_get_irq_byname_optional(pdev,
> +									 name);
> +		if (stmmac_res->tx_irq[i] <= 0) {
> +			if (stmmac_res->tx_irq[i] == -EPROBE_DEFER)
> +				return -EPROBE_DEFER;
> +			dev_dbg(&pdev->dev, "IRQ tx-queue-%d not found\n", i);
> +
> +			/* Stop on first unset tx-queue-%i property member */
> +			break;
> +		}
> +	}

Same question here for tx_irq[i].
-- 
pw-bot: cr