Support for FS67xx series (FS6712X and probably FS6706T)

[romracer]

This adds support for the FS6712X and probably the FS6706T since its the same unit with less PCIe switches and muxes. All of the LEDs have been tested on my unit as well as the single power button.

This unit doesn't have a front panel, but there are some LEDs on the side next to the power button that can be toggled and I treated the same. The blue:power LED also controls a red LED inside the power button; I couldn't find a way to separate these through GPIO lines.

I moved the asustor_6700_gpio_leds_lookup struct in the code so the order is consistently fs6700, 6700, 6100, 600. This is just a consistency thing; its otherwise unchanged.

For DMI system matching, I added the BIOS release date from my FS6712X. This is probably the only questionable change because I only have this one unit, so I can't see how this BIOS date compares to another Jasper Lake ASUSTOR. I've attached the DMI data from my system if someone wants to compare with other Jasper Lake ASUSTOR systems to see if BIOS date is a suitable differentiator.

dmi.txt

The pr_info call (module loading text) has been adjusted to print the third DMI match parameter, if it exists.

I tried to make notes in comments a little more consistent as well as a variable initialization statement. Minor consistency stuff again, no actual content changes.

Lastly, these units are all NVMe devices, and the default Linux kernel doesn't have a LED trigger for NVMe activity. disk-activity doesn't work for PCIe devices and the Linux kernel maintainers can't decide on the right approach. Again, we have to hope for ledtrig-blk or something here, but the disk activity LED could be used for other purposes in the meantime. So, I created NVME* macros that default the LEDs to off and no disk-activity trigger, and used these for the fs6700 series.

Summary by GitHub Copilot

This pull request introduces support for the FS6706T and FS6712X models, adds NVMe LED definitions, and refactors the GPIO lookup tables for better organization and clarity. The most important changes include updates to the README file, new LED definitions, and modifications to the GPIO lookup tables and driver data structures.

Model Support Updates:

• README.md: Added FS6706T (not tested) and FS6712X to the list of supported models.

LED Definitions:

• asustor.c: Added new NVMe activity and error LED definitions (NVME_ACT_LED and NVME_ERR_LED).
• asustor.c: Included NVMe LED entries in the asustor_leds array.

GPIO Lookup Tables:

• asustor.c: Added new GPIO lookup tables for FS6700 and 6700 models, organizing LED and key mappings. [1] [2]
• asustor.c: Removed the old GPIO lookup table for the 6700 model to avoid duplication and improve clarity.

Driver Data Structures:

• asustor.c: Added driver data for the FS6700 model, linking it to the new GPIO lookup tables.
• asustor.c: Updated the asustor_init function to print additional information and reformat existing code for readability. [1] [2] [3]

[romracer]

Oh, and pwm3 controls the brightness of all LEDs as a group.

[romracer]

@mafredri sorry for the ping, but is there anything I can do to help with this PR. I'll admit C nor kernel modules are my forte so any constructive criticism is welcome 😀

[mafredri]

@romracer this is great, thanks for the effort you put into this! I don't mind the ping (tbh I need a better system for dealing with my GH notifications 😅), thanks for reminding me. I'll try to have a look at this during this week.

Regarding the DMI match, I do believe ASUSTOR updates BIOSes every now-and-a-then, so maybe not the best match criteria, but I can't think of anything better at the moment (really wish ASUSTOR were more thorough with this info..).

[romracer]

Regarding BIOS dates, I don't run ADM on my unit, but I had noticed there was an app for Jasper Lake BIOS updates available on the ASUSTOR website. I downloaded it and poked around and noticed something like BIOS versions 1.16, 1.17 and 1.18 (or something, numbers might be slightly off).

The BIOS version in my DMI info is 1.23, but at the time, I didn't know if that was just someone hitting "123" on the keyboard, or had any sort of relevance. Once I saw those older version numbers in the BIOS update, I thought perhaps v1.23 is actually an incremented number, and not just "123" with a v and period.

Long story short, perhaps BIOS version could be used in place of BIOS date (if warranted). But I also agree, sure would be nice if they just populated the other fields a bit more thoroughly.

[vishalp]

Thanks for working on this. If it helps, I can confirm that both the BIOS version and date match on 2 additional FS6712X units.