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: <ce81b985-ebcf-46f7-b773-50e42d2d10e7@lunn.ch>
Date:   Tue, 25 Apr 2023 23:38:15 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Paolo Abeni <pabeni@...hat.com>
Cc:     netdev@...r.kernel.org, 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>, Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH net-next] net: phy: drop PHYLIB_LEDS knob

On Tue, Apr 25, 2023 at 11:19:11PM +0200, Paolo Abeni wrote:
> commit 4bb7aac70b5d ("net: phy: fix circular LEDS_CLASS dependencies")
> solved a build failure, but introduces a new config knob with a default
> 'y' value: PHYLIB_LEDS.
> 
> The latter is against the current new config policy. The exception
> was raised to allow the user to catch bad configurations without led
> support.
> 
> Anyway the current definition of PHYLIB_LEDS does not fit the above
> goal: if LEDS_CLASS is disabled, the new config will be available
> only with PHYLIB disabled, too.
> 
> Instead of building a more complex and error-prone dependency definition
> it looks simpler and more in line with the mentioned policies use
> IS_REACHABLE(CONFIG_LEDS_CLASS) instead of the new symbol.
> 
> Suggested-by: Jakub Kicinski <kuba@...nel.org>
> Signed-off-by: Paolo Abeni <pabeni@...hat.com>
> ---
> @Andrew, @Arnd: the rationale here is to avoid the new config knob=y,
> which caused in the past a few complains from Linus. In this case I
> think the raised exception is not valid, for the reason mentioned above.
> 
> If you have different preferences or better solutions to address that,
> please voice them :)

Arnd did mention making it an invisible option. That would have the
advantage of keeping the hundreds of randcomfig builds which have been
done. How much time do you have now to do that before sending Linus
the pull request?

> ---
>  drivers/net/phy/Kconfig      | 9 ---------
>  drivers/net/phy/phy_device.c | 2 +-
>  2 files changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 2f3ddc446cbb..f83420b86794 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -44,15 +44,6 @@ config LED_TRIGGER_PHY
>  		<Speed in megabits>Mbps OR <Speed in gigabits>Gbps OR link
>  		for any speed known to the PHY.
>  
> -config PHYLIB_LEDS
> -	bool "Support probing LEDs from device tree"

I don't know Kconfig to well, but i think you just need to remove the
text, just keep the bool.

-       bool "Support probing LEDs from device tree"
+       bool

	Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ