linux-kernel - Re: [net-next PATCH v2 1/2] net: phy: mediatek: permit to compile test GE SOC PHY driver

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: <c108aee9-f668-4cd7-b276-d5e0a266eaa4@app.fastmail.com>
Date: Thu, 10 Apr 2025 12:31:05 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Christian Marangi" <ansuelsmth@...il.com>,
 "Andrew Lunn" <andrew@...n.ch>, "Heiner Kallweit" <hkallweit1@...il.com>,
 "Russell King" <linux@...linux.org.uk>,
 "David S . Miller" <davem@...emloft.net>,
 "Eric Dumazet" <edumazet@...gle.com>, "Jakub Kicinski" <kuba@...nel.org>,
 "Paolo Abeni" <pabeni@...hat.com>, "Daniel Golle" <daniel@...rotopia.org>,
 "Qingfang Deng" <dqfext@...il.com>,
 "SkyLake Huang" <SkyLake.Huang@...iatek.com>,
 "Matthias Brugger" <matthias.bgg@...il.com>,
 "AngeloGioacchino Del Regno" <angelogioacchino.delregno@...labora.com>,
 "Randy Dunlap" <rdunlap@...radead.org>, "Simon Horman" <horms@...nel.org>,
 Netdev <netdev@...r.kernel.org>, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org
Subject: Re: [net-next PATCH v2 1/2] net: phy: mediatek: permit to compile test GE SOC
 PHY driver

On Thu, Apr 10, 2025, at 12:04, Christian Marangi wrote:
> When commit 462a3daad679 ("net: phy: mediatek: fix compile-test
> dependencies") fixed the dependency, it should have also introduced
> an or on COMPILE_TEST to permit this driver to be compile-tested even if
> NVMEM_MTK_EFUSE wasn't selected

Why does this matter? NVMEM_MTK_EFUSE can be enabled for both
allmodconfig and randconfig builds on any architecture, so you
get build coverage either way, it's just a little less likely
to be enabled in randconfig I guess?

> diff --git a/drivers/net/phy/mediatek/Kconfig b/drivers/net/phy/mediatek/Kconfig
> index 2a8ac5aed0f8..6a4c2b328c41 100644
> --- a/drivers/net/phy/mediatek/Kconfig
> +++ b/drivers/net/phy/mediatek/Kconfig
> @@ -15,8 +15,7 @@ config MEDIATEK_GE_PHY
> 
>  config MEDIATEK_GE_SOC_PHY
>  	tristate "MediaTek SoC Ethernet PHYs"
> -	depends on (ARM64 && ARCH_MEDIATEK) || COMPILE_TEST
> -	depends on NVMEM_MTK_EFUSE
> +	depends on (ARM64 && ARCH_MEDIATEK && NVMEM_MTK_EFUSE) || COMPILE_TEST
>  	select MTK_NET_PHYLIB
>  	help
>  	  Supports MediaTek SoC built-in Gigabit Ethernet PHYs.
> -- 

I would expect this to break the build with CONFIG_NVMEM=m
and MEDIATEK_GE_SOC_PHY=y.

The normal thing here would be to have a dependency on
CONFIG_NVMEM in place of the NVMEM_MTK_EFUSE dependency,
or possible on 'NVMEM || !NVMEM' if you want to make it
more likely to be enabled in randconfig builds.

       Arnd