[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230420190905.47c54ccd@kernel.org>
Date: Thu, 20 Apr 2023 19:09:05 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Arnd Bergmann <arnd@...nel.org>
Cc: Andrew Lunn <andrew@...n.ch>,
Heiner Kallweit <hkallweit1@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
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, 20 Apr 2023 10:45:51 +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.
The problem is breaking build for the config I use in testing,
so let me apply without waiting full review period. Thanks!
Powered by blists - more mailing lists