similar to: [PATCH] drm/nouveau: fix LEDS_CLASS=m configuration

On Tuesday, November 8, 2016 10:46:07 AM CET Ilia Mirkin wrote: > > diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig > > index 78631fb61adf..715cd6f4dc31 100644 > > --- a/drivers/gpu/drm/nouveau/Kconfig > > +++ b/drivers/gpu/drm/nouveau/Kconfig > > @@ -46,6 +46,14 @@ config NOUVEAU_DEBUG > > The paranoia and spam levels

This fixes the auto-magic detection of LEDS_CLASS by fixing the case where nouveau would be built-in and the LEDS_CLASS would be built as as module. Cc: <stable at vger.kernel.org> # 4.9.x- Reported-by: Intel's 0-DAY Signed-off-by: Martin Peres <martin.peres at free.fr> --- drivers/gpu/drm/nouveau/Kbuild | 2 +- drivers/gpu/drm/nouveau/Kconfig | 9 +++++++++ 2 files changed, 10

On Tue, Nov 8, 2016 at 8:56 AM, Arnd Bergmann <arnd at arndb.de> wrote: > The newly introduced LED handling for nouveau fails to link when the > driver is built-in but the LED subsystem is a loadable module: > > drivers/gpu/drm/nouveau/nouveau.o: In function `nouveau_do_suspend': > tvnv17.c:(.text.nouveau_do_suspend+0x10): undefined reference to `nouveau_led_suspend'

On Tuesday, November 8, 2016 5:07:01 PM CET Lukas Wunner wrote: > On Tue, Nov 08, 2016 at 04:52:49PM +0100, Arnd Bergmann wrote: > > The underlying problem is that we already have a number of other > > symbols that either have "depends on LEDS_CLASS" or > > "select LEDS_CLASS". To clean that up properly, we should either > > make the symbol itself

We received a donation of a Titan which has this useless feature allowing users to control the brightness of the LED behind the logo of NVIDIA. In the true spirit of open source, let's expose that to the users of very expensive cards! This patch hooks up this LED/PWM to the LED subsystem which allows blinking it in sync with cpu/disk/network/whatever activity (heartbeat is quite nice!). Users

From: Karol Herbst <karolherbst at gmail.com> Fixes a kernel crash on suspend/resume. --- drm/nouveau/nouveau_led.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drm/nouveau/nouveau_led.c b/drm/nouveau/nouveau_led.c index 9eed5a6..5e28b5f 100644 --- a/drm/nouveau/nouveau_led.c +++ b/drm/nouveau/nouveau_led.c @@ -107,7 +107,8 @@ nouveau_led_suspend(struct

2016-11-08 17:12 GMT+01:00 Arnd Bergmann <arnd at arndb.de>: > On Tuesday, November 8, 2016 5:07:01 PM CET Lukas Wunner wrote: >> On Tue, Nov 08, 2016 at 04:52:49PM +0100, Arnd Bergmann wrote: >> > The underlying problem is that we already have a number of other >> > symbols that either have "depends on LEDS_CLASS" or >> > "select

Reviewed-by: Karol Herbst <karolherbst at gmail.com> 2016-09-16 9:34 GMT+02:00 Martin Peres <martin.peres at free.fr>: > Signed-off-by: Martin Peres <martin.peres at free.fr> > --- > drm/nouveau/nouveau_led.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drm/nouveau/nouveau_led.c b/drm/nouveau/nouveau_led.c > index

On 23/08/16 11:31, Karol Herbst wrote: > maybe it makes sense to expose the SLI LED, too. > > Regardless of my comments this patch is reviewed-by me. You reviewed the wrong patch, I should have named the re-send v3. I accidentally sent the v1 patch as a v2 :s > > 2016-08-23 1:39 GMT+02:00 Martin Peres <martin.peres at free.fr>: >> We received a donation of a Titan

The proper fix would have been to select LEDS_CLASS but this can lead to a circular dependency, as found out by Arnd. This patch implements Arnd's suggestion instead, at the cost of some auto-magic for a fringe feature. Cc: <stable at vger.kernel.org> # 4.9.x- Reported-by: Arnd Bergmann <arnd at arndb.de> Reported-by: Intel's 0-DAY Fixes: 8d021d71b324

looks good, just a minor thing: You need to check for CONFIG_LEDS_CLASS, otherwise the compile throws out "warnings": WARNING: "led_classdev_register" [/home/karol/Dokumente/repos/nouveau/drm/nouveau/nouveau.ko] undefined! WARNING: "led_classdev_resume" [/home/karol/Dokumente/repos/nouveau/drm/nouveau/nouveau.ko] undefined! WARNING:

If CONFIG_DRM_NOUVEAU=y and CONFIG_LEDS_CLASS=m, then nouveau_led.o is neither stubbed out nor compiled in and the compile fails with undefined symbols in nouveau_drm.c. I'm guessing it's commit 8d021d71b324. (Thanks for the cool hack, BTW, even if I don't have such a card and am complaining about the patch.) Worked around by setting CONFIG_NEW_LEDS=n (it had been forced on by

Hi everyone, It took me a while to figure this out properly, as I kept getting circular or missing dependencies with video drivers. This set of three patches should simplify the situation a bit, mostly by cleaning up the dependencies around CONFIG_ACPI_VIDEO. With all three patches applied, I no longer run into those related warnings. If everyone agrees on the general direction, I hope we can

v2: - guard LED framework calls with ifdef CONFIG_LEDS_CLASS Signed-off-by: Martin Peres <martin.peres at free.fr> --- For real this time! Sorry for the noise drm/nouveau/Kbuild | 1 + drm/nouveau/include/nvkm/subdev/bios/gpio.h | 1 + drm/nouveau/nouveau_drm.c | 7 ++ drm/nouveau/nouveau_drv.h | 3 +

On Tue, May 3, 2016 at 7:51 PM, Martin Peres <martin.peres at free.fr> wrote: > We received a donation of a Titan which has this useless feature > allowing users to control the brightness of the LED behind the > logo of NVIDIA. In the true spirit of open source, let's expose > that to the users of very expensive cards! > > This patch hooks up this LED/PWM to the LED

maybe it makes sense to expose the SLI LED, too. Regardless of my comments this patch is reviewed-by me. 2016-08-23 1:39 GMT+02:00 Martin Peres <martin.peres at free.fr>: > We received a donation of a Titan which has this useless feature > allowing users to control the brightness of the LED behind the > logo of NVIDIA. In the true spirit of open source, let's expose > that

Signed-off-by: Martin Peres <martin.peres at free.fr> --- drm/nouveau/nouveau_led.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drm/nouveau/nouveau_led.c b/drm/nouveau/nouveau_led.c index 5e28b5f..1f731da 100644 --- a/drm/nouveau/nouveau_led.c +++ b/drm/nouveau/nouveau_led.c @@ -44,7 +44,10 @@ nouveau_led_get_brightness(struct led_classdev *led) div =

Signed-off-by: Martin Peres <martin.peres at free.fr> --- drm/nouveau/nouveau_led.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drm/nouveau/nouveau_led.c b/drm/nouveau/nouveau_led.c index 1f731da..3e2f1b6 100644 --- a/drm/nouveau/nouveau_led.c +++ b/drm/nouveau/nouveau_led.c @@ -82,6 +82,9 @@ nouveau_led_init(struct drm_device *dev) struct dcb_gpio_func logo_led; int ret; +

On 16/09/16 10:42, Karol Herbst wrote: > Reviewed-by: Karol Herbst <karolherbst at gmail.com> > > 2016-09-16 9:34 GMT+02:00 Martin Peres <martin.peres at free.fr>: >> Signed-off-by: Martin Peres <martin.peres at free.fr> >> --- >> drm/nouveau/nouveau_led.c | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git

If the led class registration fails, we free drm->led but do not reset it to NULL, which means that the suspend/resume/fini function will act as if everything went well in init() and will likely crash the kernel. This patch adds the missing drm->led = NULL. Reported-by: Emmanuel Pescosta <emmanuelpescosta099 at gmail.com> Signed-off-by: Martin Peres <martin.peres at free.fr>