Message-ID: <CAKMK7uGpRkPsNqFR=taD68dT8T2tnEhias380ayGnjMH1b09xg@mail.gmail.com>
Date:   Tue, 14 Apr 2020 17:37:18 +0200
From:   Daniel Vetter <daniel@...ll.ch>
To:     Arnd Bergmann <arnd@...db.de>,
        "Nikula, Jani" <jani.nikula@...ux.intel.com>
Cc:     Andrzej Hajda <a.hajda@...sung.com>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        Jernej Skrabec <jernej.skrabec@...l.net>,
        Leon Romanovsky <leon@...nel.org>,
        Jonas Karlman <jonas@...boo.se>,
        David Airlie <airlied@...ux.ie>,
        Networking <netdev@...r.kernel.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Nicolas Pitre <nico@...xnic.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Neil Armstrong <narmstrong@...libre.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        "David S. Miller" <davem@...emloft.net>,
        linux-rdma <linux-rdma@...r.kernel.org>
Subject: Re: [RFC 4/6] drm/bridge/sii8620: fix extcon dependency

On Tue, Apr 14, 2020 at 5:05 PM Arnd Bergmann <arnd@...db.de> wrote:
>
> On Fri, Apr 10, 2020 at 8:56 AM Andrzej Hajda <a.hajda@...sung.com> wrote:
> >
> >
> > On 08.04.2020 22:27, Arnd Bergmann wrote:
> > > Using 'imply' does not work here, it still cause the same build
> > > failure:
> > >
> > > arm-linux-gnueabi-ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function `sii8620_remove':
> > > sil-sii8620.c:(.text+0x1b8): undefined reference to `extcon_unregister_notifier'
> > > arm-linux-gnueabi-ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function `sii8620_probe':
> > > sil-sii8620.c:(.text+0x27e8): undefined reference to `extcon_find_edev_by_node'
> > > arm-linux-gnueabi-ld: sil-sii8620.c:(.text+0x2870): undefined reference to `extcon_register_notifier'
> > > arm-linux-gnueabi-ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function `sii8620_extcon_work':
> > > sil-sii8620.c:(.text+0x2908): undefined reference to `extcon_get_state'
> > >
> > > I tried the usual 'depends on EXTCON || !EXTCON' logic, but that caused
> > > a circular Kconfig dependency. Using IS_REACHABLE() is ugly but works.
> >
> > 'depends on EXTCON || !EXTCON' seems to be proper solution, maybe would be better to try to solve circular dependencies issue.
>
> I agree that would be nice, but I failed to come to a proper solution
> here. FWIW, there
> is one circular dependency that I managed to avoid by changing all
> drivers that select FB_DDC
> to depend on I2C rather than selecting it:
>
> drivers/i2c/Kconfig:8:error: recursive dependency detected!
> drivers/i2c/Kconfig:8: symbol I2C is selected by FB_DDC
> drivers/video/fbdev/Kconfig:63: symbol FB_DDC depends on FB
> drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER
> drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
> drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by DRM_SIL_SII8620
> drivers/gpu/drm/bridge/Kconfig:89: symbol DRM_SIL_SII8620 depends on EXTCON
> drivers/extcon/Kconfig:2: symbol EXTCON is selected by CHARGER_MANAGER
> drivers/power/supply/Kconfig:482: symbol CHARGER_MANAGER depends on POWER_SUPPLY
> drivers/power/supply/Kconfig:2: symbol POWER_SUPPLY is selected by
> HID_BATTERY_STRENGTH
> drivers/hid/Kconfig:29: symbol HID_BATTERY_STRENGTH depends on HID
> drivers/hid/Kconfig:8: symbol HID is selected by I2C_HID
> drivers/hid/i2c-hid/Kconfig:5: symbol I2C_HID depends on I2C
>
> After that, Kconfig crashes with a segfault:
>
> drivers/video/fbdev/Kconfig:12:error: recursive dependency detected!
> drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER
> drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
> drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by DRM_SIL_SII8620
> drivers/gpu/drm/bridge/Kconfig:89: symbol DRM_SIL_SII8620 depends on EXTCON
> drivers/extcon/Kconfig:2: symbol EXTCON is selected by CHARGER_MANAGER
> drivers/power/supply/Kconfig:482: symbol CHARGER_MANAGER depends on POWER_SUPPLY
> drivers/power/supply/Kconfig:2: symbol POWER_SUPPLY is selected by HID_ASUS
> drivers/hid/Kconfig:150: symbol HID_ASUS depends on LEDS_CLASS
> drivers/leds/Kconfig:17: symbol LEDS_CLASS depends on NEW_LEDS
> drivers/leds/Kconfig:9: symbol NEW_LEDS is selected by SENSORS_APPLESMC
> drivers/hwmon/Kconfig:327: symbol SENSORS_APPLESMC depends on HWMON
> drivers/hwmon/Kconfig:6: symbol HWMON is selected by EEEPC_LAPTOP
> drivers/platform/x86/Kconfig:260: symbol EEEPC_LAPTOP depends on ACPI_VIDEO
> make[3]: *** [/git/arm-soc/scripts/kconfig/Makefile:71: randconfig]
> Segmentation fault (core dumped)
>
> After changing EEEPC_LAPTOP and THINKPAD_ACPI to 'depends on HWMON' instead of
> 'select HWMON', I get this one:
>
> drivers/video/fbdev/Kconfig:12:error: recursive dependency detected!
> drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER
> drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
> drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by DRM_SIL_SII8620
> drivers/gpu/drm/bridge/Kconfig:89: symbol DRM_SIL_SII8620 depends on EXTCON
> drivers/extcon/Kconfig:2: symbol EXTCON is selected by CHARGER_MANAGER
> drivers/power/supply/Kconfig:482: symbol CHARGER_MANAGER depends on POWER_SUPPLY
> drivers/power/supply/Kconfig:2: symbol POWER_SUPPLY is selected by HID_ASUS
> drivers/hid/Kconfig:150: symbol HID_ASUS depends on LEDS_CLASS
> drivers/leds/Kconfig:17: symbol LEDS_CLASS depends on NEW_LEDS
> drivers/leds/Kconfig:9: symbol NEW_LEDS is selected by BACKLIGHT_ADP8860
> drivers/video/backlight/Kconfig:316: symbol BACKLIGHT_ADP8860 depends
> on BACKLIGHT_CLASS_DEVICE
> drivers/video/backlight/Kconfig:143: symbol BACKLIGHT_CLASS_DEVICE is
> selected by FB_BACKLIGHT
> drivers/video/fbdev/Kconfig:187: symbol FB_BACKLIGHT depends on FB
>
> Changing all drivers that select 'FB_BACKLIGHT' or 'BACKLIGHT_CLASS_DEVICE' to
> 'depends on BACKLIGHT_CLASS_DEVICE' gets it to build.
>
> The steps each seem reasonable, in particular since they mostly clean
> up the legacy
> fbdev drivers to what they should have done anyway, but it is quite
> invasive in the end.
> Any other ideas?

Adding Jani, since iirc he looked at the entire backlight Kconfig
story before. I think there's some nonsense going on where in some
cases you don't get reasonable dummy functions where it just doesn't
make sense. Or something like that.

At least the entire select vs depends on backlight sounds eerily familiar.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Powered by blists - more mailing lists