On Tue, 1 Jun 2021 22:18:16 -0500 stuart hayes <stuart.w.hayes@xxxxxxxxx> wrote: > Both Bjorn Helgaas and Krzysztof Wilczyński had suggested the > scheduler-type interface, so I went with that. In an earlier attempt > at this driver, when Bjorn suggested this, he asked if that would > violate the "one value per file" rule, and Greg K-H responded "That's > a valid way of displaying options for a sysfs file that can be > specific unique values." But you are not displaying unique values. Your example is # echo "ok locate" >/sys/class/leds/0000:88:00.0::drive_status/states # cat /sys/class/leds/0000:88:00.0::drive_status/states [ok] [locate] failed rebuild pfa hotspare ica ifa invalid disabled so there are 2 values set (ok and locate). Unique means that only one can be set. Question: can this LED be configured by userspace? I mean: can you configure whether the LED should be on/off, disregarding the SSD state? I ask because the LED subsystem currently officially does not support LEDs for which brightness cannot be set by userspace... If yes, you should implement the .brightness_set() function. (Could you please also send your patch to the linux-leds mailing list?) Then you should implement a LED-private trigger for this LED, which, when enabled, will make the LED follow the SSD state. The sysfs ABI should probably look like this: # cd /sys/class/leds/<SSD_LED> # echo 1 >brightness # to light the LED on # echo 0 >brightness # to light the LED off # echo ssd_state >trigger # to make the LED follow SSD states # ls ssd_state # list available SSD states ok locate failed rebuild ... # cat ssd_state/ok # check if "ok" state is enabled 0 # echo 1 >ssd_state/ok # enable "ok" state so that the # LED will be on when SSD is in "ok" # state # echo none >trigger # put the LED back into SW mode (The name of the trigger does not necessarily have to be "ssd_state". Other people should give their opinions about the name.) Marek
