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: <487b3b92-59e8-4ce5-88da-1d8176392d87@app.fastmail.com>
Date: Thu, 10 Apr 2025 14:46:11 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Christian Marangi" <ansuelsmth@...il.com>
Cc: "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:40, Christian Marangi wrote:
> On Thu, Apr 10, 2025 at 12:31:05PM +0200, Arnd Bergmann wrote:
>> 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?
>>
>
> If we base stuff on the fact that everything is selected or that a
> random config by luck selects it, then COMPILE_TEST doesn't make sense
> at all.
>
> For my personal test, I wanted to test the driver on a simple x86 build
> without having to depend on ARCH or having to cross compile. Won't
> happen on real world scenario? Totally. I should be able to compile it?
> Yes.

Being able to compile test the driver yourself is clearly
a good idea, I just don't think that requires the dependency to
be conditional here.

>> 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.
>> 
>
> The big idea of these dependency is that... In MTK the internal PHY of
> the switch needs calibration or it won't work hence it doesn't make
> sense to select the PHY as it won't ever work without the NVMEM driver.

That's not how dependencies normally work: the driver also fails
to work correctly if you are missing the correct pinctrl or led
driver, or the syscon, yet you don't list them explicitly because
you just need them for the machine to work correctly.

The driver dependencies should just list what you need to build,
regardless of whether you are compile-testing or building a driver
that is going to be used.

    Arnd