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

2017-01-09 Thread Jani Nikula
On Thu, 05 Jan 2017, Randy Dunlap  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


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

2017-01-05 Thread Daniel Vetter
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  wrote:
> >> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote:
> >>> From: Randy Dunlap 
> >>>
> >>> 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 
> >>> Reported-by: kbuild test robot 
> >>> Cc: Martin Peres 
> >>> Cc: Ben Skeggs 
> >>
> >> 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


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

2017-01-05 Thread Randy Dunlap
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  wrote:
 On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote:
> From: Randy Dunlap 
>
> 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 
> Reported-by: kbuild test robot 
> Cc: Martin Peres 
> Cc: Ben Skeggs 

 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


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

2017-01-04 Thread Ilia Mirkin
On Wed, Jan 4, 2017 at 10:17 PM, Randy Dunlap  wrote:
> On 01/04/17 19:09, Ilia Mirkin wrote:
>> On Wed, Jan 4, 2017 at 9:52 PM, Randy Dunlap  
>> wrote:
>>> On 01/04/17 06:25, Ilia Mirkin wrote:
 On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter  wrote:
> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote:
>> From: Randy Dunlap 
>>
>> 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 
>> Reported-by: kbuild test robot 
>> Cc: Martin Peres 
>> Cc: Ben Skeggs 
>
> 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


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

2017-01-04 Thread Ilia Mirkin
On Wed, Jan 4, 2017 at 9:52 PM, Randy Dunlap  wrote:
> On 01/04/17 06:25, Ilia Mirkin wrote:
>> On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter  wrote:
>>> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote:
 From: Randy Dunlap 

 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 
 Reported-by: kbuild test robot 
 Cc: Martin Peres 
 Cc: Ben Skeggs 
>>>
>>> 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


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

2017-01-04 Thread Jani Nikula
On Wed, 04 Jan 2017, Daniel Vetter  wrote:
> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote:
>> From: Randy Dunlap 
>> 
>> 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 
>> Reported-by: kbuild test robot 
>> Cc: Martin Peres 
>> Cc: Ben Skeggs 
>
> 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 at 

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

2017-01-04 Thread Randy Dunlap
On 01/04/17 19:09, Ilia Mirkin wrote:
> On Wed, Jan 4, 2017 at 9:52 PM, Randy Dunlap  wrote:
>> On 01/04/17 06:25, Ilia Mirkin wrote:
>>> On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter  wrote:
 On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote:
> From: Randy Dunlap 
>
> 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 
> Reported-by: kbuild test robot 
> Cc: Martin Peres 
> Cc: Ben Skeggs 

 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


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

2017-01-04 Thread Randy Dunlap
On 01/04/17 06:25, Ilia Mirkin wrote:
> On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter  wrote:
>> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote:
>>> From: Randy Dunlap 
>>>
>>> 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 
>>> Reported-by: kbuild test robot 
>>> Cc: Martin Peres 
>>> Cc: Ben Skeggs 
>>
>> 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


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

2017-01-04 Thread Randy Dunlap
On 01/04/17 11:29, Jani Nikula wrote:
> On Wed, 04 Jan 2017, Daniel Vetter  wrote:
>> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote:
>>> From: Randy Dunlap 
>>>
>>> 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 
>>> Reported-by: kbuild test robot 
>>> Cc: Martin Peres 
>>> Cc: Ben Skeggs 
>>
>> 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


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

2017-01-04 Thread Daniel Vetter
On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote:
> From: Randy Dunlap 
> 
> 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 
> Reported-by: kbuild test robot 
> Cc: Martin Peres 
> Cc: Ben Skeggs 

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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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


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

2017-01-04 Thread Ilia Mirkin
On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter  wrote:
> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote:
>> From: Randy Dunlap 
>>
>> 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 
>> Reported-by: kbuild test robot 
>> Cc: Martin Peres 
>> Cc: Ben Skeggs 
>
> 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 at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

2017-01-01 Thread Randy Dunlap
From: Randy Dunlap 

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 
Reported-by: kbuild test robot 
Cc: Martin Peres 
Cc: Ben Skeggs 
---
 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