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 rdunlap@infradead.org Cc: Ville Syrjälä ville.syrjala@linux.intel.com Cc: Jani Nikula jani.nikula@intel.com Cc: Damien Lespiau damien.lespiau@intel.com Cc: Daniel Vetter daniel.vetter@ffwll.ch Cc: Jani Nikula jani.nikula@linux.intel.com Cc: Joonas Lahtinen joonas.lahtinen@linux.intel.com Cc: Rodrigo Vivi rodrigo.vivi@intel.com Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org --- 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 rdunlap@infradead.org 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 rdunlap@infradead.org Cc: Ville Syrjälä ville.syrjala@linux.intel.com Cc: Jani Nikula jani.nikula@intel.com Cc: Damien Lespiau damien.lespiau@intel.com Cc: Daniel Vetter daniel.vetter@ffwll.ch Cc: Jani Nikula jani.nikula@linux.intel.com Cc: Joonas Lahtinen joonas.lahtinen@linux.intel.com Cc: Rodrigo Vivi rodrigo.vivi@intel.com Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org
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 4/27/21 1:03 AM, Jani Nikula wrote:
On Mon, 26 Apr 2021, Randy Dunlap rdunlap@infradead.org 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.
dri-devel@lists.freedesktop.org
-
Jani Nikula -
Randy Dunlap