From: "Rafał Miłecki" <zajec5@gmail.com>
To: 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: [PATCH dt-schema] schemas: chosen: Add OpenWrt LEDs properties for system states
Date: Tue, 9 Jan 2024 09:23:12 +0100 [thread overview]
Message-ID: <20240109082312.9989-1-zajec5@gmail.com> (raw)
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
cared about so far as those would need to be patched downstream anyway.
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. Value must be a full path (encoded
+ as a string) to a relevant LED node.
+
+ Property user may use specified path to control proper LED during current
+ system boot phase.
+
additionalProperties: false
--
2.35.3
next reply other threads:[~2024-01-09 8:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-09 8:23 Rafał Miłecki [this message]
2024-01-09 9:02 ` [PATCH dt-schema] schemas: chosen: Add OpenWrt LEDs properties for system states Krzysztof Kozlowski
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=20240109082312.9989-1-zajec5@gmail.com \
--to=zajec5@gmail.com \
--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 \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).