Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux