0

I'm new to Linux and I have the following problem. Unfortunately, I was not able to find appropriate information on the web, which helped me to solve it.

I have a Linux system here and a PCIe-to-UART converter from MaxLinear (XR17V358) connected to it. To enable support for this converter, I have activated the exar-serial driver in the kernel config. Furthermore, this XR17V358 provides 16 GPIOs, which can be freely used. There is also a kernel driver available to enable these GPIOs (exar-gpio) and I have also activated it in the kernel config. As a first step, all seems to work fine. There are ttyS0 to ttyS7 created in the /dev directory and I'm able to send and receive data. Also, a gpiochip472 is created in /sys/class/gpio and I'm able to export the 16 GPIOs manually and use them as expected.

So far so good...

Now I don't want to export the GPIOs manually after boot but automatically. For example, some LEDs are connected to the GPIOs of XR17V358 and I'd like to export these LEDs in /sys/class/leds via the device tree. I have searched for information, on how to export the GPIOs via device tree but the only information I could find was in https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio-exar.txt:

Exportable MPIO interface of Exar UART chips

Required properties of the device:
 - exar,first-pin: first exportable pins (0..15)
 - ngpios: number of exportable pins (1..16) 

I have then tried to describe a node of this XR17V358 GPIO controller like this:

fragment@1001 {
    target-path = "/";
    __overlay__ {
        gpio_exar: gpio@18100000 {
            compatible = "exar,gpio_exar";
            exar,first-pin = <0>;
            ngpios = <16>;
            status = "okay";
        };
    };
};

...and refer to it in the leds-node:

fragment@1002 {
    target-path = "/";
    __overlay__ {
        leds {
            pinctrl-names = "default";
            compatible = "gpio-leds";
            status = "okay";

            led0 {
                label = "led1";
                gpios = <&gpio_exar 2 GPIO_ACTIVE_HIGH>;
                default-state = "off";
                linux,default-trigger = "none";
            };
        };
    };
};

I'm sure, that LEDs-node implementation should be okay because in the same way, I'm able to export any native GPIO of the SoC. My problem seems to be, that I cannot correctly bind exar-gpio driver to device tree node. When I have a look into driver code gpio-exar.c, there seems not to be any code block, which declares a "compatible" name for the driver. Also, the properties exar,first-pin as well as ngpios seem not to be read out from a device tree node. Instead, it seems, that these values come from the exar-serial driver (8250_exar.c) and in that driver code, the values are hard coded.

So my question is, what I'm doing wrong? Or is there no possibility at all to make any device tree binding to this exar-gpio driver?

0andriy
  • 4,183
  • 1
  • 24
  • 37
ThKe93
  • 3
  • 3
  • I think you would need a daemon in userspace to create virtual LED devices using the [Userspace LEDs](https://www.kernel.org/doc/html/latest/leds/uleds.html) support (`CONFIG_LEDS_USER`). – Ian Abbott Jul 19 '22 at 12:49
  • Thanks for the hint! I had a look at it but if I see correctly, I also have to manually "export" the GPIOs of XR17V358 by writing to file handle /dev/uleds. So I could also simply create GPIOs by exporting them through sysfs in /sys/class/gpio/. Is there any possibility to let these LED outputs (and in best case also any other digital outputs) be created during boot by appropriate Exar driver and device tree properties? – ThKe93 Jul 19 '22 at 14:16
  • Device tree is really for statically allocated devices, not for devices on "plug and play" buses like PCI. With ACPI it is possible to associate devices created by PCI device drivers with firmware nodes. That is for built-in PCI devices with known bus/device/function addresses. I think that is what the `ACPI_COMPANION_SET` macro call is doing in "drivers/tty/serial/8250/8250_exar.c". Sorry that is not much help. There might be a way map PCI devices in device tree, but I am out of my depth. – Ian Abbott Jul 19 '22 at 15:00
  • Thanks for your help @IanAbbott! I had this not in mind, that PCIe devices are self discoverable and hence maybe doesn't need any device tree node. In that case I maybe have to export the GPIOs in another way, e. g. by any script which is executed late in boot process or as you have mentioned by Userspace LEDs... – ThKe93 Jul 20 '22 at 08:26
  • You can simply achieve that by adding an OF ID table with the corresponding compatible string. Then you need to disable the automatic driver attachment in 8250_exar. But yes, this will ruin PCI ideology. – 0andriy Jul 20 '22 at 14:27
  • In my case PCIe device is fixed mounted on the circuit board so it can be more seen as a platform device, as it's always connected...?! So I think I will try your suggestion @0andriy, thank you. – ThKe93 Jul 21 '22 at 05:37

0 Answers0