| Message ID | 029a1ec5-48ac-a3ce-3106-430e0f2584bb@infradead.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote: > From: Randy Dunlap <rdunlap@infradead.org> > > Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and > CONFIG_DRM_NOUVEAU=y. > If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same > kconfig value as LEDS_CLASS. > > drivers/built-in.o: In function `nouveau_do_suspend': > nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend' > drivers/built-in.o: In function `nouveau_do_resume': > nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume' > drivers/built-in.o: In function `nouveau_drm_unload': > nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini' > drivers/built-in.o: In function `nouveau_drm_load': > nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init' > > BTW, this line in Kbuild: > nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o > does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y. > > Signed-off-by: Randy Dunlap <rdunlap@infradead.org> > Reported-by: kbuild test robot <fengguang.wu@intel.com> > Cc: Martin Peres <martin.peres@free.fr> > Cc: Ben Skeggs <bskeggs@redhat.com> Thrown into drm-misc, thanks. -Daniel > --- > drivers/gpu/drm/nouveau/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > --- lnx-410-rc2.orig/drivers/gpu/drm/nouveau/Kconfig > +++ lnx-410-rc2/drivers/gpu/drm/nouveau/Kconfig > @@ -1,6 +1,7 @@ > config DRM_NOUVEAU > tristate "Nouveau (NVIDIA) cards" > depends on DRM && PCI > + depends on LEDS_CLASS || LEDS_CLASS=n > select FW_LOADER > select DRM_KMS_HELPER > select DRM_TTM > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter <daniel@ffwll.ch> wrote: > On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote: >> From: Randy Dunlap <rdunlap@infradead.org> >> >> Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and >> CONFIG_DRM_NOUVEAU=y. >> If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same >> kconfig value as LEDS_CLASS. >> >> drivers/built-in.o: In function `nouveau_do_suspend': >> nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend' >> drivers/built-in.o: In function `nouveau_do_resume': >> nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume' >> drivers/built-in.o: In function `nouveau_drm_unload': >> nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini' >> drivers/built-in.o: In function `nouveau_drm_load': >> nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init' >> >> BTW, this line in Kbuild: >> nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o >> does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y. >> >> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> >> Reported-by: kbuild test robot <fengguang.wu@intel.com> >> Cc: Martin Peres <martin.peres@free.fr> >> Cc: Ben Skeggs <bskeggs@redhat.com> > > Thrown into drm-misc, thanks. > -Daniel Wasn't there already a different solution from Martin for this, using IS_REACHABLE, instead of adding a dependency in Kconfig? > >> --- >> drivers/gpu/drm/nouveau/Kconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> --- lnx-410-rc2.orig/drivers/gpu/drm/nouveau/Kconfig >> +++ lnx-410-rc2/drivers/gpu/drm/nouveau/Kconfig >> @@ -1,6 +1,7 @@ >> config DRM_NOUVEAU >> tristate "Nouveau (NVIDIA) cards" >> depends on DRM && PCI >> + depends on LEDS_CLASS || LEDS_CLASS=n >> select FW_LOADER >> select DRM_KMS_HELPER >> select DRM_TTM >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, 04 Jan 2017, Daniel Vetter <daniel@ffwll.ch> wrote: > On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote: >> From: Randy Dunlap <rdunlap@infradead.org> >> >> Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and >> CONFIG_DRM_NOUVEAU=y. >> If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same >> kconfig value as LEDS_CLASS. >> >> drivers/built-in.o: In function `nouveau_do_suspend': >> nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend' >> drivers/built-in.o: In function `nouveau_do_resume': >> nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume' >> drivers/built-in.o: In function `nouveau_drm_unload': >> nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini' >> drivers/built-in.o: In function `nouveau_drm_load': >> nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init' >> >> BTW, this line in Kbuild: >> nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o >> does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y. >> >> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> >> Reported-by: kbuild test robot <fengguang.wu@intel.com> >> Cc: Martin Peres <martin.peres@free.fr> >> Cc: Ben Skeggs <bskeggs@redhat.com> > > Thrown into drm-misc, thanks. Randy, this results in the following recursive dependency using the attached config. BR, Jani. drivers/usb/Kconfig:39:error: recursive dependency detected! For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/usb/Kconfig:39: symbol USB is selected by MOUSE_APPLETOUCH For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/input/mouse/Kconfig:187: symbol MOUSE_APPLETOUCH depends on INPUT For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/input/Kconfig:8: symbol INPUT is selected by VT For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/tty/Kconfig:12: symbol VT is selected by FB_STI For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/video/fbdev/Kconfig:678: symbol FB_STI depends on FB For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/Kconfig:72: symbol DRM_KMS_FB_HELPER is selected by DRM_KMS_CMA_HELPER For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/Kconfig:128: symbol DRM_KMS_CMA_HELPER is selected by DRM_HDLCD For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/arm/Kconfig:6: symbol DRM_HDLCD depends on COMMON_CLK For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/clk/Kconfig:9: symbol COMMON_CLK is selected by X86_INTEL_QUARK For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" arch/x86/Kconfig:554: symbol X86_INTEL_QUARK depends on X86_PLATFORM_DEVICES For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/platform/x86/Kconfig:5: symbol X86_PLATFORM_DEVICES is selected by DRM_NOUVEAU For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/nouveau/Kconfig:1: symbol DRM_NOUVEAU depends on LEDS_CLASS For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/leds/Kconfig:16: symbol LEDS_CLASS is selected by ATH9K_HTC For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/net/wireless/ath/ath9k/Kconfig:158: symbol ATH9K_HTC depends on USB warning: (DRM_NOUVEAU && DRM_I915 && DRM_GMA500) selects ACPI_VIDEO which has unmet direct dependencies (ACPI && X86 && BACKLIGHT_CLASS_DEVICE && INPUT) > -Daniel > >> --- >> drivers/gpu/drm/nouveau/Kconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> --- lnx-410-rc2.orig/drivers/gpu/drm/nouveau/Kconfig >> +++ lnx-410-rc2/drivers/gpu/drm/nouveau/Kconfig >> @@ -1,6 +1,7 @@ >> config DRM_NOUVEAU >> tristate "Nouveau (NVIDIA) cards" >> depends on DRM && PCI >> + depends on LEDS_CLASS || LEDS_CLASS=n >> select FW_LOADER >> select DRM_KMS_HELPER >> select DRM_TTM >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 01/04/17 11:29, Jani Nikula wrote: > On Wed, 04 Jan 2017, Daniel Vetter <daniel@ffwll.ch> wrote: >> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote: >>> From: Randy Dunlap <rdunlap@infradead.org> >>> >>> Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and >>> CONFIG_DRM_NOUVEAU=y. >>> If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same >>> kconfig value as LEDS_CLASS. >>> >>> drivers/built-in.o: In function `nouveau_do_suspend': >>> nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend' >>> drivers/built-in.o: In function `nouveau_do_resume': >>> nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume' >>> drivers/built-in.o: In function `nouveau_drm_unload': >>> nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini' >>> drivers/built-in.o: In function `nouveau_drm_load': >>> nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init' >>> >>> BTW, this line in Kbuild: >>> nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o >>> does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y. >>> >>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> >>> Reported-by: kbuild test robot <fengguang.wu@intel.com> >>> Cc: Martin Peres <martin.peres@free.fr> >>> Cc: Ben Skeggs <bskeggs@redhat.com> >> >> Thrown into drm-misc, thanks. > > Randy, this results in the following recursive dependency using the > attached config. > Hi, Please drop the patch for now. If there is an alternative patch, that's good. Otherwise I'll look for a solution. Thanks. > BR, > Jani. > > > drivers/usb/Kconfig:39:error: recursive dependency detected! > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/usb/Kconfig:39: symbol USB is selected by MOUSE_APPLETOUCH > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/input/mouse/Kconfig:187: symbol MOUSE_APPLETOUCH depends on INPUT > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/input/Kconfig:8: symbol INPUT is selected by VT > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/tty/Kconfig:12: symbol VT is selected by FB_STI > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/video/fbdev/Kconfig:678: symbol FB_STI depends on FB > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/gpu/drm/Kconfig:72: symbol DRM_KMS_FB_HELPER is selected by DRM_KMS_CMA_HELPER > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/gpu/drm/Kconfig:128: symbol DRM_KMS_CMA_HELPER is selected by DRM_HDLCD > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/gpu/drm/arm/Kconfig:6: symbol DRM_HDLCD depends on COMMON_CLK > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/clk/Kconfig:9: symbol COMMON_CLK is selected by X86_INTEL_QUARK > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > arch/x86/Kconfig:554: symbol X86_INTEL_QUARK depends on X86_PLATFORM_DEVICES > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/platform/x86/Kconfig:5: symbol X86_PLATFORM_DEVICES is selected by DRM_NOUVEAU > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/gpu/drm/nouveau/Kconfig:1: symbol DRM_NOUVEAU depends on LEDS_CLASS > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/leds/Kconfig:16: symbol LEDS_CLASS is selected by ATH9K_HTC > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/net/wireless/ath/ath9k/Kconfig:158: symbol ATH9K_HTC depends on USB > warning: (DRM_NOUVEAU && DRM_I915 && DRM_GMA500) selects ACPI_VIDEO which has unmet direct dependencies (ACPI && X86 && BACKLIGHT_CLASS_DEVICE && INPUT)
On 01/04/17 06:25, Ilia Mirkin wrote: > On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter <daniel@ffwll.ch> wrote: >> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote: >>> From: Randy Dunlap <rdunlap@infradead.org> >>> >>> Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and >>> CONFIG_DRM_NOUVEAU=y. >>> If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same >>> kconfig value as LEDS_CLASS. >>> >>> drivers/built-in.o: In function `nouveau_do_suspend': >>> nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend' >>> drivers/built-in.o: In function `nouveau_do_resume': >>> nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume' >>> drivers/built-in.o: In function `nouveau_drm_unload': >>> nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini' >>> drivers/built-in.o: In function `nouveau_drm_load': >>> nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init' >>> >>> BTW, this line in Kbuild: >>> nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o >>> does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y. >>> >>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> >>> Reported-by: kbuild test robot <fengguang.wu@intel.com> >>> Cc: Martin Peres <martin.peres@free.fr> >>> Cc: Ben Skeggs <bskeggs@redhat.com> >> >> Thrown into drm-misc, thanks. >> -Daniel > > Wasn't there already a different solution from Martin for this, using > IS_REACHABLE, instead of adding a dependency in Kconfig? nouveau_led.h contains a few lines that are bounded by #if IS_ENABLED(CONFIG_LEDS_CLASS) but that's not sufficient. Is there another patch?
On Wed, Jan 4, 2017 at 9:52 PM, Randy Dunlap <rdunlap@infradead.org> wrote: > On 01/04/17 06:25, Ilia Mirkin wrote: >> On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter <daniel@ffwll.ch> wrote: >>> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote: >>>> From: Randy Dunlap <rdunlap@infradead.org> >>>> >>>> Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and >>>> CONFIG_DRM_NOUVEAU=y. >>>> If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same >>>> kconfig value as LEDS_CLASS. >>>> >>>> drivers/built-in.o: In function `nouveau_do_suspend': >>>> nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend' >>>> drivers/built-in.o: In function `nouveau_do_resume': >>>> nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume' >>>> drivers/built-in.o: In function `nouveau_drm_unload': >>>> nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini' >>>> drivers/built-in.o: In function `nouveau_drm_load': >>>> nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init' >>>> >>>> BTW, this line in Kbuild: >>>> nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o >>>> does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y. >>>> >>>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> >>>> Reported-by: kbuild test robot <fengguang.wu@intel.com> >>>> Cc: Martin Peres <martin.peres@free.fr> >>>> Cc: Ben Skeggs <bskeggs@redhat.com> >>> >>> Thrown into drm-misc, thanks. >>> -Daniel >> >> Wasn't there already a different solution from Martin for this, using >> IS_REACHABLE, instead of adding a dependency in Kconfig? > > nouveau_led.h contains a few lines that are bounded by > #if IS_ENABLED(CONFIG_LEDS_CLASS) > > but that's not sufficient. > > Is there another patch? https://lists.freedesktop.org/archives/nouveau/2016-December/026744.html Not sure why it's not upstream yet. I guess Ben missed it? -ilia
On 01/04/17 19:09, Ilia Mirkin wrote: > On Wed, Jan 4, 2017 at 9:52 PM, Randy Dunlap <rdunlap@infradead.org> wrote: >> On 01/04/17 06:25, Ilia Mirkin wrote: >>> On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter <daniel@ffwll.ch> wrote: >>>> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote: >>>>> From: Randy Dunlap <rdunlap@infradead.org> >>>>> >>>>> Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and >>>>> CONFIG_DRM_NOUVEAU=y. >>>>> If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same >>>>> kconfig value as LEDS_CLASS. >>>>> >>>>> drivers/built-in.o: In function `nouveau_do_suspend': >>>>> nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend' >>>>> drivers/built-in.o: In function `nouveau_do_resume': >>>>> nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume' >>>>> drivers/built-in.o: In function `nouveau_drm_unload': >>>>> nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini' >>>>> drivers/built-in.o: In function `nouveau_drm_load': >>>>> nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init' >>>>> >>>>> BTW, this line in Kbuild: >>>>> nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o >>>>> does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y. >>>>> >>>>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> >>>>> Reported-by: kbuild test robot <fengguang.wu@intel.com> >>>>> Cc: Martin Peres <martin.peres@free.fr> >>>>> Cc: Ben Skeggs <bskeggs@redhat.com> >>>> >>>> Thrown into drm-misc, thanks. >>>> -Daniel >>> >>> Wasn't there already a different solution from Martin for this, using >>> IS_REACHABLE, instead of adding a dependency in Kconfig? >> >> nouveau_led.h contains a few lines that are bounded by >> #if IS_ENABLED(CONFIG_LEDS_CLASS) >> >> but that's not sufficient. >> >> Is there another patch? > > https://lists.freedesktop.org/archives/nouveau/2016-December/026744.html > > Not sure why it's not upstream yet. I guess Ben missed it? Ok, if you all are OK with a slightly crippled driver.
On Wed, Jan 4, 2017 at 10:17 PM, Randy Dunlap <rdunlap@infradead.org> wrote: > On 01/04/17 19:09, Ilia Mirkin wrote: >> On Wed, Jan 4, 2017 at 9:52 PM, Randy Dunlap <rdunlap@infradead.org> wrote: >>> On 01/04/17 06:25, Ilia Mirkin wrote: >>>> On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter <daniel@ffwll.ch> wrote: >>>>> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote: >>>>>> From: Randy Dunlap <rdunlap@infradead.org> >>>>>> >>>>>> Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and >>>>>> CONFIG_DRM_NOUVEAU=y. >>>>>> If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same >>>>>> kconfig value as LEDS_CLASS. >>>>>> >>>>>> drivers/built-in.o: In function `nouveau_do_suspend': >>>>>> nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend' >>>>>> drivers/built-in.o: In function `nouveau_do_resume': >>>>>> nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume' >>>>>> drivers/built-in.o: In function `nouveau_drm_unload': >>>>>> nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini' >>>>>> drivers/built-in.o: In function `nouveau_drm_load': >>>>>> nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init' >>>>>> >>>>>> BTW, this line in Kbuild: >>>>>> nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o >>>>>> does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y. >>>>>> >>>>>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> >>>>>> Reported-by: kbuild test robot <fengguang.wu@intel.com> >>>>>> Cc: Martin Peres <martin.peres@free.fr> >>>>>> Cc: Ben Skeggs <bskeggs@redhat.com> >>>>> >>>>> Thrown into drm-misc, thanks. >>>>> -Daniel >>>> >>>> Wasn't there already a different solution from Martin for this, using >>>> IS_REACHABLE, instead of adding a dependency in Kconfig? >>> >>> nouveau_led.h contains a few lines that are bounded by >>> #if IS_ENABLED(CONFIG_LEDS_CLASS) >>> >>> but that's not sufficient. >>> >>> Is there another patch? >> >> https://lists.freedesktop.org/archives/nouveau/2016-December/026744.html >> >> Not sure why it's not upstream yet. I guess Ben missed it? > > Ok, if you all are OK with a slightly crippled driver. The LED functionality is to allow adjusting the light inside the case of the high-end GTX TITAN boards. I think people will be fine with that level of crippled for when they build nouveau in and the leds class as a module. -ilia
On Wed, Jan 04, 2017 at 02:24:51PM -0800, Randy Dunlap wrote: > On 01/04/17 11:29, Jani Nikula wrote: > > On Wed, 04 Jan 2017, Daniel Vetter <daniel@ffwll.ch> wrote: > >> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote: > >>> From: Randy Dunlap <rdunlap@infradead.org> > >>> > >>> Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and > >>> CONFIG_DRM_NOUVEAU=y. > >>> If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same > >>> kconfig value as LEDS_CLASS. > >>> > >>> drivers/built-in.o: In function `nouveau_do_suspend': > >>> nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend' > >>> drivers/built-in.o: In function `nouveau_do_resume': > >>> nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume' > >>> drivers/built-in.o: In function `nouveau_drm_unload': > >>> nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini' > >>> drivers/built-in.o: In function `nouveau_drm_load': > >>> nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init' > >>> > >>> BTW, this line in Kbuild: > >>> nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o > >>> does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y. > >>> > >>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> > >>> Reported-by: kbuild test robot <fengguang.wu@intel.com> > >>> Cc: Martin Peres <martin.peres@free.fr> > >>> Cc: Ben Skeggs <bskeggs@redhat.com> > >> > >> Thrown into drm-misc, thanks. > > > > Randy, this results in the following recursive dependency using the > > attached config. > > > > Hi, > Please drop the patch for now. If there is an alternative patch, > that's good. Otherwise I'll look for a solution. Ok, pushed a revert. I guess I'll stop touching Kconfig stuff again for the next few months ;-) -Daniel
On 01/05/17 00:01, Daniel Vetter wrote: > On Wed, Jan 04, 2017 at 02:24:51PM -0800, Randy Dunlap wrote: >> On 01/04/17 11:29, Jani Nikula wrote: >>> On Wed, 04 Jan 2017, Daniel Vetter <daniel@ffwll.ch> wrote: >>>> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote: >>>>> From: Randy Dunlap <rdunlap@infradead.org> >>>>> >>>>> Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and >>>>> CONFIG_DRM_NOUVEAU=y. >>>>> If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same >>>>> kconfig value as LEDS_CLASS. >>>>> >>>>> drivers/built-in.o: In function `nouveau_do_suspend': >>>>> nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend' >>>>> drivers/built-in.o: In function `nouveau_do_resume': >>>>> nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume' >>>>> drivers/built-in.o: In function `nouveau_drm_unload': >>>>> nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini' >>>>> drivers/built-in.o: In function `nouveau_drm_load': >>>>> nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init' >>>>> >>>>> BTW, this line in Kbuild: >>>>> nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o >>>>> does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y. >>>>> >>>>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> >>>>> Reported-by: kbuild test robot <fengguang.wu@intel.com> >>>>> Cc: Martin Peres <martin.peres@free.fr> >>>>> Cc: Ben Skeggs <bskeggs@redhat.com> >>>> >>>> Thrown into drm-misc, thanks. >>> >>> Randy, this results in the following recursive dependency using the >>> attached config. >>> >> >> Hi, >> Please drop the patch for now. If there is an alternative patch, >> that's good. Otherwise I'll look for a solution. > > Ok, pushed a revert. I guess I'll stop touching Kconfig stuff again for > the next few months ;-) :) That particular circular/recursive dependency is ugly. I spent about one hour trying/testing various fixes and don't have one.
On Thu, 05 Jan 2017, Randy Dunlap <rdunlap@infradead.org> wrote: > That particular circular/recursive dependency is ugly. I spent about > one hour trying/testing various fixes and don't have one. I didn't really look at this one all that much, but when I face problems with kconfig, it's almost invariably because of overuse of select. Documentation/kbuild/kconfig-language.txt says, "In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies." People violate this all the time because it's convenient. If they depended, they'd have to enable all deps to even see their config. I wish kconfig would warn about incorrect use of select... though I guess that would produce a wall of warnings. Additionally, it really should be easier to find and enable unmet dependencies in menuconfig. Someone(tm) has a lot of work to do... BR, Jani.
--- lnx-410-rc2.orig/drivers/gpu/drm/nouveau/Kconfig +++ lnx-410-rc2/drivers/gpu/drm/nouveau/Kconfig @@ -1,6 +1,7 @@ config DRM_NOUVEAU tristate "Nouveau (NVIDIA) cards" depends on DRM && PCI + depends on LEDS_CLASS || LEDS_CLASS=n select FW_LOADER select DRM_KMS_HELPER select DRM_TTM