[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c07d07b3-42bc-4433-8f8d-3bee75218df7@lunn.ch>
Date: Tue, 21 Mar 2023 17:02:42 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Christian Marangi <ansuelsmth@...il.com>
Cc: Florian Fainelli <f.fainelli@...il.com>,
Vladimir Oltean <olteanv@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
Gregory Clement <gregory.clement@...tlin.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Pavel Machek <pavel@....cz>, Lee Jones <lee@...nel.org>,
John Crispin <john@...ozen.org>, netdev@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-arm-msm@...r.kernel.org, linux-leds@...r.kernel.org
Subject: Re: [net-next PATCH v5 04/15] leds: Provide stubs for when CLASS_LED
is disabled
> BTW yes I repro the problem.
>
> Checked the makefile and led-core.c is compiled with NEW_LEDS and
> led-class is compiled with LEDS_CLASS.
>
> led_init_default_state_get is in led-core.c and this is the problem with
> using LEDS_CLASS instead of NEW_LEDS...
>
> But actually why we are putting led_init_default_state_get behind a
> config? IMHO we should compile it anyway.
It is pointless if you don't have any LED support. To make it always
compiled, you would probably need to move it into leds.h. And then you
bloat every user with some code which is not hot path.
Andrew
Powered by blists - more mailing lists