search for: leds_class

...t; > The paranoia and spam levels will add a lot of extra checks which > > may potentially slow down driver operation. > > > > +config DRM_NOUVEAU_LED > > + bool "Support for logo LED" > > + depends on DRM_NOUVEAU && LEDS_CLASS > > + depends on !(DRM_NOUVEAU=y && LEDS_CLASS=m) > > + help > > + Say Y here to enabling controlling the brightness of the > > + LED behind NVIDIA logo on certain Titan cards. > > This is a very odd restriction... could this be wri...

...ndex fde6e3656636..5e00e911daa6 100644 --- a/drivers/gpu/drm/nouveau/Kbuild +++ b/drivers/gpu/drm/nouveau/Kbuild @@ -22,7 +22,7 @@ nouveau-$(CONFIG_DEBUG_FS) += nouveau_debugfs.o nouveau-y += nouveau_drm.o nouveau-y += nouveau_hwmon.o nouveau-$(CONFIG_COMPAT) += nouveau_ioc32.o -nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o +nouveau-$(CONFIG_DRM_NOUVEAU_LED) += nouveau_led.o nouveau-y += nouveau_nvif.o nouveau-$(CONFIG_NOUVEAU_PLATFORM_DRIVER) += nouveau_platform.o nouveau-y += nouveau_usif.o # userspace <-> nvif diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig...

...644 > --- a/drivers/gpu/drm/nouveau/Kbuild > +++ b/drivers/gpu/drm/nouveau/Kbuild > @@ -22,7 +22,7 @@ nouveau-$(CONFIG_DEBUG_FS) += nouveau_debugfs.o > nouveau-y += nouveau_drm.o > nouveau-y += nouveau_hwmon.o > nouveau-$(CONFIG_COMPAT) += nouveau_ioc32.o > -nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o > +nouveau-$(CONFIG_DRM_NOUVEAU_LED) += nouveau_led.o > nouveau-y += nouveau_nvif.o > nouveau-$(CONFIG_NOUVEAU_PLATFORM_DRIVER) += nouveau_platform.o > nouveau-y += nouveau_usif.o # userspace <-> nvif > diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers...

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 hidden and only select it from other drivers, > > or use "depends on LEDS_CLASS" everywhere. > > > > Another option is to use the IS_REACHABLE(...

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 hidden and only select it from other drivers, > or use "depends on LEDS_CLASS" everywhere. > > Another option is to use the IS_REACHABLE() macro instead of IS_ENA...

...t;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 LEDS_CLASS". To clean that up properly, we should either >> > make the symbol itself hidden and only select it from other drivers, >> > or use "depends on LEDS_CLASS" everywhere. >> > >> > Another option is to us...

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/...

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...

...b/drivers/platform/x86/Kconfig index e0ca673bf564..2d9fb46a8d11 100644 --- a/drivers/platform/x86/Kconfig +++ b/drivers/platform/x86/Kconfig @@ -17,7 +17,7 @@ if X86_PLATFORM_DEVICES config ACER_WMI tristate "Acer WMI Laptop Extras" - depends on ACPI + depends on ACPI_VIDEO select LEDS_CLASS select NEW_LEDS depends on BACKLIGHT_CLASS_DEVICE @@ -26,8 +26,6 @@ config ACER_WMI depends on RFKILL || RFKILL = n depends on ACPI_WMI select INPUT_SPARSEKMAP - # Acer WMI depends on ACPI_VIDEO when ACPI is enabled - select ACPI_VIDEO if ACPI ---help--- This is a driver for...

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: &quot...

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

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