* [PATCH] dt-bindings: leds: Mark label property as deprecated @ 2022-11-22 11:11 Christoph Niedermaier 2022-11-22 11:11 ` [PATCH] dt-bindings: mfd: da9062: Correct file name for watchdog Christoph Niedermaier ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: Christoph Niedermaier @ 2022-11-22 11:11 UTC (permalink / raw) To: linux-kernel Cc: Christoph Niedermaier, Pavel Machek, Rob Herring, Krzysztof Kozlowski, Jacek Anaszewski, Marek Vasut, kernel, linux-leds, devicetree Mark the label property as deprecated as it is mentioned in the description. Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> --- Cc: Pavel Machek <pavel@ucw.cz> Cc: Rob Herring <robh+dt@kernel.org> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com> Cc: Marek Vasut <marex@denx.de> Cc: kernel@dh-electronics.com Cc: linux-leds@vger.kernel.org Cc: devicetree@vger.kernel.org To: linux-kernel@vger.kernel.org --- Documentation/devicetree/bindings/leds/common.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml index f5c57a580078..c1ce846f7676 100644 --- a/Documentation/devicetree/bindings/leds/common.yaml +++ b/Documentation/devicetree/bindings/leds/common.yaml @@ -52,6 +52,7 @@ properties: $ref: /schemas/types.yaml#/definitions/uint32 label: + deprecated: true description: The label for this LED. If omitted, the label is taken from the node name (excluding the unit address). It has to uniquely identify a device, i.e. -- 2.11.0 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH] dt-bindings: mfd: da9062: Correct file name for watchdog 2022-11-22 11:11 [PATCH] dt-bindings: leds: Mark label property as deprecated Christoph Niedermaier @ 2022-11-22 11:11 ` Christoph Niedermaier 2022-11-29 12:33 ` Krzysztof Kozlowski 2022-11-22 11:11 ` [PATCH] dt-bindings: mmc: Make comment on wakeup-source less confusing Christoph Niedermaier 2022-11-22 12:23 ` [PATCH] dt-bindings: leds: Mark label property as deprecated Pavel Machek 2 siblings, 1 reply; 30+ messages in thread From: Christoph Niedermaier @ 2022-11-22 11:11 UTC (permalink / raw) To: linux-kernel Cc: Christoph Niedermaier, Support Opensource, Lee Jones, Rob Herring, Krzysztof Kozlowski, Marek Vasut, kernel, devicetree Replace the watchdog file name with the name currently in use. Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> --- Cc: Support Opensource <support.opensource@diasemi.com> Cc: Lee Jones <lee@kernel.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> Cc: Marek Vasut <marex@denx.de> Cc: kernel@dh-electronics.com Cc: devicetree@vger.kernel.org To: linux-kernel@vger.kernel.org --- Documentation/devicetree/bindings/mfd/da9062.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt b/Documentation/devicetree/bindings/mfd/da9062.txt index bab0d0e66cb3..e96629eb9f48 100644 --- a/Documentation/devicetree/bindings/mfd/da9062.txt +++ b/Documentation/devicetree/bindings/mfd/da9062.txt @@ -85,7 +85,7 @@ Sub-nodes: - onkey : See ../input/da9062-onkey.txt -- watchdog: See ../watchdog/da9062-watchdog.txt +- watchdog: See ../watchdog/da9062-wdt.txt - thermal : See ../thermal/da9062-thermal.txt -- 2.11.0 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: mfd: da9062: Correct file name for watchdog 2022-11-22 11:11 ` [PATCH] dt-bindings: mfd: da9062: Correct file name for watchdog Christoph Niedermaier @ 2022-11-29 12:33 ` Krzysztof Kozlowski 2022-11-30 10:10 ` Lee Jones 2022-11-30 10:18 ` Christoph Niedermaier 0 siblings, 2 replies; 30+ messages in thread From: Krzysztof Kozlowski @ 2022-11-29 12:33 UTC (permalink / raw) To: Christoph Niedermaier, linux-kernel Cc: Support Opensource, Lee Jones, Rob Herring, Krzysztof Kozlowski, Marek Vasut, kernel, devicetree On 22/11/2022 12:11, Christoph Niedermaier wrote: > Replace the watchdog file name with the name currently in use. > > Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> > --- > Cc: Support Opensource <support.opensource@diasemi.com> > Cc: Lee Jones <lee@kernel.org> > Cc: Rob Herring <robh+dt@kernel.org> > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > Cc: Marek Vasut <marex@denx.de> > Cc: kernel@dh-electronics.com > Cc: devicetree@vger.kernel.org > To: linux-kernel@vger.kernel.org > --- > Documentation/devicetree/bindings/mfd/da9062.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt b/Documentation/devicetree/bindings/mfd/da9062.txt > index bab0d0e66cb3..e96629eb9f48 100644 > --- a/Documentation/devicetree/bindings/mfd/da9062.txt > +++ b/Documentation/devicetree/bindings/mfd/da9062.txt > @@ -85,7 +85,7 @@ Sub-nodes: > > - onkey : See ../input/da9062-onkey.txt > > -- watchdog: See ../watchdog/da9062-watchdog.txt > +- watchdog: See ../watchdog/da9062-wdt.txt How is this related to LED patch? Don't mix threads. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: mfd: da9062: Correct file name for watchdog 2022-11-29 12:33 ` Krzysztof Kozlowski @ 2022-11-30 10:10 ` Lee Jones 2022-11-30 10:13 ` kernel 2022-11-30 10:19 ` Krzysztof Kozlowski 2022-11-30 10:18 ` Christoph Niedermaier 1 sibling, 2 replies; 30+ messages in thread From: Lee Jones @ 2022-11-30 10:10 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Christoph Niedermaier, linux-kernel, Support Opensource, Rob Herring, Krzysztof Kozlowski, Marek Vasut, kernel, devicetree On Tue, 29 Nov 2022, Krzysztof Kozlowski wrote: > On 22/11/2022 12:11, Christoph Niedermaier wrote: > > Replace the watchdog file name with the name currently in use. > > > > Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> > > --- > > Cc: Support Opensource <support.opensource@diasemi.com> > > Cc: Lee Jones <lee@kernel.org> > > Cc: Rob Herring <robh+dt@kernel.org> > > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > > Cc: Marek Vasut <marex@denx.de> > > Cc: kernel@dh-electronics.com > > Cc: devicetree@vger.kernel.org > > To: linux-kernel@vger.kernel.org > > --- > > Documentation/devicetree/bindings/mfd/da9062.txt | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt b/Documentation/devicetree/bindings/mfd/da9062.txt > > index bab0d0e66cb3..e96629eb9f48 100644 > > --- a/Documentation/devicetree/bindings/mfd/da9062.txt > > +++ b/Documentation/devicetree/bindings/mfd/da9062.txt > > @@ -85,7 +85,7 @@ Sub-nodes: > > > > - onkey : See ../input/da9062-onkey.txt > > > > -- watchdog: See ../watchdog/da9062-watchdog.txt > > +- watchdog: See ../watchdog/da9062-wdt.txt > > How is this related to LED patch? Don't mix threads. Que? [PATCH] dt-bindings: mfd: da9062: Correct file name for watchdog -- Lee Jones [李琼斯] ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [PATCH] dt-bindings: mfd: da9062: Correct file name for watchdog 2022-11-30 10:10 ` Lee Jones @ 2022-11-30 10:13 ` kernel 2022-11-30 10:19 ` Krzysztof Kozlowski 1 sibling, 0 replies; 30+ messages in thread From: kernel @ 2022-11-30 10:13 UTC (permalink / raw) To: Lee Jones, Krzysztof Kozlowski Cc: linux-kernel, Support Opensource, Rob Herring, Krzysztof Kozlowski, Marek Vasut, kernel, devicetree From: Lee Jones [mailto:lee@kernel.org] Sent: Wednesday, November 30, 2022 11:10 AM > On Tue, 29 Nov 2022, Krzysztof Kozlowski wrote: > >> On 22/11/2022 12:11, Christoph Niedermaier wrote: >>> Replace the watchdog file name with the name currently in use. >>> >>> Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> >>> --- >>> Cc: Support Opensource <support.opensource@diasemi.com> >>> Cc: Lee Jones <lee@kernel.org> >>> Cc: Rob Herring <robh+dt@kernel.org> >>> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> >>> Cc: Marek Vasut <marex@denx.de> >>> Cc: kernel@dh-electronics.com >>> Cc: devicetree@vger.kernel.org >>> To: linux-kernel@vger.kernel.org >>> --- >>> Documentation/devicetree/bindings/mfd/da9062.txt | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt b/Documentation/devicetree/bindings/mfd/da9062.txt >>> index bab0d0e66cb3..e96629eb9f48 100644 >>> --- a/Documentation/devicetree/bindings/mfd/da9062.txt >>> +++ b/Documentation/devicetree/bindings/mfd/da9062.txt >>> @@ -85,7 +85,7 @@ Sub-nodes: >>> >>> - onkey : See ../input/da9062-onkey.txt >>> >>> -- watchdog: See ../watchdog/da9062-watchdog.txt >>> +- watchdog: See ../watchdog/da9062-wdt.txt >> >> How is this related to LED patch? Don't mix threads. > > Que? > > [PATCH] dt-bindings: mfd: da9062: Correct file name for watchdog > > -- > Lee Jones [李琼斯] I am sorry. I used git send-email the wrong way. Thanks for pointing this out. Don't answer to this E-Mail. I will send a new patch. Regards Christoph ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: mfd: da9062: Correct file name for watchdog 2022-11-30 10:10 ` Lee Jones 2022-11-30 10:13 ` kernel @ 2022-11-30 10:19 ` Krzysztof Kozlowski 2022-11-30 10:20 ` Lee Jones 1 sibling, 1 reply; 30+ messages in thread From: Krzysztof Kozlowski @ 2022-11-30 10:19 UTC (permalink / raw) To: Lee Jones Cc: Christoph Niedermaier, linux-kernel, Support Opensource, Rob Herring, Krzysztof Kozlowski, Marek Vasut, kernel, devicetree On 30/11/2022 11:10, Lee Jones wrote: > On Tue, 29 Nov 2022, Krzysztof Kozlowski wrote: > >> On 22/11/2022 12:11, Christoph Niedermaier wrote: >>> Replace the watchdog file name with the name currently in use. >>> >>> Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> >>> --- >>> Cc: Support Opensource <support.opensource@diasemi.com> >>> Cc: Lee Jones <lee@kernel.org> >>> Cc: Rob Herring <robh+dt@kernel.org> >>> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> >>> Cc: Marek Vasut <marex@denx.de> >>> Cc: kernel@dh-electronics.com >>> Cc: devicetree@vger.kernel.org >>> To: linux-kernel@vger.kernel.org >>> --- >>> Documentation/devicetree/bindings/mfd/da9062.txt | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt b/Documentation/devicetree/bindings/mfd/da9062.txt >>> index bab0d0e66cb3..e96629eb9f48 100644 >>> --- a/Documentation/devicetree/bindings/mfd/da9062.txt >>> +++ b/Documentation/devicetree/bindings/mfd/da9062.txt >>> @@ -85,7 +85,7 @@ Sub-nodes: >>> >>> - onkey : See ../input/da9062-onkey.txt >>> >>> -- watchdog: See ../watchdog/da9062-watchdog.txt >>> +- watchdog: See ../watchdog/da9062-wdt.txt >> >> How is this related to LED patch? Don't mix threads. > > Que? > > [PATCH] dt-bindings: mfd: da9062: Correct file name for watchdog It's a response to a LED patch (single, not thread). Best regards, Krzysztof ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: mfd: da9062: Correct file name for watchdog 2022-11-30 10:19 ` Krzysztof Kozlowski @ 2022-11-30 10:20 ` Lee Jones 0 siblings, 0 replies; 30+ messages in thread From: Lee Jones @ 2022-11-30 10:20 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Christoph Niedermaier, linux-kernel, Support Opensource, Rob Herring, Krzysztof Kozlowski, Marek Vasut, kernel, devicetree On Wed, 30 Nov 2022, Krzysztof Kozlowski wrote: > On 30/11/2022 11:10, Lee Jones wrote: > > On Tue, 29 Nov 2022, Krzysztof Kozlowski wrote: > > > >> On 22/11/2022 12:11, Christoph Niedermaier wrote: > >>> Replace the watchdog file name with the name currently in use. > >>> > >>> Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> > >>> --- > >>> Cc: Support Opensource <support.opensource@diasemi.com> > >>> Cc: Lee Jones <lee@kernel.org> > >>> Cc: Rob Herring <robh+dt@kernel.org> > >>> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > >>> Cc: Marek Vasut <marex@denx.de> > >>> Cc: kernel@dh-electronics.com > >>> Cc: devicetree@vger.kernel.org > >>> To: linux-kernel@vger.kernel.org > >>> --- > >>> Documentation/devicetree/bindings/mfd/da9062.txt | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt b/Documentation/devicetree/bindings/mfd/da9062.txt > >>> index bab0d0e66cb3..e96629eb9f48 100644 > >>> --- a/Documentation/devicetree/bindings/mfd/da9062.txt > >>> +++ b/Documentation/devicetree/bindings/mfd/da9062.txt > >>> @@ -85,7 +85,7 @@ Sub-nodes: > >>> > >>> - onkey : See ../input/da9062-onkey.txt > >>> > >>> -- watchdog: See ../watchdog/da9062-watchdog.txt > >>> +- watchdog: See ../watchdog/da9062-wdt.txt > >> > >> How is this related to LED patch? Don't mix threads. > > > > Que? > > > > [PATCH] dt-bindings: mfd: da9062: Correct file name for watchdog > > It's a response to a LED patch (single, not thread). Didn't show up like that of me. I guess I wasn't included on the LED patch. -- Lee Jones [李琼斯] ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [PATCH] dt-bindings: mfd: da9062: Correct file name for watchdog 2022-11-29 12:33 ` Krzysztof Kozlowski 2022-11-30 10:10 ` Lee Jones @ 2022-11-30 10:18 ` Christoph Niedermaier 1 sibling, 0 replies; 30+ messages in thread From: Christoph Niedermaier @ 2022-11-30 10:18 UTC (permalink / raw) To: Krzysztof Kozlowski, linux-kernel Cc: Support Opensource, Lee Jones, Rob Herring, Krzysztof Kozlowski, Marek Vasut, kernel, devicetree From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@linaro.org] Sent: Tuesday, November 29, 2022 1:34 PM > On 22/11/2022 12:11, Christoph Niedermaier wrote: >> Replace the watchdog file name with the name currently in use. >> >> Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> >> --- >> Cc: Support Opensource <support.opensource@diasemi.com> >> Cc: Lee Jones <lee@kernel.org> >> Cc: Rob Herring <robh+dt@kernel.org> >> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> >> Cc: Marek Vasut <marex@denx.de> >> Cc: kernel@dh-electronics.com >> Cc: devicetree@vger.kernel.org >> To: linux-kernel@vger.kernel.org >> --- >> Documentation/devicetree/bindings/mfd/da9062.txt | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt b/Documentation/devicetree/bindings/mfd/da9062.txt >> index bab0d0e66cb3..e96629eb9f48 100644 >> --- a/Documentation/devicetree/bindings/mfd/da9062.txt >> +++ b/Documentation/devicetree/bindings/mfd/da9062.txt >> @@ -85,7 +85,7 @@ Sub-nodes: >> >> - onkey : See ../input/da9062-onkey.txt >> >> -- watchdog: See ../watchdog/da9062-watchdog.txt >> +- watchdog: See ../watchdog/da9062-wdt.txt > > How is this related to LED patch? Don't mix threads. I am sorry. I used git send-email the wrong way. Thanks for pointing this out. Don't answer to this E-Mail. I will send a new patch. Regards Christoph ^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH] dt-bindings: mmc: Make comment on wakeup-source less confusing 2022-11-22 11:11 [PATCH] dt-bindings: leds: Mark label property as deprecated Christoph Niedermaier 2022-11-22 11:11 ` [PATCH] dt-bindings: mfd: da9062: Correct file name for watchdog Christoph Niedermaier @ 2022-11-22 11:11 ` Christoph Niedermaier 2022-11-29 12:06 ` Ulf Hansson 2022-11-29 12:35 ` Krzysztof Kozlowski 2022-11-22 12:23 ` [PATCH] dt-bindings: leds: Mark label property as deprecated Pavel Machek 2 siblings, 2 replies; 30+ messages in thread From: Christoph Niedermaier @ 2022-11-22 11:11 UTC (permalink / raw) To: linux-kernel Cc: Christoph Niedermaier, Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Marek Vasut, kernel, linux-mmc, devicetree The current comment on wakeup-source is a bit confusing, because it isn't clear at first sight which property is actually deprecated. Change the comment to one that is less confusing. Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> --- Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> Cc: Marek Vasut <marex@denx.de> Cc: kernel@dh-electronics.com Cc: linux-mmc@vger.kernel.org Cc: devicetree@vger.kernel.org To: linux-kernel@vger.kernel.org --- Documentation/devicetree/bindings/mmc/mmc-controller.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml index 802e3ca8be4d..a921442c6c1d 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml +++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml @@ -293,7 +293,7 @@ properties: description: SDIO only. Preserves card power during a suspend/resume cycle. - # Deprecated: enable-sdio-wakeup + # Use wakeup-source instead of the deprecated enable-sdio-wakeup wakeup-source: $ref: /schemas/types.yaml#/definitions/flag description: -- 2.11.0 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: mmc: Make comment on wakeup-source less confusing 2022-11-22 11:11 ` [PATCH] dt-bindings: mmc: Make comment on wakeup-source less confusing Christoph Niedermaier @ 2022-11-29 12:06 ` Ulf Hansson 2022-11-29 12:33 ` Krzysztof Kozlowski 2022-11-29 12:35 ` Krzysztof Kozlowski 1 sibling, 1 reply; 30+ messages in thread From: Ulf Hansson @ 2022-11-29 12:06 UTC (permalink / raw) To: Rob Herring, Krzysztof Kozlowski Cc: Christoph Niedermaier, linux-kernel, Marek Vasut, kernel, linux-mmc, devicetree On Tue, 22 Nov 2022 at 12:43, Christoph Niedermaier <cniedermaier@dh-electronics.com> wrote: > > The current comment on wakeup-source is a bit confusing, because it isn't > clear at first sight which property is actually deprecated. > Change the comment to one that is less confusing. > > Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> > --- > Cc: Ulf Hansson <ulf.hansson@linaro.org> > Cc: Rob Herring <robh+dt@kernel.org> > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > Cc: Marek Vasut <marex@denx.de> > Cc: kernel@dh-electronics.com > Cc: linux-mmc@vger.kernel.org > Cc: devicetree@vger.kernel.org > To: linux-kernel@vger.kernel.org > --- > Documentation/devicetree/bindings/mmc/mmc-controller.yaml | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml > index 802e3ca8be4d..a921442c6c1d 100644 > --- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml > +++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml > @@ -293,7 +293,7 @@ properties: > description: > SDIO only. Preserves card power during a suspend/resume cycle. > > - # Deprecated: enable-sdio-wakeup > + # Use wakeup-source instead of the deprecated enable-sdio-wakeup > wakeup-source: > $ref: /schemas/types.yaml#/definitions/flag > description: Rob, Krzysztof - do we have a preferred pattern for how to express deprecated bindings - or is the above okay to you? Kind regards Uffe ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: mmc: Make comment on wakeup-source less confusing 2022-11-29 12:06 ` Ulf Hansson @ 2022-11-29 12:33 ` Krzysztof Kozlowski 0 siblings, 0 replies; 30+ messages in thread From: Krzysztof Kozlowski @ 2022-11-29 12:33 UTC (permalink / raw) To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski Cc: Christoph Niedermaier, linux-kernel, Marek Vasut, kernel, linux-mmc, devicetree On 29/11/2022 13:06, Ulf Hansson wrote: > On Tue, 22 Nov 2022 at 12:43, Christoph Niedermaier > <cniedermaier@dh-electronics.com> wrote: >> >> The current comment on wakeup-source is a bit confusing, because it isn't >> clear at first sight which property is actually deprecated. >> Change the comment to one that is less confusing. >> >> Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> >> --- >> Cc: Ulf Hansson <ulf.hansson@linaro.org> >> Cc: Rob Herring <robh+dt@kernel.org> >> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> >> Cc: Marek Vasut <marex@denx.de> >> Cc: kernel@dh-electronics.com >> Cc: linux-mmc@vger.kernel.org >> Cc: devicetree@vger.kernel.org >> To: linux-kernel@vger.kernel.org >> --- >> Documentation/devicetree/bindings/mmc/mmc-controller.yaml | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml >> index 802e3ca8be4d..a921442c6c1d 100644 >> --- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml >> +++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml >> @@ -293,7 +293,7 @@ properties: >> description: >> SDIO only. Preserves card power during a suspend/resume cycle. >> >> - # Deprecated: enable-sdio-wakeup >> + # Use wakeup-source instead of the deprecated enable-sdio-wakeup >> wakeup-source: >> $ref: /schemas/types.yaml#/definitions/flag >> description: > > Rob, Krzysztof - do we have a preferred pattern for how to express > deprecated bindings - or is the above okay to you? Yes, we have: deprecated: true I don't get why this is in response to LED patch? I entirely ignored this thread because of it. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: mmc: Make comment on wakeup-source less confusing 2022-11-22 11:11 ` [PATCH] dt-bindings: mmc: Make comment on wakeup-source less confusing Christoph Niedermaier 2022-11-29 12:06 ` Ulf Hansson @ 2022-11-29 12:35 ` Krzysztof Kozlowski 2022-11-29 15:30 ` Ulf Hansson 1 sibling, 1 reply; 30+ messages in thread From: Krzysztof Kozlowski @ 2022-11-29 12:35 UTC (permalink / raw) To: Christoph Niedermaier, linux-kernel Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Marek Vasut, kernel, linux-mmc, devicetree On 22/11/2022 12:11, Christoph Niedermaier wrote: > The current comment on wakeup-source is a bit confusing, because it isn't > clear at first sight which property is actually deprecated. > Change the comment to one that is less confusing. It's still confusing - you mention some non-existing property. I don't think it's worth to touch it. If you insist, drop entire comment... > > Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> > --- > Cc: Ulf Hansson <ulf.hansson@linaro.org> > Cc: Rob Herring <robh+dt@kernel.org> > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > Cc: Marek Vasut <marex@denx.de> > Cc: kernel@dh-electronics.com > Cc: linux-mmc@vger.kernel.org > Cc: devicetree@vger.kernel.org > To: linux-kernel@vger.kernel.org > --- > Documentation/devicetree/bindings/mmc/mmc-controller.yaml | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml > index 802e3ca8be4d..a921442c6c1d 100644 > --- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml > +++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml > @@ -293,7 +293,7 @@ properties: > description: > SDIO only. Preserves card power during a suspend/resume cycle. > > - # Deprecated: enable-sdio-wakeup > + # Use wakeup-source instead of the deprecated enable-sdio-wakeup > wakeup-source: > $ref: /schemas/types.yaml#/definitions/flag > description: Best regards, Krzysztof ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: mmc: Make comment on wakeup-source less confusing 2022-11-29 12:35 ` Krzysztof Kozlowski @ 2022-11-29 15:30 ` Ulf Hansson 2022-11-29 15:37 ` Marek Vasut 2022-11-29 15:59 ` Krzysztof Kozlowski 0 siblings, 2 replies; 30+ messages in thread From: Ulf Hansson @ 2022-11-29 15:30 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Christoph Niedermaier, linux-kernel, Rob Herring, Krzysztof Kozlowski, Marek Vasut, kernel, linux-mmc, devicetree On Tue, 29 Nov 2022 at 13:36, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > On 22/11/2022 12:11, Christoph Niedermaier wrote: > > The current comment on wakeup-source is a bit confusing, because it isn't > > clear at first sight which property is actually deprecated. > > Change the comment to one that is less confusing. > > It's still confusing - you mention some non-existing property. I don't > think it's worth to touch it. If you insist, drop entire comment... Hmm, it doesn't look that easy to me. The "enable-sdio-wakeup" is indeed a deprecated wakeup property [1], but it seems like it's not really described somewhere. I wouldn't mind removing it (as it seems to add some confusions), but in that case it needs to be entirely removed from the DT docs, right? Another option, would be to add a proper description of the property and mark it with "deprecated: true". > > > > > Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> > > --- > > Cc: Ulf Hansson <ulf.hansson@linaro.org> > > Cc: Rob Herring <robh+dt@kernel.org> > > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > > Cc: Marek Vasut <marex@denx.de> > > Cc: kernel@dh-electronics.com > > Cc: linux-mmc@vger.kernel.org > > Cc: devicetree@vger.kernel.org > > To: linux-kernel@vger.kernel.org > > --- > > Documentation/devicetree/bindings/mmc/mmc-controller.yaml | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml > > index 802e3ca8be4d..a921442c6c1d 100644 > > --- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml > > +++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml > > @@ -293,7 +293,7 @@ properties: > > description: > > SDIO only. Preserves card power during a suspend/resume cycle. > > > > - # Deprecated: enable-sdio-wakeup > > + # Use wakeup-source instead of the deprecated enable-sdio-wakeup > > wakeup-source: > > $ref: /schemas/types.yaml#/definitions/flag > > description: Kind regards Uffe [1] Documentation/devicetree/bindings/power/wakeup-source.txt ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: mmc: Make comment on wakeup-source less confusing 2022-11-29 15:30 ` Ulf Hansson @ 2022-11-29 15:37 ` Marek Vasut 2022-11-29 15:59 ` Krzysztof Kozlowski 1 sibling, 0 replies; 30+ messages in thread From: Marek Vasut @ 2022-11-29 15:37 UTC (permalink / raw) To: Ulf Hansson, Krzysztof Kozlowski Cc: Christoph Niedermaier, linux-kernel, Rob Herring, Krzysztof Kozlowski, kernel, linux-mmc, devicetree On 11/29/22 16:30, Ulf Hansson wrote: > On Tue, 29 Nov 2022 at 13:36, Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> wrote: >> >> On 22/11/2022 12:11, Christoph Niedermaier wrote: >>> The current comment on wakeup-source is a bit confusing, because it isn't >>> clear at first sight which property is actually deprecated. >>> Change the comment to one that is less confusing. >> >> It's still confusing - you mention some non-existing property. I don't >> think it's worth to touch it. If you insist, drop entire comment... > > Hmm, it doesn't look that easy to me. The "enable-sdio-wakeup" is > indeed a deprecated wakeup property [1], but it seems like it's not > really described somewhere. I wouldn't mind removing it (as it seems > to add some confusions), but in that case it needs to be entirely > removed from the DT docs, right? > > Another option, would be to add a proper description of the property > and mark it with "deprecated: true". There are no in-tree DTs which use the property, so maybe we should just drop it altogether from the bindings ? next-20221128$ git grep enable-sdio-wakeup Documentation/devicetree/bindings/mmc/mmc-controller.yaml: # Deprecated: enable-sdio-wakeup Documentation/devicetree/bindings/power/wakeup-source.txt:1. "enable-sdio-wakeup" Documentation/devicetree/bindings/mmc/mmc.txt drivers/mmc/core/host.c: device_property_read_bool(dev, "enable-sdio-wakeup")) /* legacy */ drivers/mmc/host/sdhci-pltfm.c: device_property_read_bool(dev, "enable-sdio-wakeup")) /* legacy */ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: mmc: Make comment on wakeup-source less confusing 2022-11-29 15:30 ` Ulf Hansson 2022-11-29 15:37 ` Marek Vasut @ 2022-11-29 15:59 ` Krzysztof Kozlowski 1 sibling, 0 replies; 30+ messages in thread From: Krzysztof Kozlowski @ 2022-11-29 15:59 UTC (permalink / raw) To: Ulf Hansson Cc: Christoph Niedermaier, linux-kernel, Rob Herring, Krzysztof Kozlowski, Marek Vasut, kernel, linux-mmc, devicetree On 29/11/2022 16:30, Ulf Hansson wrote: > On Tue, 29 Nov 2022 at 13:36, Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> wrote: >> >> On 22/11/2022 12:11, Christoph Niedermaier wrote: >>> The current comment on wakeup-source is a bit confusing, because it isn't >>> clear at first sight which property is actually deprecated. >>> Change the comment to one that is less confusing. >> >> It's still confusing - you mention some non-existing property. I don't >> think it's worth to touch it. If you insist, drop entire comment... > > Hmm, it doesn't look that easy to me. The "enable-sdio-wakeup" is > indeed a deprecated wakeup property [1], but it seems like it's not > really described somewhere. I wouldn't mind removing it (as it seems > to add some confusions), but in that case it needs to be entirely > removed from the DT docs, right? Yes, from the bindings and from DTSes. It's already gone from mmc-controller.yaml bindings, so basically we already did the most of such removal. > > Another option, would be to add a proper description of the property > and mark it with "deprecated: true". Best regards, Krzysztof ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: leds: Mark label property as deprecated 2022-11-22 11:11 [PATCH] dt-bindings: leds: Mark label property as deprecated Christoph Niedermaier 2022-11-22 11:11 ` [PATCH] dt-bindings: mfd: da9062: Correct file name for watchdog Christoph Niedermaier 2022-11-22 11:11 ` [PATCH] dt-bindings: mmc: Make comment on wakeup-source less confusing Christoph Niedermaier @ 2022-11-22 12:23 ` Pavel Machek 2022-11-25 21:26 ` Marek Vasut 2 siblings, 1 reply; 30+ messages in thread From: Pavel Machek @ 2022-11-22 12:23 UTC (permalink / raw) To: Christoph Niedermaier Cc: linux-kernel, Rob Herring, Krzysztof Kozlowski, Jacek Anaszewski, Marek Vasut, kernel, linux-leds, devicetree [-- Attachment #1: Type: text/plain, Size: 709 bytes --] Hi! > Mark the label property as deprecated as it is mentioned > in the description. Lets do it the other way around. Functions (etc) don't really provide good enough description of LED, and label is still needed. Best regards, Pavel > +++ b/Documentation/devicetree/bindings/leds/common.yaml > @@ -52,6 +52,7 @@ properties: > $ref: /schemas/types.yaml#/definitions/uint32 > > label: > + deprecated: true > description: > The label for this LED. If omitted, the label is taken from the node name > (excluding the unit address). It has to uniquely identify a device, i.e. -- People of Russia, stop Putin before his war on Ukraine escalates. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: leds: Mark label property as deprecated 2022-11-22 12:23 ` [PATCH] dt-bindings: leds: Mark label property as deprecated Pavel Machek @ 2022-11-25 21:26 ` Marek Vasut 2022-11-29 9:03 ` Christoph Niedermaier 2022-11-30 19:19 ` Rob Herring 0 siblings, 2 replies; 30+ messages in thread From: Marek Vasut @ 2022-11-25 21:26 UTC (permalink / raw) To: Pavel Machek, Christoph Niedermaier Cc: linux-kernel, Rob Herring, Krzysztof Kozlowski, Jacek Anaszewski, kernel, linux-leds, devicetree On 11/22/22 13:23, Pavel Machek wrote: > Hi! Hi, >> Mark the label property as deprecated as it is mentioned >> in the description. > > Lets do it the other way around. Functions (etc) don't really provide > good enough description of LED, and label is still needed. Can you please provide a clear explanation which property or approach is the correct one for new DTs ? So far, the documentation states that "label" is deprecated, and users should replace it with "function" and "color". ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [PATCH] dt-bindings: leds: Mark label property as deprecated 2022-11-25 21:26 ` Marek Vasut @ 2022-11-29 9:03 ` Christoph Niedermaier 2022-11-30 19:19 ` Rob Herring 1 sibling, 0 replies; 30+ messages in thread From: Christoph Niedermaier @ 2022-11-29 9:03 UTC (permalink / raw) To: Marek Vasut, Pavel Machek Cc: linux-kernel, Rob Herring, Krzysztof Kozlowski, Jacek Anaszewski, kernel, linux-leds, devicetree From: Marek Vasut [mailto:marex@denx.de] Sent: Friday, November 25, 2022 10:27 PM > On 11/22/22 13:23, Pavel Machek wrote: >> Hi! > > Hi, > Hi, >>> Mark the label property as deprecated as it is mentioned >>> in the description. >> >> Lets do it the other way around. Functions (etc) don't really provide >> good enough description of LED, and label is still needed. > > Can you please provide a clear explanation which property or approach is > the correct one for new DTs ? > > So far, the documentation states that "label" is deprecated, and users > should replace it with "function" and "color". I'm a little confused because the direction seems to have changed here. Do you want label and functions (etc.) to be able to be used equally side by side, or should one of them be preferred? I also do DTs and it would be good to know what to go for. Could you please provide further explanation? Regards Christoph ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: leds: Mark label property as deprecated 2022-11-25 21:26 ` Marek Vasut 2022-11-29 9:03 ` Christoph Niedermaier @ 2022-11-30 19:19 ` Rob Herring 2022-11-30 19:26 ` Pavel Machek 2022-12-01 23:41 ` Marek Vasut 1 sibling, 2 replies; 30+ messages in thread From: Rob Herring @ 2022-11-30 19:19 UTC (permalink / raw) To: Marek Vasut Cc: Pavel Machek, Christoph Niedermaier, linux-kernel, Krzysztof Kozlowski, Jacek Anaszewski, kernel, linux-leds, devicetree On Fri, Nov 25, 2022 at 10:26:30PM +0100, Marek Vasut wrote: > On 11/22/22 13:23, Pavel Machek wrote: > > Hi! > > Hi, > > > > Mark the label property as deprecated as it is mentioned > > > in the description. > > > > Lets do it the other way around. Functions (etc) don't really provide > > good enough description of LED, and label is still needed. > > Can you please provide a clear explanation which property or approach is the > correct one for new DTs ? > > So far, the documentation states that "label" is deprecated, and users > should replace it with "function" and "color". 'function' is what activity/operation the LED is associated with. It is a fixed set of strings which s/w may use. It is a replacement for 'linux,default-trigger'. 'label' is what is printed next to the LED for a human to read. 'label' can be anything and the OS shouldn't care what it is. They serve 2 different purposes. Rob ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: leds: Mark label property as deprecated 2022-11-30 19:19 ` Rob Herring @ 2022-11-30 19:26 ` Pavel Machek 2022-12-01 21:47 ` Rob Herring 2022-12-01 23:44 ` Marek Vasut 2022-12-01 23:41 ` Marek Vasut 1 sibling, 2 replies; 30+ messages in thread From: Pavel Machek @ 2022-11-30 19:26 UTC (permalink / raw) To: Rob Herring Cc: Marek Vasut, Christoph Niedermaier, linux-kernel, Krzysztof Kozlowski, Jacek Anaszewski, kernel, linux-leds, devicetree [-- Attachment #1: Type: text/plain, Size: 1412 bytes --] On Wed 2022-11-30 13:19:05, Rob Herring wrote: > On Fri, Nov 25, 2022 at 10:26:30PM +0100, Marek Vasut wrote: > > On 11/22/22 13:23, Pavel Machek wrote: > > > Hi! > > > > Hi, > > > > > > Mark the label property as deprecated as it is mentioned > > > > in the description. > > > > > > Lets do it the other way around. Functions (etc) don't really provide > > > good enough description of LED, and label is still needed. > > > > Can you please provide a clear explanation which property or approach is the > > correct one for new DTs ? > > > > So far, the documentation states that "label" is deprecated, and users > > should replace it with "function" and "color". > > 'function' is what activity/operation the LED is associated with. It is > a fixed set of strings which s/w may use. It is a replacement for > 'linux,default-trigger'. > > 'label' is what is printed next to the LED for a human to read. 'label' > can be anything and the OS shouldn't care what it is. Unfortunately, no. We use label as a path in /sys/class/leds. And it looks like integer "function" is not really adequate for describing what LED does. There are too many LEDs and not enough integers, and it is common to have same function ("activity") on multiple devices ("wifi", "mmc", "eth"). Best regards, Pavel -- People of Russia, stop Putin before his war on Ukraine escalates. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: leds: Mark label property as deprecated 2022-11-30 19:26 ` Pavel Machek @ 2022-12-01 21:47 ` Rob Herring 2022-12-02 9:25 ` Pavel Machek 2022-12-01 23:44 ` Marek Vasut 1 sibling, 1 reply; 30+ messages in thread From: Rob Herring @ 2022-12-01 21:47 UTC (permalink / raw) To: Pavel Machek Cc: Marek Vasut, Christoph Niedermaier, linux-kernel, Krzysztof Kozlowski, Jacek Anaszewski, kernel, linux-leds, devicetree On Wed, Nov 30, 2022 at 1:27 PM Pavel Machek <pavel@ucw.cz> wrote: > > On Wed 2022-11-30 13:19:05, Rob Herring wrote: > > On Fri, Nov 25, 2022 at 10:26:30PM +0100, Marek Vasut wrote: > > > On 11/22/22 13:23, Pavel Machek wrote: > > > > Hi! > > > > > > Hi, > > > > > > > > Mark the label property as deprecated as it is mentioned > > > > > in the description. > > > > > > > > Lets do it the other way around. Functions (etc) don't really provide > > > > good enough description of LED, and label is still needed. > > > > > > Can you please provide a clear explanation which property or approach is the > > > correct one for new DTs ? > > > > > > So far, the documentation states that "label" is deprecated, and users > > > should replace it with "function" and "color". > > > > 'function' is what activity/operation the LED is associated with. It is > > a fixed set of strings which s/w may use. It is a replacement for > > 'linux,default-trigger'. > > > > 'label' is what is printed next to the LED for a human to read. 'label' > > can be anything and the OS shouldn't care what it is. > > Unfortunately, no. That's why I said 'shouldn't care', not 'doesn't care'. 'label' is also not just an LED property. It's used elsewhere, but unfortunately the LED subsystem makes more use of it than it perhaps should. > We use label as a path in /sys/class/leds. Yes, or node name if no label. That's still not really caring what the value of label is. At least the kernel doesn't. A well behaved userspace wouldn't either and doesn't for most classes. > And it looks like integer > "function" is not really adequate for describing what LED does. There > are too many LEDs and not enough integers, and it is common to have > same function ("activity") on multiple devices ("wifi", "mmc", "eth"). Whatever the problems are, 'label' is not the solution. There is a way to associate leds with devices. 'trigger-source' IIRC. Rob ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: leds: Mark label property as deprecated 2022-12-01 21:47 ` Rob Herring @ 2022-12-02 9:25 ` Pavel Machek 0 siblings, 0 replies; 30+ messages in thread From: Pavel Machek @ 2022-12-02 9:25 UTC (permalink / raw) To: Rob Herring Cc: Marek Vasut, Christoph Niedermaier, linux-kernel, Krzysztof Kozlowski, Jacek Anaszewski, kernel, linux-leds, devicetree [-- Attachment #1: Type: text/plain, Size: 1743 bytes --] Hi! > > > > So far, the documentation states that "label" is deprecated, and users > > > > should replace it with "function" and "color". > > > > > > 'function' is what activity/operation the LED is associated with. It is > > > a fixed set of strings which s/w may use. It is a replacement for > > > 'linux,default-trigger'. > > > > > > 'label' is what is printed next to the LED for a human to read. 'label' > > > can be anything and the OS shouldn't care what it is. > > > > Unfortunately, no. > > That's why I said 'shouldn't care', not 'doesn't care'. > > 'label' is also not just an LED property. It's used elsewhere, but > unfortunately the LED subsystem makes more use of it than it perhaps > should. > > > We use label as a path in /sys/class/leds. > > Yes, or node name if no label. That's still not really caring what the > value of label is. At least the kernel doesn't. A well behaved > userspace wouldn't either and doesn't for most classes. A well behaved userspace needs that to tell what kind of LED it is. It is important to tell keyboard backlight from HDD activity LED and from fllash on back camera for example. > > And it looks like integer > > "function" is not really adequate for describing what LED does. There > > are too many LEDs and not enough integers, and it is common to have > > same function ("activity") on multiple devices ("wifi", "mmc", "eth"). > > Whatever the problems are, 'label' is not the solution. > > There is a way to associate leds with devices. 'trigger-source' > IIRC. Neither is trigger-source a solution. Can we have linux,sysfs-path or something? Pavel -- People of Russia, stop Putin before his war on Ukraine escalates. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: leds: Mark label property as deprecated 2022-11-30 19:26 ` Pavel Machek 2022-12-01 21:47 ` Rob Herring @ 2022-12-01 23:44 ` Marek Vasut 1 sibling, 0 replies; 30+ messages in thread From: Marek Vasut @ 2022-12-01 23:44 UTC (permalink / raw) To: Pavel Machek, Rob Herring Cc: Christoph Niedermaier, linux-kernel, Krzysztof Kozlowski, Jacek Anaszewski, kernel, linux-leds, devicetree On 11/30/22 20:26, Pavel Machek wrote: > On Wed 2022-11-30 13:19:05, Rob Herring wrote: >> On Fri, Nov 25, 2022 at 10:26:30PM +0100, Marek Vasut wrote: >>> On 11/22/22 13:23, Pavel Machek wrote: >>>> Hi! >>> >>> Hi, >>> >>>>> Mark the label property as deprecated as it is mentioned >>>>> in the description. >>>> >>>> Lets do it the other way around. Functions (etc) don't really provide >>>> good enough description of LED, and label is still needed. >>> >>> Can you please provide a clear explanation which property or approach is the >>> correct one for new DTs ? >>> >>> So far, the documentation states that "label" is deprecated, and users >>> should replace it with "function" and "color". >> >> 'function' is what activity/operation the LED is associated with. It is >> a fixed set of strings which s/w may use. It is a replacement for >> 'linux,default-trigger'. >> >> 'label' is what is printed next to the LED for a human to read. 'label' >> can be anything and the OS shouldn't care what it is. > > Unfortunately, no. > > We use label as a path in /sys/class/leds. And it looks like integer > "function" is not really adequate for describing what LED does. There > are too many LEDs and not enough integers, and it is common to have > same function ("activity") on multiple devices ("wifi", "mmc", "eth"). The Documentation/devicetree/bindings/leds/common.yaml schema indicates that function is a string, not an integer: " 32 function: 33 description: 34 LED function. Use one of the LED_FUNCTION_* prefixed definitions 35 from the header include/dt-bindings/leds/common.h. If there is no 36 matching LED_FUNCTION available, add a new one. 37 $ref: /schemas/types.yaml#/definitions/string " ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: leds: Mark label property as deprecated 2022-11-30 19:19 ` Rob Herring 2022-11-30 19:26 ` Pavel Machek @ 2022-12-01 23:41 ` Marek Vasut 2022-12-05 18:44 ` Jacek Anaszewski 1 sibling, 1 reply; 30+ messages in thread From: Marek Vasut @ 2022-12-01 23:41 UTC (permalink / raw) To: Rob Herring Cc: Pavel Machek, Christoph Niedermaier, linux-kernel, Krzysztof Kozlowski, Jacek Anaszewski, kernel, linux-leds, devicetree On 11/30/22 20:19, Rob Herring wrote: > On Fri, Nov 25, 2022 at 10:26:30PM +0100, Marek Vasut wrote: >> On 11/22/22 13:23, Pavel Machek wrote: >>> Hi! >> >> Hi, >> >>>> Mark the label property as deprecated as it is mentioned >>>> in the description. >>> >>> Lets do it the other way around. Functions (etc) don't really provide >>> good enough description of LED, and label is still needed. >> >> Can you please provide a clear explanation which property or approach is the >> correct one for new DTs ? >> >> So far, the documentation states that "label" is deprecated, and users >> should replace it with "function" and "color". > > 'function' is what activity/operation the LED is associated with. It is > a fixed set of strings which s/w may use. It is a replacement for > 'linux,default-trigger'. Isn't this 'function' more of a standardized replacement for 'label' ? $ git grep LED_FUNCTION_ include/ ... include/dt-bindings/leds/common.h:#define LED_FUNCTION_PLAYER5 "player-5" include/dt-bindings/leds/common.h:#define LED_FUNCTION_ACTIVITY "activity" include/dt-bindings/leds/common.h:#define LED_FUNCTION_ALARM "alarm" include/dt-bindings/leds/common.h:#define LED_FUNCTION_BACKLIGHT "backlight" include/dt-bindings/leds/common.h:#define LED_FUNCTION_BLUETOOTH "bluetooth" include/dt-bindings/leds/common.h:#define LED_FUNCTION_BOOT "boot" ... Seems to me that ^ is closer to a "standardized" form of 'label' . The LED subsystem does not infer any behavior of those LEDs based on their 'function' property as far as I can tell, at least not in the way 'linux,default-trigger' behaves. > 'label' is what is printed next to the LED for a human to read. 'label' > can be anything and the OS shouldn't care what it is. This part I understand. What is not clear to me is, why is 'label' being un-deprecated. We newly have 'function', 'function-enumerator' and 'color' DT properties for LEDs, which seem to be standardized forms of describing what the LED is used for, which LED it is (if there are multiple), and color of that LED. This was previously described in the 'label' property, usually in free form of e.g. "beaglebone:green:usr2" . > They serve 2 different purposes. [...] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: leds: Mark label property as deprecated 2022-12-01 23:41 ` Marek Vasut @ 2022-12-05 18:44 ` Jacek Anaszewski 2022-12-22 9:36 ` Christoph Niedermaier 0 siblings, 1 reply; 30+ messages in thread From: Jacek Anaszewski @ 2022-12-05 18:44 UTC (permalink / raw) To: Marek Vasut, Rob Herring Cc: Pavel Machek, Christoph Niedermaier, linux-kernel, Krzysztof Kozlowski, kernel, linux-leds, devicetree Hi all, On 12/2/22 00:41, Marek Vasut wrote: > On 11/30/22 20:19, Rob Herring wrote: >> On Fri, Nov 25, 2022 at 10:26:30PM +0100, Marek Vasut wrote: >>> On 11/22/22 13:23, Pavel Machek wrote: >>>> Hi! >>> >>> Hi, >>> >>>>> Mark the label property as deprecated as it is mentioned >>>>> in the description. >>>> >>>> Lets do it the other way around. Functions (etc) don't really provide >>>> good enough description of LED, and label is still needed. >>> >>> Can you please provide a clear explanation which property or approach >>> is the >>> correct one for new DTs ? >>> >>> So far, the documentation states that "label" is deprecated, and users >>> should replace it with "function" and "color". >> >> 'function' is what activity/operation the LED is associated with. It is >> a fixed set of strings which s/w may use. It is a replacement for >> 'linux,default-trigger'. > > Isn't this 'function' more of a standardized replacement for 'label' ? Yes it is. Introduction of function and color properties aimed at standardizing LED naming. Before there was only 'label' used for that, with DT node name as fallback if 'label' property was not provided. With introduction of 'function' and 'color' label was deprecated in the sense that if the former two are present, they are used for composing the LED name. In LED documentation [0] people are encouraged to use definitions from include/dt-bindings/leds/common.h to keep LED naming uniform. It allows to avoid duplicates like "wlan" and "wifi". > $ git grep LED_FUNCTION_ include/ > ... > include/dt-bindings/leds/common.h:#define LED_FUNCTION_PLAYER5 "player-5" > include/dt-bindings/leds/common.h:#define LED_FUNCTION_ACTIVITY "activity" > include/dt-bindings/leds/common.h:#define LED_FUNCTION_ALARM "alarm" > include/dt-bindings/leds/common.h:#define LED_FUNCTION_BACKLIGHT > "backlight" > include/dt-bindings/leds/common.h:#define LED_FUNCTION_BLUETOOTH > "bluetooth" > include/dt-bindings/leds/common.h:#define LED_FUNCTION_BOOT "boot" > ... > > Seems to me that ^ is closer to a "standardized" form of 'label' . > > The LED subsystem does not infer any behavior of those LEDs based on > their 'function' property as far as I can tell, at least not in the way > 'linux,default-trigger' behaves. > >> 'label' is what is printed next to the LED for a human to read. 'label' >> can be anything and the OS shouldn't care what it is. > > This part I understand. What is not clear to me is, why is 'label' being > un-deprecated. It shouldn't be. It seems to be Pavel's ad-hoc decision. > We newly have 'function', 'function-enumerator' and 'color' DT > properties for LEDs, which seem to be standardized forms of describing > what the LED is used for, which LED it is (if there are multiple), and > color of that LED. This was previously described in the 'label' > property, usually in free form of e.g. "beaglebone:green:usr2" . > >> They serve 2 different purposes. > > [...] [0] Documentation/leds/leds-class.rst -- Best regards, Jacek Anaszewski ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [PATCH] dt-bindings: leds: Mark label property as deprecated 2022-12-05 18:44 ` Jacek Anaszewski @ 2022-12-22 9:36 ` Christoph Niedermaier 2022-12-22 13:50 ` Pavel Machek 0 siblings, 1 reply; 30+ messages in thread From: Christoph Niedermaier @ 2022-12-22 9:36 UTC (permalink / raw) To: Jacek Anaszewski, Marek Vasut, Rob Herring, Pavel Machek Cc: linux-kernel, Krzysztof Kozlowski, kernel, linux-leds, devicetree From: Jacek Anaszewski [mailto:jacek.anaszewski@gmail.com] Sent: Monday, December 5, 2022 7:44 PM > > Hi all, > Hi all, > On 12/2/22 00:41, Marek Vasut wrote: >> On 11/30/22 20:19, Rob Herring wrote: >>> On Fri, Nov 25, 2022 at 10:26:30PM +0100, Marek Vasut wrote: >>>> On 11/22/22 13:23, Pavel Machek wrote: >>>>> Hi! >>>> >>>> Hi, >>>> >>>>>> Mark the label property as deprecated as it is mentioned >>>>>> in the description. >>>>> >>>>> Lets do it the other way around. Functions (etc) don't really provide >>>>> good enough description of LED, and label is still needed. >>>> >>>> Can you please provide a clear explanation which property or approach >>>> is the >>>> correct one for new DTs ? >>>> >>>> So far, the documentation states that "label" is deprecated, and users >>>> should replace it with "function" and "color". >>> >>> 'function' is what activity/operation the LED is associated with. It is >>> a fixed set of strings which s/w may use. It is a replacement for >>> 'linux,default-trigger'. >> >> Isn't this 'function' more of a standardized replacement for 'label' ? > > Yes it is. Introduction of function and color properties aimed at > standardizing LED naming. Before there was only 'label' used for that, > with DT node name as fallback if 'label' property was not provided. > With introduction of 'function' and 'color' label was deprecated in > the sense that if the former two are present, they are used for > composing the LED name. > > In LED documentation [0] people are encouraged to use definitions from > include/dt-bindings/leds/common.h to keep LED naming uniform. > It allows to avoid duplicates like "wlan" and "wifi". > >> $ git grep LED_FUNCTION_ include/ >> ... >> include/dt-bindings/leds/common.h:#define LED_FUNCTION_PLAYER5 "player-5" >> include/dt-bindings/leds/common.h:#define LED_FUNCTION_ACTIVITY "activity" >> include/dt-bindings/leds/common.h:#define LED_FUNCTION_ALARM "alarm" >> include/dt-bindings/leds/common.h:#define LED_FUNCTION_BACKLIGHT >> "backlight" >> include/dt-bindings/leds/common.h:#define LED_FUNCTION_BLUETOOTH >> "bluetooth" >> include/dt-bindings/leds/common.h:#define LED_FUNCTION_BOOT "boot" >> ... >> >> Seems to me that ^ is closer to a "standardized" form of 'label' . >> >> The LED subsystem does not infer any behavior of those LEDs based on >> their 'function' property as far as I can tell, at least not in the way >> 'linux,default-trigger' behaves. >> >>> 'label' is what is printed next to the LED for a human to read. 'label' >>> can be anything and the OS shouldn't care what it is. >> >> This part I understand. What is not clear to me is, why is 'label' being >> un-deprecated. > > It shouldn't be. It seems to be Pavel's ad-hoc decision. Is there a majority agreement that the "label" property remains deprecated? If so, I would say we can mark the label as deprecated. On the other hand, the new generated standardized sysfs name does not seem to provide a full replacement for the "label" property. What is still missing? How can the current state be extended to find more acceptance? [...] Regards Christoph ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: leds: Mark label property as deprecated 2022-12-22 9:36 ` Christoph Niedermaier @ 2022-12-22 13:50 ` Pavel Machek 2022-12-22 14:01 ` Marek Vasut 0 siblings, 1 reply; 30+ messages in thread From: Pavel Machek @ 2022-12-22 13:50 UTC (permalink / raw) To: Christoph Niedermaier Cc: Jacek Anaszewski, Marek Vasut, Rob Herring, linux-kernel, Krzysztof Kozlowski, kernel, linux-leds, devicetree [-- Attachment #1: Type: text/plain, Size: 756 bytes --] Hi! > >> This part I understand. What is not clear to me is, why is 'label' being > >> un-deprecated. > > > > It shouldn't be. It seems to be Pavel's ad-hoc decision. > > Is there a majority agreement that the "label" property remains > deprecated? > If so, I would say we can mark the label as deprecated. > > On the other hand, the new generated standardized sysfs name does not seem > to provide a full replacement for the "label" property. > What is still missing? Having reasonable naming of the LEDs is pre-requisite for deprecating label property. And no, kernel community does not operate by "majority agreement"s. Best regards, Pavel -- People of Russia, stop Putin before his war on Ukraine escalates. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: leds: Mark label property as deprecated 2022-12-22 13:50 ` Pavel Machek @ 2022-12-22 14:01 ` Marek Vasut 2022-12-22 14:56 ` Pavel Machek 0 siblings, 1 reply; 30+ messages in thread From: Marek Vasut @ 2022-12-22 14:01 UTC (permalink / raw) To: Pavel Machek, Christoph Niedermaier Cc: Jacek Anaszewski, Rob Herring, linux-kernel, Krzysztof Kozlowski, kernel, linux-leds, devicetree On 12/22/22 14:50, Pavel Machek wrote: > Hi! > >>>> This part I understand. What is not clear to me is, why is 'label' being >>>> un-deprecated. >>> >>> It shouldn't be. It seems to be Pavel's ad-hoc decision. >> >> Is there a majority agreement that the "label" property remains >> deprecated? > > >> If so, I would say we can mark the label as deprecated. >> >> On the other hand, the new generated standardized sysfs name does not seem >> to provide a full replacement for the "label" property. >> What is still missing? > > Having reasonable naming of the LEDs is pre-requisite for deprecating > label property. As far as I can tell, function and function-enumerator is the reasonable naming. Jacek seem to confirm that. I would say, label can be deprecated . What is the counter-argument for why it should NOT be deprecated ? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: leds: Mark label property as deprecated 2022-12-22 14:01 ` Marek Vasut @ 2022-12-22 14:56 ` Pavel Machek 2022-12-22 15:21 ` Marek Vasut 0 siblings, 1 reply; 30+ messages in thread From: Pavel Machek @ 2022-12-22 14:56 UTC (permalink / raw) To: Marek Vasut Cc: Christoph Niedermaier, Jacek Anaszewski, Rob Herring, linux-kernel, Krzysztof Kozlowski, kernel, linux-leds, devicetree [-- Attachment #1: Type: text/plain, Size: 1204 bytes --] On Thu 2022-12-22 15:01:44, Marek Vasut wrote: > On 12/22/22 14:50, Pavel Machek wrote: > > Hi! > > > > > > > This part I understand. What is not clear to me is, why is 'label' being > > > > > un-deprecated. > > > > > > > > It shouldn't be. It seems to be Pavel's ad-hoc decision. > > > > > > Is there a majority agreement that the "label" property remains > > > deprecated? > > > > > > > If so, I would say we can mark the label as deprecated. > > > > > > On the other hand, the new generated standardized sysfs name does not seem > > > to provide a full replacement for the "label" property. > > > What is still missing? > > > > Having reasonable naming of the LEDs is pre-requisite for deprecating > > label property. > > As far as I can tell, function and function-enumerator is the reasonable > naming. Jacek seem to confirm that. I would say, label can be deprecated . > What is the counter-argument for why it should NOT be deprecated ? When the label is no longer neccessary for naming leds, it can be deprecated. AFAICT, that is currently not the case. Best regards, Pavel -- People of Russia, stop Putin before his war on Ukraine escalates. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] dt-bindings: leds: Mark label property as deprecated 2022-12-22 14:56 ` Pavel Machek @ 2022-12-22 15:21 ` Marek Vasut 0 siblings, 0 replies; 30+ messages in thread From: Marek Vasut @ 2022-12-22 15:21 UTC (permalink / raw) To: Pavel Machek Cc: Christoph Niedermaier, Jacek Anaszewski, Rob Herring, linux-kernel, Krzysztof Kozlowski, kernel, linux-leds, devicetree On 12/22/22 15:56, Pavel Machek wrote: > On Thu 2022-12-22 15:01:44, Marek Vasut wrote: >> On 12/22/22 14:50, Pavel Machek wrote: >>> Hi! >>> >>>>>> This part I understand. What is not clear to me is, why is 'label' being >>>>>> un-deprecated. >>>>> >>>>> It shouldn't be. It seems to be Pavel's ad-hoc decision. >>>> >>>> Is there a majority agreement that the "label" property remains >>>> deprecated? >>> >>> >>>> If so, I would say we can mark the label as deprecated. >>>> >>>> On the other hand, the new generated standardized sysfs name does not seem >>>> to provide a full replacement for the "label" property. >>>> What is still missing? >>> >>> Having reasonable naming of the LEDs is pre-requisite for deprecating >>> label property. >> >> As far as I can tell, function and function-enumerator is the reasonable >> naming. Jacek seem to confirm that. I would say, label can be deprecated . >> What is the counter-argument for why it should NOT be deprecated ? > > When the label is no longer neccessary for naming leds, it can be > deprecated. AFAICT, that is currently not the case. I'm sorry, this is not a counter-argument, this is hand-waving . Do you have anything to back your claim that the label is currently still needed, contrary to what the DT bindings document claims for years? "This property is deprecated - use 'function' and 'color' properties instead. function-enumerator has no effect when this property is present." " commit c5d18dd6b64e09dd6984bda9bdd55160af537a8c Date: Sun Jun 9 20:19:04 2019 +0200 dt-bindings: leds: Add properties for LED name construction Introduce dedicated properties for conveying information about LED function and color. Mark old "label" property as deprecated. Additionally function-enumerator property is being provided for the cases when neither function nor color can be used for LED differentiation. " It seems the function and function-enumerator is very much the replacement for label, except standardized. If that's not the case, do elaborate. If there is a special case that is not covered by it, do point it out. ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2022-12-22 15:22 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-11-22 11:11 [PATCH] dt-bindings: leds: Mark label property as deprecated Christoph Niedermaier 2022-11-22 11:11 ` [PATCH] dt-bindings: mfd: da9062: Correct file name for watchdog Christoph Niedermaier 2022-11-29 12:33 ` Krzysztof Kozlowski 2022-11-30 10:10 ` Lee Jones 2022-11-30 10:13 ` kernel 2022-11-30 10:19 ` Krzysztof Kozlowski 2022-11-30 10:20 ` Lee Jones 2022-11-30 10:18 ` Christoph Niedermaier 2022-11-22 11:11 ` [PATCH] dt-bindings: mmc: Make comment on wakeup-source less confusing Christoph Niedermaier 2022-11-29 12:06 ` Ulf Hansson 2022-11-29 12:33 ` Krzysztof Kozlowski 2022-11-29 12:35 ` Krzysztof Kozlowski 2022-11-29 15:30 ` Ulf Hansson 2022-11-29 15:37 ` Marek Vasut 2022-11-29 15:59 ` Krzysztof Kozlowski 2022-11-22 12:23 ` [PATCH] dt-bindings: leds: Mark label property as deprecated Pavel Machek 2022-11-25 21:26 ` Marek Vasut 2022-11-29 9:03 ` Christoph Niedermaier 2022-11-30 19:19 ` Rob Herring 2022-11-30 19:26 ` Pavel Machek 2022-12-01 21:47 ` Rob Herring 2022-12-02 9:25 ` Pavel Machek 2022-12-01 23:44 ` Marek Vasut 2022-12-01 23:41 ` Marek Vasut 2022-12-05 18:44 ` Jacek Anaszewski 2022-12-22 9:36 ` Christoph Niedermaier 2022-12-22 13:50 ` Pavel Machek 2022-12-22 14:01 ` Marek Vasut 2022-12-22 14:56 ` Pavel Machek 2022-12-22 15:21 ` Marek Vasut
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.