0

I have an up2board with Ubuntu 18.04 and dedicated kernel so I can use this board specific hardware like i.e LEDs. I turn these LEDs using following commands:

$ sudo -i
$ cd /sys/class/gpio
$ echo 432 > export
$ cd gpio432
$ echo "out" > direction
$ echo 1 > value

Now, I would like to find out two things:

  1. How a command such as echo 1 > value propagate from user space down to driver.

  2. How to find out what driver is responsible for this LEDs support.

2
  • These could be seen as two very different questions. Is the first question about how redirection in the shell works, or how the driver picks up the value from the /sys hierarchy?
    – Kusalananda
    May 4, 2019 at 9:19
  • @Kusalananda, the later - how driver gets called - starting from echo 1 > value down to driver interfaces.
    – DannyS
    May 4, 2019 at 9:22

1 Answer 1

1

Very briefly:

Entries in /sys are not really files. This mount is of type sysfs, and in the kernel this corresponds to an API where other parts of the kernel can register themselves. Then when the "files" of this file system are read or written, sysfs forwards these actions to the registered modules.

The gpio (general purpose I/O) layer of the kernel is again an abstractions where other drivers can registers. Typically these are drivers of chips or chipsets which have GPIO registers in the chips themselves. How the GPIO pins of these chips are wired depends on the hardware.

A bit more information can be found in Documentation/gpio/gpio.txt etc. in the kernel source code.

As for ways to identify the driver, one way is to ll gpio432 after you have created the gpio node and look at the symlink; it will point to the device that has the chip/chipset with the GPIO registers. Then look for the driver for that device.

Another way would be to look through dmesg and see if the driver produces messages when it registers the GPIO.

Possibly this information can also be accessed via udevadm.

2
  • As for finding a driver name, I managed to found it in a way similar to yours. However your answer lacks the information about the information flow from user space to driver itself. How can I check what function is called after echo 1 > value? Can I put a breakpoint, print sth to the screen or log the action in kernel code?
    – DannyS
    May 5, 2019 at 16:50
  • The control flow is dynamic, and it depends on what modules are registered, so I can't think of an easy way to check what functions are called. You can't put breakpoints in kernel code (the whole system would freeze). There are various ways to trace function executions (google "kernel trace" etc.), but I haven't tried if there are enough tracepoints to trace this particular flow. The other methods will likely be less effort than setting up tracing.
    – dirkt
    May 6, 2019 at 5:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.