[net PATCH] net: ethernet: mediatek: only enable WED for ARM64 architecture

[netdev-bot+sashiko at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] Inappropriate `Fixes:` tag: the commit claims to fix
  804775dfc288 ("net: ethernet: mtk_eth_soc: add support for Wireless…

--

net: ethernet: mediatek: only enable WED for ARM64 architecture

This narrows the dependency of the hidden def_bool symbol
NET_MEDIATEK_SOC_WED so it is only enabled on ARM64 ARCH_MEDIATEK
builds, on the grounds that only MT7622 and MT798x implement WED.

> diff --git a/drivers/net/ethernet/mediatek/Kconfig b/drivers/net/ethernet/mediatek/Kconfig
> index 2ba361f8ce7d..7737f2f15478 100644
> --- a/drivers/net/ethernet/mediatek/Kconfig
> +++ b/drivers/net/ethernet/mediatek/Kconfig

>     Fixes: 804775dfc288 ("net: ethernet: mtk_eth_soc: add support for Wireless Ethernet Dispatch (WED)")

[Severity: Medium]

Is the Fixes: tag appropriate here?  The changelog does not describe a
defect, only a hardware-scope observation and a prediction:

    Currently, only MT7622 and MT798x SoCs support WED features. They
    are all ARM64 platforms. And it is unlikely that MediaTek will
    release a new net chip based on ARM32 architecture in the future.

As far as I can tell nothing misbehaves on 32-bit today.  WED is only
instantiated when the ethernet DT node carries a mediatek,wed phandle:

drivers/net/ethernet/mediatek/mtk_eth_soc.c:mtk_probe() {
	...
	np = of_parse_phandle(pdev->dev.of_node,
			      "mediatek,wed", i);
	if (!np)
		break;
	...
	mtk_wed_add_hw(np, eth, eth->base + wdma_base, wdma_phy, i);
	...
}

and git grep wed arch/arm/boot/dts/mediatek returns no matches, so no
32-bit MediaTek platform can reach mtk_wed_add_hw().

There also does not appear to be any 64-bit-only construct that a
depends on ARM64 would be repairing: mtk_wed.c, mtk_wed_wo.c,
mtk_wed_mcu.c and mtk_wed.h contain no readq/writeq, no >> 32 address
splitting and no CONFIG_64BIT conditionals (the only CONFIG_64BIT use in
the directory is in mtk_eth_soc.h, which this symbol does not gate).

> @@ -8,7 +8,7 @@ config NET_VENDOR_MEDIATEK
>  if NET_VENDOR_MEDIATEK
>  
>  config NET_MEDIATEK_SOC_WED
> -	depends on ARCH_MEDIATEK || COMPILE_TEST
> +	depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
>  	def_bool NET_MEDIATEK_SOC != n

Since the Fixes: tag makes this a candidate for stable backporting, could
this silently flip a config symbol in released kernels?  On a stable tree
with 32-bit ARCH_MEDIATEK, the depends on line becomes false and
NET_MEDIATEK_SOC_WED is a hidden def_bool, so make olddefconfig drops
mtk_wed*.o from the build with no prompt or warning.

Would it make sense to drop the Fixes: tag and describe this as a build
scope cleanup instead?

One more question on the ARM64 condition itself: if something in the WED
code really is not buildable on 32-bit, does the || COMPILE_TEST branch
leave that unaddressed, since it still builds the identical code on
non-ARM64 targets?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/OSZPR01MB8140B889AD227E0B547F5F87BC872%40OSZPR01MB8140.jpnprd01.prod.outlook.com