lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 14 Apr 2020 17:04:47 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Andrzej Hajda <a.hajda@...sung.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Nicolas Pitre <nico@...xnic.net>,
        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>,
        Neil Armstrong <narmstrong@...libre.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        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 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?

       Arnd

Powered by blists - more mailing lists