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 individual port devices makes a lot of sense. sysfs should be one-value-per-file where ever possible. thanks, greg k-h
