When CONFIG_DRM_I915=y, CONFIG_ACPI is not set, and
CONFIG_BACKLIGHT_CLASS_DEVICE=m, not due to I915 config,
there are build errors trying to reference backlight_device_{un}register().
Changing the use of IS_ENABLED() to IS_REACHABLE() in intel_panel.[ch]
fixes this.
ld: drivers/gpu/drm/i915/display/intel_panel.o: in function `intel_backlight_device_register':
intel_panel.c:(.text+0x2ec1): undefined reference to `backlight_device_register'
ld: drivers/gpu/drm/i915/display/intel_panel.o: in function `intel_backlight_device_unregister':
intel_panel.c:(.text+0x2f93): undefined reference to `backlight_device_unregister'
ld: drivers/gpu/drm/i915/display/intel_panel.o: in function `intel_backlight_device_register':
intel_panel.c:(.text+0x2ec1): undefined reference to `backlight_device_register'
ld: drivers/gpu/drm/i915/display/intel_panel.o: in function `intel_backlight_device_unregister':
intel_panel.c:(.text+0x2f93): undefined reference to `backlight_device_unregister'
Fixes: 912e8b12eedb ("drm/i915: register backlight device also when backlight class is a module")
Fixes: 44c1220a441c ("drm/i915: extract intel_panel.h from intel_drv.h")
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Damien Lespiau <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Cc: [email protected]
Cc: [email protected]
---
Found in linux-next but applies to mainline (5.12).
drivers/gpu/drm/i915/display/intel_panel.c | 2 +-
drivers/gpu/drm/i915/display/intel_panel.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- linux-next-20210426.orig/drivers/gpu/drm/i915/display/intel_panel.c
+++ linux-next-20210426/drivers/gpu/drm/i915/display/intel_panel.c
@@ -1254,7 +1254,7 @@ void intel_panel_enable_backlight(const
mutex_unlock(&dev_priv->backlight_lock);
}
-#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
+#if IS_REACHABLE(CONFIG_BACKLIGHT_CLASS_DEVICE)
static u32 intel_panel_get_backlight(struct intel_connector *connector)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
--- linux-next-20210426.orig/drivers/gpu/drm/i915/display/intel_panel.h
+++ linux-next-20210426/drivers/gpu/drm/i915/display/intel_panel.h
@@ -54,7 +54,7 @@ u32 intel_panel_invert_pwm_level(struct
u32 intel_panel_backlight_level_to_pwm(struct intel_connector *connector, u32 level);
u32 intel_panel_backlight_level_from_pwm(struct intel_connector *connector, u32 val);
-#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
+#if IS_REACHABLE(CONFIG_BACKLIGHT_CLASS_DEVICE)
int intel_backlight_device_register(struct intel_connector *connector);
void intel_backlight_device_unregister(struct intel_connector *connector);
#else /* CONFIG_BACKLIGHT_CLASS_DEVICE */
On Mon, 26 Apr 2021, Randy Dunlap <[email protected]> wrote:
> When CONFIG_DRM_I915=y, CONFIG_ACPI is not set, and
> CONFIG_BACKLIGHT_CLASS_DEVICE=m, not due to I915 config,
> there are build errors trying to reference backlight_device_{un}register().
>
> Changing the use of IS_ENABLED() to IS_REACHABLE() in intel_panel.[ch]
> fixes this.
I feel like a broken record...
CONFIG_DRM_I915=y and CONFIG_BACKLIGHT_CLASS_DEVICE=m is an invalid
configuration. The patch at hand just silently hides the problem,
leaving you without backlight.
i915 should *depend* on backlight, not select it. It would express the
dependency without chances for invalid configuration.
However, i915 alone can't depend on backlight, all users of backlight
should depend on backlight, not select it. Otherwise, you end up with
other configuration problems, circular dependencies and
whatnot. Everyone should change. See also (*) why select is not a good
idea here.
I've sent patches to this effect before, got rejected, and the same
thing gets repeated ad infinitum.
Accepting this patch would stop the inflow of these reports and similar
patches, but it does not fix the root cause. It just sweeps the problem
under the rug.
BR,
Jani.
(*) Documentation/kbuild/kconfig-language.rst:
select should be used with care. select will force
a symbol to a value without visiting the dependencies.
By abusing select you are able to select a symbol FOO even
if FOO depends on BAR that is not set.
In general use select only for non-visible symbols
(no prompts anywhere) and for symbols with no dependencies.
That will limit the usefulness but on the other hand avoid
the illegal configurations all over.
>
> ld: drivers/gpu/drm/i915/display/intel_panel.o: in function `intel_backlight_device_register':
> intel_panel.c:(.text+0x2ec1): undefined reference to `backlight_device_register'
> ld: drivers/gpu/drm/i915/display/intel_panel.o: in function `intel_backlight_device_unregister':
> intel_panel.c:(.text+0x2f93): undefined reference to `backlight_device_unregister'
>
> ld: drivers/gpu/drm/i915/display/intel_panel.o: in function `intel_backlight_device_register':
> intel_panel.c:(.text+0x2ec1): undefined reference to `backlight_device_register'
> ld: drivers/gpu/drm/i915/display/intel_panel.o: in function `intel_backlight_device_unregister':
> intel_panel.c:(.text+0x2f93): undefined reference to `backlight_device_unregister'
>
> Fixes: 912e8b12eedb ("drm/i915: register backlight device also when backlight class is a module")
> Fixes: 44c1220a441c ("drm/i915: extract intel_panel.h from intel_drv.h")
> Signed-off-by: Randy Dunlap <[email protected]>
> Cc: Ville Syrjälä <[email protected]>
> Cc: Jani Nikula <[email protected]>
> Cc: Damien Lespiau <[email protected]>
> Cc: Daniel Vetter <[email protected]>
> Cc: Jani Nikula <[email protected]>
> Cc: Joonas Lahtinen <[email protected]>
> Cc: Rodrigo Vivi <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> ---
> Found in linux-next but applies to mainline (5.12).
>
> drivers/gpu/drm/i915/display/intel_panel.c | 2 +-
> drivers/gpu/drm/i915/display/intel_panel.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> --- linux-next-20210426.orig/drivers/gpu/drm/i915/display/intel_panel.c
> +++ linux-next-20210426/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -1254,7 +1254,7 @@ void intel_panel_enable_backlight(const
> mutex_unlock(&dev_priv->backlight_lock);
> }
>
> -#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
> +#if IS_REACHABLE(CONFIG_BACKLIGHT_CLASS_DEVICE)
> static u32 intel_panel_get_backlight(struct intel_connector *connector)
> {
> struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> --- linux-next-20210426.orig/drivers/gpu/drm/i915/display/intel_panel.h
> +++ linux-next-20210426/drivers/gpu/drm/i915/display/intel_panel.h
> @@ -54,7 +54,7 @@ u32 intel_panel_invert_pwm_level(struct
> u32 intel_panel_backlight_level_to_pwm(struct intel_connector *connector, u32 level);
> u32 intel_panel_backlight_level_from_pwm(struct intel_connector *connector, u32 val);
>
> -#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
> +#if IS_REACHABLE(CONFIG_BACKLIGHT_CLASS_DEVICE)
> int intel_backlight_device_register(struct intel_connector *connector);
> void intel_backlight_device_unregister(struct intel_connector *connector);
> #else /* CONFIG_BACKLIGHT_CLASS_DEVICE */
--
Jani Nikula, Intel Open Source Graphics Center
On 4/27/21 1:03 AM, Jani Nikula wrote:
> On Mon, 26 Apr 2021, Randy Dunlap <[email protected]> wrote:
>> When CONFIG_DRM_I915=y, CONFIG_ACPI is not set, and
>> CONFIG_BACKLIGHT_CLASS_DEVICE=m, not due to I915 config,
>> there are build errors trying to reference backlight_device_{un}register().
>>
>> Changing the use of IS_ENABLED() to IS_REACHABLE() in intel_panel.[ch]
>> fixes this.
>
> I feel like a broken record...
Thanks! :)
I'll leave it b0rken as well.
> CONFIG_DRM_I915=y and CONFIG_BACKLIGHT_CLASS_DEVICE=m is an invalid
> configuration. The patch at hand just silently hides the problem,
> leaving you without backlight.
>
> i915 should *depend* on backlight, not select it. It would express the
> dependency without chances for invalid configuration.
>
> However, i915 alone can't depend on backlight, all users of backlight
> should depend on backlight, not select it. Otherwise, you end up with
> other configuration problems, circular dependencies and
> whatnot. Everyone should change. See also (*) why select is not a good
> idea here.
>
> I've sent patches to this effect before, got rejected, and the same
> thing gets repeated ad infinitum.
>
> Accepting this patch would stop the inflow of these reports and similar
> patches, but it does not fix the root cause. It just sweeps the problem
> under the rug.
>
>
> BR,
> Jani.
>
> (*) Documentation/kbuild/kconfig-language.rst:
>
> select should be used with care. select will force
> a symbol to a value without visiting the dependencies.
> By abusing select you are able to select a symbol FOO even
> if FOO depends on BAR that is not set.
> In general use select only for non-visible symbols
> (no prompts anywhere) and for symbols with no dependencies.
> That will limit the usefulness but on the other hand avoid
> the illegal configurations all over.
Yes, I'm well aware of that.
ta.
--
~Randy