devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: "Rafał Miłecki" <zajec5@gmail.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	devicetree@vger.kernel.org
Cc: linux-leds@vger.kernel.org, openwrt-devel@lists.openwrt.org,
	"Rafał Miłecki" <rafal@milecki.pl>
Subject: Re: [PATCH dt-schema] schemas: chosen: Add OpenWrt LEDs properties for system states
Date: Tue, 9 Jan 2024 10:02:02 +0100	[thread overview]
Message-ID: <1b90c50c-0a09-4627-83cd-1794dae7ed9b@linaro.org> (raw)
In-Reply-To: <20240109082312.9989-1-zajec5@gmail.com>

On 09/01/2024 09:23, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
> 
> OpenWrt project provides downstream support for thousands of embedded
> home network devices. Its custom requirement for DT is to provide info
> about LEDs roles. Currently it does it by using custom non-documented
> aliases. While formally valid (aliases.yaml doesn't limit names or
> purposes of aliases) it's quite a loose solution.
> 
> Document 4 precise "chosen" biding properties with clearly documented
> OpenWrt usage. This will allow upstreaming tons of DTS files that noone

typo: none

> cared about so far as those would need to be patched downstream anyway.

From all this description I understand why you want to add it, but I
don't understand what are you exactly adding and how it is being used by
the users/OS.

> 
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> A few weeks ago I was seeking for a help regarding OpenWrt's need for
> specifing LEDs roles in DT, see:
> 
> Describing LEDs roles in device tree?
> https://lore.kernel.org/linux-devicetree/ee912a89-4fd7-43c3-a79b-16659a035fe1@gmail.com/T/#u
> 
> I DON'T think OpenWrt's current solution with aliases is good enough:
> * It's not clearly documented
> * It may vary from other projects usa case
> * It may be refused by random maintainers I think
> 
> I decided to suggest 4 OpenWrt-prefixed properties for "chosen". I'm
> hoping this small custom binding is sth we could go with. I'm really
> looking forward to upstreaming OpenWrt's downstream DTS files so other
> projects (e.g. Buildroot) can use them.
> 
> If you have any better fitting solution in mind please let me know. I
> should be fine with anything that lets me solve this downstream mess
> situation.
> 
>  dtschema/schemas/chosen.yaml | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/dtschema/schemas/chosen.yaml b/dtschema/schemas/chosen.yaml
> index 6d5c3f1..96d0db7 100644
> --- a/dtschema/schemas/chosen.yaml
> +++ b/dtschema/schemas/chosen.yaml
> @@ -264,4 +264,13 @@ properties:
>  patternProperties:
>    "^framebuffer": true
>  
> +  "^openwrt,led-(boot|failsafe|running|upgrade)$":
> +    $ref: types.yaml#/definitions/string
> +    description:
> +      OpenWrt choice of LED for a given role.

Neither this explains it. What is "OpenWrt choice"? Choice like what?
What are the valid choices?

> Value must be a full path (encoded
> +      as a string) to a relevant LED node.

What do you mean by full path? DT node path? Then no, use phandles.

Anyway, we have existing properties for this - LED functions. Just
choose LED with given function (from sysfs) and you are done. If
function is missing in the header: feel free to go, least for me.

Also: please Cc LED maintainers on all future submissions of this.

Best regards,
Krzysztof


  reply	other threads:[~2024-01-09  9:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-09  8:23 [PATCH dt-schema] schemas: chosen: Add OpenWrt LEDs properties for system states Rafał Miłecki
2024-01-09  9:02 ` Krzysztof Kozlowski [this message]
2024-01-09 16:38   ` Rafał Miłecki
2024-01-09 19:10     ` Krzysztof Kozlowski
2024-01-09 21:08       ` Geert Uytterhoeven
2024-01-10  7:28         ` Krzysztof Kozlowski
2024-01-09 21:48       ` Rafał Miłecki
2024-01-10  7:40         ` Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1b90c50c-0a09-4627-83cd-1794dae7ed9b@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=openwrt-devel@lists.openwrt.org \
    --cc=rafal@milecki.pl \
    --cc=robh+dt@kernel.org \
    --cc=zajec5@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).