On Fri, Jan 18, 2019 at 10:28:34AM +0100, Greg Kroah-Hartman wrote: > On Fri, Jan 18, 2019 at 10:22:02AM +0100, Uwe Kleine-König wrote: > > On Fri, Jan 18, 2019 at 10:13:37AM +0100, Greg Kroah-Hartman wrote: > > > On Fri, Jan 18, 2019 at 10:07:05AM +0100, Uwe Kleine-König wrote: > > > > But I still agree that there seems to be something "unusual" about the > > > > usb led trigger ... > > > > > > > > Instead of providing a sysfs-file per port to make said port trigger the > > > > led, I'd prefer a single file that you can use to add and remove ports > > > > from the trigger. With this change the driver can properly benefit from > > > > the attribute handling of the led-trigger core and is more in line with > > > > the other triggers. > > > > > > But how do you know how many ports are present? And this feels like it > > > ends up being a "custom api" for each different type of led that is > > > > I assume you mean "different type of led trigger" here. (For leds that > > is not true.) > > > > > present in the system. Or is that already the case? > > > > I imagine something like: > > > > # cat available_ports > > port1 port2 port3 > > > > # cat active_ports > > port1 > > > > # echo port2 > active_ports > > # cat active_ports > > port1 port2 > > > > Regarding the "custom API" point: Sure, it's not possible to entirely > > prevent this as an UART trigger is about UARTs and an USB trigger is > > about USB ports. We could argue about a callback that somehow enumerates > > possible trigger sources, but I'm not sure this simplifies stuff in the > > end because there are still some special cases. E.g. you might want to > > have the UART trigger only blink on TX for ttyS2. > > But, the trigger is on the specific ttyS2 device, so keeping it on the (Sticking to the USB trigger, as the tty trigger isn't completed yet.) Not sure I got you right, but the trigger is configured under the sysfs entry of the affected LED, not the triggering device. So currently you have to do: echo usbport > /sys/class/leds/input0::capslock/trigger echo 1 > /sys/class/leds/input0::capslock/ports/myhub-port2 > individual port devices makes a lot of sense. sysfs should be > one-value-per-file where ever possible. So if the above API is considered better above what I suggested, we have to rethink how this can be simplified for trigger drivers in the trigger core. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |
