about my trigger-sources work

about my trigger-sources work

[Marek Behun]

Hi,
just to let you know and maybe get some feedback or your ideas.

The documentation
https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/common.yaml
specifies that a LED node can have a trigger-sources property to
specify a list of devices which should be used as a source for that
LED's activity.

I am trying to implement this now, since it is not implemented yet in
common API. The only user of this property is
drivers/usb/core/ledtrig-usbport.c and they do it on their own.

One problem is that different classes of devices can be specified as
a source, and so they have to be OF-translated differently.
To solve this I added a new method to struct led_trigger
	int (*of_xlate_and_set_source)(struct led_classdev *led_cdev,
				       const struct of_phandle_args *args);
The purpose is that if a LED trigger can have a source, such as a
network device, and this device is specified in device tree via
trigger-sources, the LED subsystem shall parse the trigger-sources
property and pass it to this method via args. This method then
translates args into a device (ie a network device) and sets it as a
source of triggering for this LED.

Another problem is that it is possible (and probable) that the trigger
source device is not probed yet when LED is being created. We can't use
probe deferral here, because it is possible that source device won't be
probed at all, and this should IMO not cause probe fail for the LED
cdev.
Now this could be solved in multiple ways:
- the led trigger subsystem could do it by registering a notifier for
  when devices are probed. Now I can't find such a notifier existing
  (there are similar, for when a driver is bound and so on, but we need
  one for when device is probed), so this would need to be implemented
  in the core device API
- the led trigger could do it on its own by registering a notifier for
  the subsystem on which the device that can be a trigger source for
  this trigger will live. For example the netdev trigger could register
  a netdevice notifier, the gpio trigger could register a notifier
  for the gpio bus (this would probably need to be implemented as in
  previous point)
I think the second option is better, because of possibility of more
specific notifier events (at least one led trigger (netdev) already uses
netdevice notifier).

This work could later also lead to a more sensible naming of the first
part (device) of LED devices in sysfs, for example:
When a network device eth0 is set to be a trigger-source for a LED,
the LED should be called eth0:color:function. I therefore think that it
should be part of the code of the LED trigger driver to rename the LED,
when a trigger source is set from OF.

What do you think?

Marek