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
