On Wed, Feb 1, 2017 at 3:55 PM, Rafał Miłecki <zajec5@xxxxxxxxx> wrote: > On 02/01/2017 10:26 PM, Jacek Anaszewski wrote: >> >> On 02/01/2017 04:56 PM, Rafał Miłecki wrote: >>> >>> On 01/31/2017 10:34 PM, Jacek Anaszewski wrote: >>>> >>>> On 01/31/2017 05:11 PM, Rafał Miłecki wrote: >>>>> >>>>> Thanks a lot Jacek for this explanation (and sorry but I needed a bit >>>>> of >>>>> time to >>>>> think about this). I can finally see your point, I think we're on the >>>>> same page >>>>> now. >>>>> >>>>> I think that for all this time I was thinking from the pure DT >>>>> perspective. If >>>>> you ignore fact that Linux has multiple LED trigger drivers, then >>>>> "led-triggers" >>>>> may not sound that bad. >>>>> >>>>> After reading your description however I can see this property can be >>>>> misleading >>>>> as Linux people may think "drivers" when seeing "triggers". >>>>> >>>>> I still think this is a useful property and I hope we can still find a >>>>> way to >>>>> name it in a sane way: to be nice from DT PoV and march Linux LEDs >>>>> subsystem. >>>> >>>> >>>> I also see the need for this property. >>>> >>>>> I think we should still work on some generic property (without linux, >>>>> prefix) as >>>>> this seems to be something generic, not really specific to Linux >>>>> implementation. >>>>> Specifying relation between LED and devices is something than AFAICS >>>>> can be >>>>> reused by other systems as well. >>>>> >>>>> So my suggestion is to try some new name & leave linux,default-trigger >>>>> to allow >>>>> specifying one single trigger driver as required by current Linux >>>>> implementation. >>>>> >>>>> What do you think about this? >>>>> >>>>> There are few suggestions to came to my mind: >>>>> "trigger-sources" >>>>> "trigger-devices" >>>>> "led-trigger-devices" >>>>> "led-related-devices" >>>>> "led-event-devices" >>>> >>>> >>>> trigger-devices would work in this specific use case, >>>> where we can give phandles to usb ports. Nonetheless, we >>>> have also other kernel based events serving as trigger >>>> sources - e.g. timer. >>>> >>>> In this case I'd go for trigger-sources, but we'd need >>>> to have some generic way of defining the source like timer. +1 for the name. >>> >>> >>> I'd leave timer for later discussion but I'm glad you brought this >>> problem. >>> Maybe we could discuss this on another example that is more supported >>> like >>> GPIOs? >>> >>> We know this property allows specifying USB ports and we want it to >>> support >>> mixing various sources. So a very simple sample case seems to be using >>> it for >>> specifying GPIO as trigger source. >>> >>> Is this possible to mix various entries in a list assigned to single >>> property? >>> Let's say: >>> trigger-sources = >>> <&ohci_port1>, >>> <&ehci_port1>, >>> <&gpio 1 GPIO_ACTIVE_HIGH>; >> >> >> According to my knowledge all elements in the list are elements >> of one array, no matter if they are comma separated or space separated >> in "<>" brackets. DT maintainer would have to confirm that though. > > > This matches my knowledge as well. It is a bit problematic, but this could work as long as you know the possible arg types and a given node only has 1 match (nodes with interrupt and gpio being likely). You look up the phandle, iterate thru possible "#*-cells" properties for that phandle, then parse the cells. You could define rules of what is the required cell type (e.g. must use gpio cells if a phandle has both gpio and interrupt cells defined.). Another, simpler approach would be defining #trigger-cells in each source. This is probably the better option as all the infrastructure is there and could handle unforeseen cases. >>> Is this possible to support this? If so, which function I can use to >>> detect >>> what is pointed by a phandle? >>> I'm not that familiar with DT and I'm not sure how to handle this. >> >> >> I wonder if this is correct way to go. Maybe we should think of >> creating entirely new trigger mechanism that would allow for having >> multiple active triggers at a time. > > > I'm OK with reworking Linux's triggers if it need be. I think we should > agree > on binding(s) first though. Yes, they are separate problems. Rob
