On Mon, Aug 05, 2024 at 02:58:07PM +0200, Mark Kettenis wrote:
> > From: Steffen Beyer <stef...@beyer.io>
> > Date: Mon, 5 Aug 2024 13:55:09 +0200
> >
> > > On 4. Aug 2024, at 16:28, Steffen Beyer <stef...@beyer.io> 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
>
I mean, we could maybe attach gpio(4) to gpioleds(4), with maybe the
names pre-filled from the DT? At that point we already know these
GPIOs are only LEDs and we wouldn't even give it raw access to the
other GPIO drivers. Also we only need to attach a single gpio(4) and
not one per GPIO driver.
Otherwise, time to revive led(4)/ledctl(1)? ;)
https://marc.info/?l=openbsd-tech&m=157627303425435&w=2
