On Tue, Jul 02, 2019 at 03:50:49PM +0200, Andrzej Hajda wrote: > On 19.04.2019 10:19, Ronald Tschalär wrote: > > commit d6abe6df706c (drm/bridge: sil_sii8620: do not have a dependency > > of RC_CORE) changed the driver to select both RC_CORE and INPUT. > > However, this causes problems with other drivers, in particular an input > > driver that depends on MFD_INTEL_LPSS_PCI (to be added in a separate > > commit): > > > > drivers/clk/Kconfig:9:error: recursive dependency detected! > > drivers/clk/Kconfig:9: symbol COMMON_CLK is selected by MFD_INTEL_LPSS > > drivers/mfd/Kconfig:566: symbol MFD_INTEL_LPSS is selected by MFD_INTEL_LPSS_PCI > > drivers/mfd/Kconfig:580: symbol MFD_INTEL_LPSS_PCI is implied by KEYBOARD_APPLESPI > > drivers/input/keyboard/Kconfig:73: symbol KEYBOARD_APPLESPI depends on INPUT > > drivers/input/Kconfig:8: symbol INPUT is selected by DRM_SIL_SII8620 > > drivers/gpu/drm/bridge/Kconfig:83: symbol DRM_SIL_SII8620 depends on DRM_BRIDGE > > drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by DRM_PL111 > > drivers/gpu/drm/pl111/Kconfig:1: symbol DRM_PL111 depends on COMMON_CLK > > > > According to the docs and general consensus, select should only be used > > for non user-visible symbols, but both RC_CORE and INPUT are > > user-visible. Furthermore almost all other references to INPUT > > throughout the kernel config are depends, not selects. For this reason > > the first part of this change reverts commit d6abe6df706c. > > > > In order to address the original reason for commit d6abe6df706c, namely > > that not all boards use the remote controller functionality and hence > > should not need have to deal with RC_CORE, the second part of this > > change now makes the remote control support in the driver optional and > > contingent on RC_CORE being defined. And with this the hard dependency > > on INPUT also goes away as that is only needed if RC_CORE is defined > > (which in turn already depends on INPUT). > > > > CC: Inki Dae <inki.dae@xxxxxxxxxxx> > > CC: Andrzej Hajda <a.hajda@xxxxxxxxxxx> > > CC: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> > > CC: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> > > Signed-off-by: Ronald Tschalär <ronald@xxxxxxxxxxxxx> > > Reviewed-by: Andrzej Hajda <a.hajda@xxxxxxxxxxx> > > > Apparently this patch was not queued to kernel yet. If there are no > objections I will queue it via drm-misc-next tree tomorrow. If this patch set won't be queued for 5.3 then I guess that would be a good idea. But may I ask what is preventing this patch set from being queued for upstream, so I can try and fix whatever the issue is? Cheers, Ronald _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel