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. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |
