Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1550520 > unrolled thread

Re: [PATCH] drm: nouveau: fix build when LEDS_CLASS=m

Started byDaniel Vetter <daniel@ffwll.ch>
First post2017-01-04 09:50 +0100
Last post2017-01-09 12:00 +0100
Articles 10 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] drm: nouveau: fix build when LEDS_CLASS=m Daniel Vetter <daniel@ffwll.ch> - 2017-01-04 09:50 +0100
    Re: [PATCH] drm: nouveau: fix build when LEDS_CLASS=m Ilia Mirkin <imirkin@alum.mit.edu> - 2017-01-04 15:30 +0100
      Re: [PATCH] drm: nouveau: fix build when LEDS_CLASS=m Randy Dunlap <rdunlap@infradead.org> - 2017-01-05 04:00 +0100
        Re: [PATCH] drm: nouveau: fix build when LEDS_CLASS=m Randy Dunlap <rdunlap@infradead.org> - 2017-01-05 04:20 +0100
          Re: [PATCH] drm: nouveau: fix build when LEDS_CLASS=m Ilia Mirkin <imirkin@alum.mit.edu> - 2017-01-05 04:30 +0100
        Re: [PATCH] drm: nouveau: fix build when LEDS_CLASS=m Ilia Mirkin <imirkin@alum.mit.edu> - 2017-01-05 04:20 +0100
    Re: [PATCH] drm: nouveau: fix build when LEDS_CLASS=m Randy Dunlap <rdunlap@infradead.org> - 2017-01-04 23:30 +0100
      Re: [PATCH] drm: nouveau: fix build when LEDS_CLASS=m Daniel Vetter <daniel@ffwll.ch> - 2017-01-05 09:10 +0100
        Re: [PATCH] drm: nouveau: fix build when LEDS_CLASS=m Randy Dunlap <rdunlap@infradead.org> - 2017-01-05 17:10 +0100
          Re: [PATCH] drm: nouveau: fix build when LEDS_CLASS=m Jani Nikula <jani.nikula@linux.intel.com> - 2017-01-09 12:00 +0100

#1550520 — Re: [PATCH] drm: nouveau: fix build when LEDS_CLASS=m

FromDaniel Vetter <daniel@ffwll.ch>
Date2017-01-04 09:50 +0100
SubjectRe: [PATCH] drm: nouveau: fix build when LEDS_CLASS=m
Message-ID<sVPqF-2eb-1@gated-at.bofh.it>
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

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [next] | [standalone]

#1550861

FromIlia Mirkin <imirkin@alum.mit.edu>
Date2017-01-04 15:30 +0100
Message-ID<sVUJI-5S7-21@gated-at.bofh.it>
In reply to#1550520
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

[toc] | [prev] | [next] | [standalone]

#1551588

FromRandy Dunlap <rdunlap@infradead.org>
Date2017-01-05 04:00 +0100
Message-ID<sW6rv-50I-1@gated-at.bofh.it>
In reply to#1550861
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?

-- 
~Randy

[toc] | [prev] | [next] | [standalone]

#1551589

FromRandy Dunlap <rdunlap@infradead.org>
Date2017-01-05 04:20 +0100
Message-ID<sW6KS-5uA-7@gated-at.bofh.it>
In reply to#1551588
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.


-- 
~Randy

[toc] | [prev] | [next] | [standalone]

#1551592

FromIlia Mirkin <imirkin@alum.mit.edu>
Date2017-01-05 04:30 +0100
Message-ID<sW6Uy-5xP-17@gated-at.bofh.it>
In reply to#1551589
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

[toc] | [prev] | [next] | [standalone]

#1551590

FromIlia Mirkin <imirkin@alum.mit.edu>
Date2017-01-05 04:20 +0100
Message-ID<sW6KS-5uA-5@gated-at.bofh.it>
In reply to#1551588
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

[toc] | [prev] | [next] | [standalone]

#1551450

FromRandy Dunlap <rdunlap@infradead.org>
Date2017-01-04 23:30 +0100
Message-ID<sW2ee-2r4-35@gated-at.bofh.it>
In reply to#1550520
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)


-- 
~Randy

[toc] | [prev] | [next] | [standalone]

#1551725

FromDaniel Vetter <daniel@ffwll.ch>
Date2017-01-05 09:10 +0100
Message-ID<sWbhw-76-17@gated-at.bofh.it>
In reply to#1551450
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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1552088

FromRandy Dunlap <rdunlap@infradead.org>
Date2017-01-05 17:10 +0100
Message-ID<sWiM1-5ja-27@gated-at.bofh.it>
In reply to#1551725
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.

-- 
~Randy

[toc] | [prev] | [next] | [standalone]

#1554214

FromJani Nikula <jani.nikula@linux.intel.com>
Date2017-01-09 12:00 +0100
Message-ID<sXFQe-37h-11@gated-at.bofh.it>
In reply to#1552088
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.



-- 
Jani Nikula, Intel Open Source Technology Center

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web