[v2] leds: fix regression in usbport led trigger

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

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