On 10/6/19 4:11 PM, Akinobu Mita wrote: > 2019年10月6日(日) 4:17 Jacek Anaszewski <jacek.anaszewski@xxxxxxxxx>: >> >> On 10/5/19 3:20 PM, Akinobu Mita wrote: >>> 2019年10月5日(土) 6:17 Jacek Anaszewski <jacek.anaszewski@xxxxxxxxx>: >>>> >>>> Hi Akinobu, >>>> >>>> Why do you think this change is needed? Does it solve >>>> some use case for you? >>> >>> It can be useful when using with an LED trigger that could set the >>> brightness values other than LED_FULL or LED_OFF. >>> >>> The LED CPU trigger for all CPUs (not per CPU) sets the brightness value >>> depending on the number of active CPUs. We can define the multi brightness >>> level gpio LED with fewer number of GPIO LEDs than the total number of >>> CPUs, and the LEDs can be viewed as a level meter. >> >> Can't you achieve exactly the same effect by creating separate LED class >> device for each GPIO LED and registering each of them for separate cpuN >> trigger? > > If there are GPIO LEDs as many as the total number of CPUs, we can. > However, if there are only two GPIO LEDs and six CPUs, we can only know > the CPU activity for two CPUs out of six CPUs with cpuN trigger. > So it's different from using cpu (all) trigger with multi level (2-level) > brightness GPIO LED. OK, that's a reasonable argument. However, this is clearly trigger-specific functionality and we should not delegate this logic down to the driver. What you propose should be a responsibility of a trigger that would allow registering multiple LEDs for its disposal. This would have to be different from existing LED Trigger mechanism, that blindly applies trigger event to all LEDs that have registered for it. Such a trigger would have to be a separate LED (pattern?) class device. It would need to be told how many LEDs it is going to manage and create files for filling the LED names. This design could be also used for defining patterns spanning on multiple LEDs. Just a rough idea. We can dwell on it if it catches. -- Best regards, Jacek Anaszewski
