linux-kernel - [PATCH 17/17] staging: nuc-led: update the TODOs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <f23fed6a89f66564f5af52f241016a4b9823ce04.1621161037.git.mchehab+huawei@kernel.org>
Date:   Sun, 16 May 2021 12:53:45 +0200
From:   Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To:     gregkh@...uxfoundation.org
Cc:     linuxarm@...wei.com, mauro.chehab@...wei.com,
        Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
        "Pavel Machek" <pavel@....cz>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
        linux-leds@...r.kernel.org, linux-staging@...ts.linux.dev
Subject: [PATCH 17/17] staging: nuc-led: update the TODOs

Now that most functionality were merged at the driver,
update its TODO list, and add a "TODO" comment for the two
WMI API commands that are currently not implemented.

In summary:

-  on Rev 0.64, command 0x07 (LED_NOTIFICATION) is meant to store
   all config settings at EEPROM. That doesn't seem to be needed
   on Skull Canyon, but tests with different hardware would be
   nice in order to double-check it. Also, maybe Rev 1.00 would
   make it mandatory;
-  Rev 1.00 added command 0x08 to switch the LED type
   (LED_SWITCH_TYPE at the driver's nomenclature) between
   single color LED and multi color LED). Not sure how this
   should be properly implemented (if this is the case);
-  The tests for NUC6 version were using a Skull Canyon NUC.
   It allowed to check that the driver's logic runs, but
   it is not enough to see if everything is really working.
   Tests on NUC6 or NUC7 are required;
-  On a suspend test, I noticed that some controls were reset
   to the default at resume time. It is required to check
   what's happening there and address it properly.
-  Need to validate the uAPI and document it before moving
   this driver out of staging.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
---
 drivers/staging/nuc-led/TODO      | 12 +++++++-----
 drivers/staging/nuc-led/nuc-wmi.c |  6 ++----
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/nuc-led/TODO b/drivers/staging/nuc-led/TODO
index d5296d7186a7..df6f3f653eb0 100644
--- a/drivers/staging/nuc-led/TODO
+++ b/drivers/staging/nuc-led/TODO
@@ -1,6 +1,8 @@
-- Add support for 6th gen NUCs, like Skull Canyon
-- Improve LED core support to avoid it to try to manage the
-  LED brightness directly;
-- Test it with 8th gen NUCs;
-- Add more functionality to the driver;
+- Test it with 6th gen and 10th NUCs;
+- Add support for LED_NOTIFICATION;
+- Add support for LED_SWITCH_TYPE;
+- Some LED parameters are changing after returning
+  from suspend. Need to check what's happening there
+  (hardware bug?) and ensure that the parameters will
+  be properly restored after resume.
 - Stabilize and document its sysfs interface.
diff --git a/drivers/staging/nuc-led/nuc-wmi.c b/drivers/staging/nuc-led/nuc-wmi.c
index 2d9c49d72703..e87e97d56364 100644
--- a/drivers/staging/nuc-led/nuc-wmi.c
+++ b/drivers/staging/nuc-led/nuc-wmi.c
@@ -42,16 +42,14 @@ enum led_cmds {
 	LED_OLD_SET_LED                 = 0x02,
 
 	/* Rev 0.64 and 1.0 cmds */
-
 	LED_QUERY			= 0x03,
 	LED_NEW_GET_STATUS		= 0x04,
 	LED_SET_INDICATOR		= 0x05,
 	LED_SET_VALUE			= 0x06,
-	LED_NOTIFICATION		= 0x07,
-	LED_SWITCH_TYPE			= 0x08,
+	LED_NOTIFICATION		= 0x07, // TODO: add support for it
 
 	/* Rev 1.0 cmds */
-
+	LED_SWITCH_TYPE			= 0x08, // TODO: add support for it
 	LED_VERSION_CONTROL             = 0x09,
 };
 
-- 
2.31.1