diff mbox series

[V2,REBASED] dt-bindings: leds: add "usbport" trigger

Message ID 20230316135546.9162-1-zajec5@gmail.com
State New
Headers show
Series [V2,REBASED] dt-bindings: leds: add "usbport" trigger | expand

Commit Message

Rafał Miłecki March 16, 2023, 1:55 p.m. UTC
From: Rafał Miłecki <rafal@milecki.pl>

Linux's "usbport" trigger is a bit specific one. It allows LED to follow
state of multiple USB ports which have to be selected additionally
(there isn't a single trigger for each port).

Default list of USB ports to monitor can be specified using
"trigger-sources" DT property. Theoretically it should be possible for
Linux to deduce applicable trigger based on the references nodes in the
"trigger-sources". It hasn't been implemented however (probably due to
laziness).

Milk spilled - we already have DT files specifying "usbport" manually -
allow that value in the binding. This fixes validation of in-kernel and
external DT files.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
 Documentation/devicetree/bindings/leds/common.yaml | 2 ++
 1 file changed, 2 insertions(+)

Comments

Rafał Miłecki Dec. 28, 2023, 7:33 a.m. UTC | #1
Hi Lee,

On 16.03.2023 16:33, Lee Jones wrote:
> On Thu, 16 Mar 2023, Rafał Miłecki wrote:
> 
>> From: Rafał Miłecki <rafal@milecki.pl>
>>
>> Linux's "usbport" trigger is a bit specific one. It allows LED to follow
>> state of multiple USB ports which have to be selected additionally
>> (there isn't a single trigger for each port).
>>
>> Default list of USB ports to monitor can be specified using
>> "trigger-sources" DT property. Theoretically it should be possible for
>> Linux to deduce applicable trigger based on the references nodes in the
>> "trigger-sources". It hasn't been implemented however (probably due to
>> laziness).
>>
>> Milk spilled - we already have DT files specifying "usbport" manually -
>> allow that value in the binding. This fixes validation of in-kernel and
>> external DT files.
>>
>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>> ---
>>   Documentation/devicetree/bindings/leds/common.yaml | 2 ++
>>   1 file changed, 2 insertions(+)
> 
> Applied, thanks

it seems this PATCH got lost somewhere. Can you check it, please?
Lee Jones Jan. 9, 2024, 8:42 a.m. UTC | #2
On Thu, 28 Dec 2023, Rafał Miłecki wrote:

> Hi Lee,
> 
> On 16.03.2023 16:33, Lee Jones wrote:
> > On Thu, 16 Mar 2023, Rafał Miłecki wrote:
> > 
> > > From: Rafał Miłecki <rafal@milecki.pl>
> > > 
> > > Linux's "usbport" trigger is a bit specific one. It allows LED to follow
> > > state of multiple USB ports which have to be selected additionally
> > > (there isn't a single trigger for each port).
> > > 
> > > Default list of USB ports to monitor can be specified using
> > > "trigger-sources" DT property. Theoretically it should be possible for
> > > Linux to deduce applicable trigger based on the references nodes in the
> > > "trigger-sources". It hasn't been implemented however (probably due to
> > > laziness).
> > > 
> > > Milk spilled - we already have DT files specifying "usbport" manually -
> > > allow that value in the binding. This fixes validation of in-kernel and
> > > external DT files.
> > > 
> > > Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> > > ---
> > >   Documentation/devicetree/bindings/leds/common.yaml | 2 ++
> > >   1 file changed, 2 insertions(+)
> > 
> > Applied, thanks
> 
> it seems this PATCH got lost somewhere. Can you check it, please?

What makes you think that?

https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/leds/common.yaml#L126
Rafał Miłecki Jan. 9, 2024, 10:05 a.m. UTC | #3
On 9.01.2024 09:42, Lee Jones wrote:
> On Thu, 28 Dec 2023, Rafał Miłecki wrote:
>> On 16.03.2023 16:33, Lee Jones wrote:
>>> On Thu, 16 Mar 2023, Rafał Miłecki wrote:
>>>
>>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>>
>>>> Linux's "usbport" trigger is a bit specific one. It allows LED to follow
>>>> state of multiple USB ports which have to be selected additionally
>>>> (there isn't a single trigger for each port).
>>>>
>>>> Default list of USB ports to monitor can be specified using
>>>> "trigger-sources" DT property. Theoretically it should be possible for
>>>> Linux to deduce applicable trigger based on the references nodes in the
>>>> "trigger-sources". It hasn't been implemented however (probably due to
>>>> laziness).
>>>>
>>>> Milk spilled - we already have DT files specifying "usbport" manually -
>>>> allow that value in the binding. This fixes validation of in-kernel and
>>>> external DT files.
>>>>
>>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>>>> ---
>>>>    Documentation/devicetree/bindings/leds/common.yaml | 2 ++
>>>>    1 file changed, 2 insertions(+)
>>>
>>> Applied, thanks
>>
>> it seems this PATCH got lost somewhere. Can you check it, please?
> 
> What makes you think that?
> 
> https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/leds/common.yaml#L126

I have no idea. It seems all good. Sorry for the noise, brain fart.
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
index 61e63ed81ced..11aedf1650a1 100644
--- a/Documentation/devicetree/bindings/leds/common.yaml
+++ b/Documentation/devicetree/bindings/leds/common.yaml
@@ -125,6 +125,8 @@  properties:
           - usb-gadget
             # LED indicates USB host activity
           - usb-host
+            # LED indicates USB port state
+          - usbport
         # LED is triggered by CPU activity
       - pattern: "^cpu[0-9]*$"
         # LED is triggered by Bluetooth activity