0

This is all in Linux 4.14.73. I'd upgrade if I could but I cant.

I'm trying to trigger an LED flash in a standard LED class instance from another kernel space driver. I know all about the "bad form" of not accessing files from Kernel Space so I figure there must be some way already defined way for accessing Sysfs attributes from Kernel Space.

The LED is defined here:

/sys/class/leds/fpga_led0

Its trigger is set to [oneshot] so it has a device attribute called "shot" exposed. To get a single LED flash all I need to do from the command line is this:

echo 1 > /sys/class/leds/fpga_led0/shot

I can easily write a User Space program to open the "shot" attribute and write a "1" string to it. There are various published methods of forcing file operations into a kernel driver. Most of them are fairly limited. I've yet to see one that exposes file seek operations which are key to repeatedly writing to an attribute without wasting time opening and closing the file. To be clear, this is not setting values at boot time. In this case I have one driver that needs to send a value to another driver's Sysfs entry at a specific moment in its own operation. Is there a standard, accepted way of sending a value from one running kernel driver to the Sysfs attribute of another kernel driver?

Marco Bonelli
  • 63,369
  • 21
  • 118
  • 128
jemiah
  • 63
  • 8
  • 1
    There is no standard way to read/write from/to sysfs from kernel space. You will have to manually identify the module responsible for registering that entry and take a look at the `file_operations` it defines, in particular the `write` operation. From there you can try and replicate the behavior of the code in your module. It would probably help to add more information about the device you are working on, which FPGA is it? Do you know which module (if any) controls the led? – Marco Bonelli Feb 14 '22 at 16:00
  • @MarcoBonelli This is for a Nios2 core implemented in a Max10 FPGA. I have extremely tight constraints and am stuck with the 4.14.73 kernel. I was actively trying to avoid replicating the LED behavior as it's already setup and working perfectly. The standard kernel sys/class/led driver code is linked to the FPGA PIO module right in the DTS file. The kernel LED flash/trigger setup works flawlessly. The other driver in question just needs to trip the trigger and log EXACTLY when it did it. I'm tempted to write a user space app to bind them but the latency would be unacceptable. Still looking. – jemiah Feb 14 '22 at 17:54
  • 1
    This doesn't help you if you are stuck with 4.14, but the 5.6 kernel has the `of_get_led()` / `led_put()` API and the `devm_led_get()` managed API which allows a device driver to get a list of LEDs specified by an `leds` property (it is an array of phandles) in the device's node in the device tree. It is used by the "led_bl" driver ("drivers/video/backlight/led_bl.c") in kernel 5.6 or later. – Ian Abbott Feb 14 '22 at 18:45
  • @IanAbbott Thanks. I'll look into how it works JIK. I am stuck with 4.14 unfortunately. Given how intense the stricture is on accessing files from inside the Kernel I can't believe there isn't something for accessing Sysfs entries. – jemiah Feb 14 '22 at 21:18
  • 1
    My original question still stands but I've found a work-around for this specific case. Luckily, when I dug into the docs for the LED support in this kernel its API has support for direct kernel space signaling to the LEDs defined in linux/leds.h. I added a "linux,default-trigger" entry into DTS file for the LED in question and was able to make a led_trigger_register_simple() call from the other driver to get access and it could then make led_trigger_blink_oneshot() calls. Still, every driver doesn't have such a shiny API. It feels like there should be a generic process for this. – jemiah Feb 15 '22 at 07:28
  • There isn't becuase what you want is completely wrong from the Linux kernel design perspective. You should use the framework(s) directly with whatever APIs they provide and not poking to the modules via unusual (for kernel) ways. – 0andriy Feb 15 '22 at 08:06
  • 1
    That is how LED framwork was designed actually. One part is about hardware (LED **provider**) and the other is for user (**consumer**), i.e. who triggers that LED. So, it seems you found more or less proper approach. – 0andriy Feb 15 '22 at 08:08

0 Answers0