Add support for FS67xx series (FS6712X, 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.

[mafredri]

Finally got around to taking a look at this and everything looks great.

We should perhaps do a better job of documenting the quirks of each model in a separate document or in the code (thinking of e.g. that combined blue/red led), but otherwise nothing to add.

Thanks a lot for adding support for new models!

[mgc8]

This is a great addition for the FS67xx range, thanks @romracer !

I was eager to try it on my device (a FS6712X) for the proper LED support, unfortunately it doesn't seem to be detected. After some digging, it turns out that I have a different BIOS version 1.20 compared to the 1.23 one hardcoded in asustor.c:

(...)
			DMI_EXACT_MATCH(DMI_BIOS_DATE, "09/15/2023"),
(...)

@@ -277,8 +277,8 @@
 Handle 0x000E, DMI type 0, 26 bytes
 BIOS Information
        Vendor: Phoenix Technologies Ltd
-       Version: V1.23
-       Release Date: 09/15/2023
+       Version: V1.20
+       Release Date: 11/04/2022
        ROM Size: 8 MB
        Characteristics:
                PCI is supported

There doesn't appear to be a way to update this BIOS from within Linux, I guess the factory OS does that "in the background"? There's no BIOS download links here either:
https://www.asustor.com/service/downloads?product_id=80

As I imagine other versions could exist as well, perhaps a better way to identify these models is to look in lspci for a number of ASMedia PCIe switches, which come up in a prodigious number? That is a specific NVMe feature that other models most certainly won't have:

$ lspci | grep ASMedia
02:00.0 PCI bridge: ASMedia Technology Inc. ASM2806 4-Port PCIe x2 Gen3 Packet Switch (rev 01)
03:00.0 PCI bridge: ASMedia Technology Inc. ASM2806 4-Port PCIe x2 Gen3 Packet Switch (rev 01)
03:02.0 PCI bridge: ASMedia Technology Inc. ASM2806 4-Port PCIe x2 Gen3 Packet Switch (rev 01)
03:06.0 PCI bridge: ASMedia Technology Inc. ASM2806 4-Port PCIe x2 Gen3 Packet Switch (rev 01)
03:0e.0 PCI bridge: ASMedia Technology Inc. ASM2806 4-Port PCIe x2 Gen3 Packet Switch (rev 01)
08:00.0 PCI bridge: ASMedia Technology Inc. ASM2806 4-Port PCIe x2 Gen3 Packet Switch (rev 01)
09:00.0 PCI bridge: ASMedia Technology Inc. ASM2806 4-Port PCIe x2 Gen3 Packet Switch (rev 01)
09:02.0 PCI bridge: ASMedia Technology Inc. ASM2806 4-Port PCIe x2 Gen3 Packet Switch (rev 01)
09:06.0 PCI bridge: ASMedia Technology Inc. ASM2806 4-Port PCIe x2 Gen3 Packet Switch (rev 01)
09:0e.0 PCI bridge: ASMedia Technology Inc. ASM2806 4-Port PCIe x2 Gen3 Packet Switch (rev 01)
0e:00.0 PCI bridge: ASMedia Technology Inc. ASM2806 4-Port PCIe x2 Gen3 Packet Switch (rev 01)
0f:00.0 PCI bridge: ASMedia Technology Inc. ASM2806 4-Port PCIe x2 Gen3 Packet Switch (rev 01)
0f:02.0 PCI bridge: ASMedia Technology Inc. ASM2806 4-Port PCIe x2 Gen3 Packet Switch (rev 01)
0f:06.0 PCI bridge: ASMedia Technology Inc. ASM2806 4-Port PCIe x2 Gen3 Packet Switch (rev 01)
0f:0e.0 PCI bridge: ASMedia Technology Inc. ASM2806 4-Port PCIe x2 Gen3 Packet Switch (rev 01)

Otherwise, perhaps a range of BIOS versions/dates would help?

[romracer]

Hmm, I wish I could say I knew how to implement that. I'm not really a kernel module developer though. As a hack, it should be possible to duplicate this block, but its admittedly less future-proof: https://github.com/mafredri/asustor-platform-driver/blob/main/asustor.c#L274-L283

I can push up a PR if desired. Thoughts Mathias?

PS: There is a Jasper Lake BIOS update app on the apps tab of the Asustor web page, but it requires their OS to install, and it doesn't have version 1.23 anyway.

[DanielGibson]

@mgc8 @romracer: Can you run the following commands and post the resulting .txt files here?
$ sudo dmidecode > dmidecode.txt
$ sudo lshw > lshw.txt

I'll compare to the output on my AS5402T and try to figure out a difference that's better than the BIOS date
For reference, here are mine:
lshw.txt
dmidecode.txt

[romracer]

@DanielGibson My dmi.txt is included in the first comment on this PR.
lshw.txt

Thanks for taking a look!

[DanielGibson]

Seems like the dmi stuff is too similar.
Your idea with the ASMedia PCIe switches doesn't sound too bad (though I have currently no idea how one would match that in the asustor modules), however:

1. It would be nice to have all this information from a FS6706T, it won't need as many PCIe ports so who knows if it uses the same switch, or needs a switch at all
2. Not sure if maybe the bigger AS67xx models (esp. AS6706T) also use a PCIe switch, maybe to connect additional SATA controllers

[DanielGibson]

Random idea: We already expose all the SATA LEDs on all supported devices of the same series, so even a devices that only supports two SATA HDDs (and thus only has two SATA LEDs), like AS6702T or AS5402T will have 6 SATA LEDs exposed, because AS6706T needs them.
Does it make much of a difference if we also always expose the NVME LEDs (for those xS67xx devices), even if it doesn't exist?

Potential problem: It seems like it uses the same GPIO ports as SATA1 (12, 13), so it would be an alias. No idea if that really is a problem, though

[DanielGibson]

Potential problem: It seems like it uses the same GPIO ports as SATA1 (12, 13), so it would be an alias. No idea if that really is a problem, though

Seems like it is indeed a problem (the nvme1 LEDs don't turn up when just adding them to the asustor_6700_gpio_leds_lookup list with 12 and 13 as chip_hwnum; they do turn up with 14 and 15 so the problem seems indeed to be that 12 and 13 are already used for sata1).

[mgc8]

Can you run the following commands and post the resulting .txt files here? $ sudo dmidecode > dmidecode.txt $ sudo lshw > lshw.txt

@DanielGibson Here are mine:
dmidecode.txt
lshw.txt

I had actually ran a comparison with the dmi.txt that had been uploaded higher up here, and the only relevant difference seemed to be the BIOS version and date... (apart from memory and the processor voltage which are not really relevant).

[mgc8]

Seems like the dmi stuff is too similar. Your idea with the ASMedia PCIe switches doesn't sound too bad (though I have currently no idea how one would match that in the asustor modules), however:

1. It would be nice to have all this information from a FS6706T, it won't need as many PCIe ports so who knows if it uses the same switch, or needs a switch at all
2. Not sure if maybe the bigger AS67xx models (esp. AS6706T) also use a PCIe switch, maybe to connect additional SATA controllers

I am sure the FS6706T also uses the switch, just probably half the number (7 or 8 instead of 15), since the CPU has too few PCIe lanes available otherwise for NVMe.

Can't speak for the SATA models, they might employ the same chips of course, but I think the "criteria" here could be the number of those switches -- over 2x-3x of them and you're likely looking at a NVMe model. It's still a heuristic, and not ideal, but I'm not sure how else we'd identify them either -- short of having some compile-time parameters or Makefile variables perhaps?

On another note, @romracer I can confirm that duplicating that structure for detection, at least as a workaround if not a perfect solution, works fine.

[DanielGibson]

I'll try to figure out if I can detect those PCIe switches in the asustor kernel module, and I also plan to add an argument to the kernel module that allows overriding the detected device (something like force_device=FS67xx)

[DanielGibson]

Could you also post the output of
$ sudo lspci -vv -nn > lspci_vv.txt
and
$ sudo lspci -tv -nn > lspci_tv.txt

(turns out the lshw output doesn't have much information on those PCIe switches)

Thanks in advance :)

UPDATE: added -nn to both of the commands
UPDATE2: and it should've been lspci, not lshw, argh!

[mgc8]

Could you also post the output of $ sudo lspci -vv -nn > lspci_vv.txt and $ sudo lspci -tv -nn > lspci_tv.txt
(turns out the lshw output doesn't have much information on those PCIe switches)
Thanks in advance :)
UPDATE: added -nn to both of the commands UPDATE2: and it should've been lspci, not lshw, argh!

Thanks for that update, I was just about to write confused about my version of lshw not supporting those switches :)

Here are the two files with lspci -[v|t]v -nn:
lspci_vv.txt
lspci_tv.txt

Having the module argument to override detection would be a nice addition, definitely.

I did a bit of digging and found some PCI probing functions in the kernel under drivers/pci/probe.c ( here ) although I'm afraid I'm not familiar enough with kernel internals to be able to get further...

[DanielGibson]

Weird, those don't list the
02:00.0 PCI bridge: ASMedia Technology Inc. ASM2806 4-Port PCIe x2 Gen3 Packet Switch (rev 01)
devices from #21 (comment) at all?!
Does just lspci still list them?

Update: Ok, the lspci -vv output has them, but lspci -tv doesn't

[DanielGibson]

Can you try this branch: https://github.com/DanielGibson/asustor-platform-driver/tree/detect-flashtor

I think it should detect your devices as FS67xx.
(Overriding the detected device is also implemented)

[DanielGibson]

I created a PR, we should probably continue the discussion there: #27