[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b0a2ddd4-6a91-43cd-9546-a9c3dff4fac2@lunn.ch>
Date: Thu, 20 Apr 2023 17:29:30 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Arnd Bergmann <arnd@...nel.org>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Florian Fainelli <f.fainelli@...il.com>,
Christian Marangi <ansuelsmth@...il.com>,
Arnd Bergmann <arnd@...db.de>,
Russell King <linux@...linux.org.uk>,
Frank Sae <Frank.Sae@...or-comm.com>,
Randy Dunlap <rdunlap@...radead.org>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: phy: fix circular LEDS_CLASS dependencies
On Thu, Apr 20, 2023 at 10:45:51AM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@...db.de>
>
> The CONFIG_PHYLIB symbol is selected by a number of device drivers that
> need PHY support, but it now has a dependency on CONFIG_LEDS_CLASS,
> which may not be enabled, causing build failures.
>
> Avoid the risk of missing and circular dependencies by guarding the
> phylib LED support itself in another Kconfig symbol that can only be
> enabled if the dependency is met.
>
> This could be made a hidden symbol and always enabled when both CONFIG_OF
> and CONFIG_LEDS_CLASS are reachable from the phylib, but there may be an
> advantage in having users see this option when they have a misconfigured
> kernel without built-in LED support.
>
> Fixes: 01e5b728e9e4 ("net: phy: Add a binding for PHY LEDs")
> Signed-off-by: Arnd Bergmann <arnd@...db.de>
This is for net-next.
Reviewed-by: Andrew Lunn <andrew@...n.ch>
Andrew
Powered by blists - more mailing lists