From 12ec7e56ce95d7b6fd4cd74e634c1181e2b424e1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Beh=C3=BAn?= Date: Mon, 19 Oct 2020 13:08:08 +0200 Subject: Documentation: leds: remove invalidated information MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The contents of the Future Development section of leds-class Documentation was invalidated when support for LED-private triggers was merged. Remove this section. Signed-off-by: Marek Behún Fixes: 93690cdf3060 ("leds: trigger: add support for LED-private device...") Signed-off-by: Pavel Machek --- Documentation/leds/leds-class.rst | 10 ---------- 1 file changed, 10 deletions(-) (limited to 'Documentation/leds') diff --git a/Documentation/leds/leds-class.rst b/Documentation/leds/leds-class.rst index a0708d3f3d0b..cd155ead8703 100644 --- a/Documentation/leds/leds-class.rst +++ b/Documentation/leds/leds-class.rst @@ -177,13 +177,3 @@ The LED Trigger core cannot be a module as the simple trigger functions would cause nightmare dependency issues. I see this as a minor issue compared to the benefits the simple trigger functionality brings. The rest of the LED subsystem can be modular. - - -Future Development -================== - -At the moment, a trigger can't be created specifically for a single LED. -There are a number of cases where a trigger might only be mappable to a -particular LED (ACPI?). The addition of triggers provided by the LED driver -should cover this option and be possible to add without breaking the -current interface. -- cgit v1.2.3