> From: Steffen Beyer <[email protected]> > Date: Mon, 5 Aug 2024 13:55:09 +0200 > > > On 4. Aug 2024, at 16:28, Steffen Beyer <[email protected]> wrote: > > > > rkgpio0 at rkpinctrl0 > > rkgpio1 at rkpinctrl0 > > rkgpio2 at rkpinctrl0 > > rkgpio3 at rkpinctrl0 > > rkgpio4 at rkpinctrl0 > > Is it possible to access GPIO and the connected LEDs? > > My understanding is, that gpioleds should access the device tree: > > leds { > compatible = "gpio-leds"; > > sys_led: led-0 { > label = "sys_led"; > gpios = <&gpio1 RK_PC1 GPIO_ACTIVE_HIGH>; > linux,default-trigger = "heartbeat"; > pinctrl-names = "default"; > pinctrl-0 = <&sys_led_pin>; > }; > > wan_led: led-1 { > label = "wan_led"; > gpios = <&gpio1 RK_PC2 GPIO_ACTIVE_HIGH>; > pinctrl-names = "default"; > pinctrl-0 = <&wan_led_pin>; > }; > > lan1_led: led-2 { > label = "lan1_led"; > gpios = <&gpio1 RK_PC3 GPIO_ACTIVE_HIGH>; > pinctrl-names = "default"; > pinctrl-0 = <&lan1_led_pin>; > }; > > lan2_led: led-3 { > label = "lan2_led"; > gpios = <&gpio1 RK_PC4 GPIO_ACTIVE_HIGH>; > pinctrl-names = "default"; > pinctrl-0 = <&lan2_led_pin>; > }; > }; > > …and make those available, but: > > gpioleds0 at mainbus0: no LEDs
The gpioleds(4) driver only handles initializations of LEDs that have a "default-state" proprty (to make sure they're initialized to the default state). It may make sense to extend that code to look at the linux,default-trigger property to do some useful with the LED. In your example above: linux-default-trigger = "heartbeat" could be used to make the LED blink based on how busy a machine is like we did on some sparc machines and still do on some hppa and sparc64 machines. The names of the other LEDs suggest that they should be used to indicate network interface activity but there is not enough information in the device tree to make them do something useful by default. > Further, I tried in /etc/rc.securelevel: > > echo -n ' gpio' > /usr/sbin/gpioctl gpio1 0 set out led0 > /usr/sbin/gpioctl gpio1 1 set out led1 > /usr/sbin/gpioctl gpio1 2 set out led2 > /usr/sbin/gpioctl gpio1 3 set out led3 > > …but: > > # gpioctl gpio1 0 1 > gpioctl: /dev/gpio1: Device not configured > > How is it supposed to work? It doesn't work for rkgpio(4) because it isn't implemented. We made a conscious decision to not give userland direct access to hardware. For bcmgpio(4) and sxipio(4) we implemented some code that selectively exposes GPIO pins through gpio(4) if: 1. The pin isn't claimed by another device driver. 2. The pin is configured as a GPIO pin by the firmware and/or device tree. That reduces the amount of damage that can be done by using gpioctl((8) but doesn't completely eliminate it. Something similar could be done for rkgpio(4), but so far it hasn't been something I felt a need for myself. Cheers, Mark
