Add support for Intel nuc7jyb / nuc7cjyh2 BIOS > 0047

[elsnorrow]

I've tested out this repo (and the repo from milesp20). As the nuc7jyb (motherboard) / nuc7cjyh2 (NUC itself) is almost identical as the NUC6CA[x]. It doesn't have a RING LED / RGB LED by default but the motherboard is the same and it does have the RGB Connector. I connected my own RGB led to this port which works fine when manually setting the RGB LED color in the BIOS. All prereq's are met:

• BIOS: BIOS Version 0050 - JYGLKCPX.86A.0050.2019.0418.1441

• ACPI/WMI support in kernel

• LED(s) set to SW Control in BIOS

I unfortunately can't downgrade or upgrade further. Upgrading removes the SW control from the bios. And downgrading is not possible because of a CPU microcode update. There is an interesting note in the release notes of BIOS version: BIOS Version 0049 - JYGLKCPX.86A.0049.2019.0401.1038. It states:

Changed RING LED to RGB LED in BIOS Setup to match motherboard silkscreen and Technical Product Specification.

This was released in April 2019 where your repo was updated in February 2019. I suspect this might be the breaking change. Additional info below:

The kernel module loads fine:

[    3.968495] kernel: nuc_led: loading out-of-tree module taints kernel.
[    3.968525] kernel: nuc_led: module verification failed: signature and/or required key missing - tainting kernel
[    3.968702] kernel: nuc_led: Intel NUC LED control driver loaded

However when trying to retrieve the current LED status I receive the following error:

Profile: Current
==================================================
Power state state could not be determined: WMI call returned error

Ring state state could not be determined: WMI call returned error

I've tried to check for the WMI GUID by running sudo fwts wmi - which seems to be matching the GUID set in nuc_led.c:

Command: "fwts wmi -".
Running tests: wmi.

wmi: Extract and analyse Windows Management Instrumentation (WMI).
-------------------------------------------------------------------------------------------------------------------------
FADT X_FIRMWARE_CTRL 64 bit pointer was zero, falling back to using FIRMWARE_CTRL 32 bit pointer.
Test 1 of 1: Windows Management Instrumentation test.

\AMW0._WDG (1 of 2)
  GUID: 8C5DA44C-CDC3-46B3-8619-4E26D34390B7
  WMI Method:
    Flags          : 0x02 (Method)
    Object ID      : AA
    Instance       : 0x01
PASSED: Test 1, 8C5DA44C-CDC3-46B3-8619-4E26D34390B7 has associated method \AMW0.WMAA

\AMW0._WDG (2 of 2)
  GUID: 05901221-D566-11D1-B2F0-00A0C9062910
  WMI Object:
    Flags          : 0x00 (None)
    Object ID      : BA
    Instance       : 0x01

I've also generated a dsdt.dat / dsdt.dsl which seems to be matching as well. I've attached the dsdt.dsl. I've limited knowledge of C / C++ programming which is why I created this issue. Any help is appreciated!
dsdt.dsl.txt

[elsnorrow]

Additionally, if I compare my dsdt file with one that was posted by another user in the repo from milesp20 I see an additional method called Method (ECHN, 3, NotSerialized) is added to my dsdt file.

I searched for the following Methods in the dsdt file:

• Method (WMAA

• Method (SLED

• Method (GLED

And found this difference. This was suggested by milesp20 here. I've attached the dsdt file from that issue here as well.
dsdt.dsl-github.txt

[elsnorrow]

@xptsp do you have any idea? Happy to provide additional info.