From: Josef Schlehofer <pepe.schlehofer@gmail.com>
To: Lee Jones <lee@kernel.org>, Pavel Machek <pavel@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>
Cc: "Pali Rohár" <pali@kernel.org>, "Marek Behún" <kabel@kernel.org>,
"Andy Shevchenko" <andy@kernel.org>, "Rong Zhang" <i@rong.moe>,
"Uwe Kleine-König" <u.kleine-koenig@baylibre.com>,
"Griffin Kroah-Hartman" <griffin@kroah.com>,
linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
linux-api@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH v4 0/2] leds: Add support for CZ.NIC Turris 1.x LEDs
Date: Mon, 26 Oct 2026 20:51:18 +0100 [thread overview]
Message-ID: <20261026195120.12759-1-pepe.schlehofer@gmail.com> (raw)
The CZ.NIC Turris 1.x routers have eight RGB LEDs driven by the CPLD.
turris1x.dts already describes the controller, but there is no driver.
Pali posted v1, v2 and a RESEND in 2022 [1][2][3]. I took the series
over with v3 [4] and kept Pali as the author.
The main change in v4 follows Marek's review. The five LAN LEDs share
one colour and can only be switched on and off, so rgb:lan-1 is now the
only multicolor LAN LED and its colour applies to all five. All five
have max_brightness 1.
Marek, I left out the symlinks. Linking a single attribute needs
compat_only_sysfs_link_entry_to_kobj(), which is meant for keeping old
paths working. Instead, the ABI says that rgb:lan-1 sets the colour of
all five. A link to the whole rgb:lan-1 directory can come on top if
you or Lee want it.
The global brightness moved from the Omnia ABI file to the Turris 1.x
one, because here it is a 0-255 CPLD level, not a percentage.
Based on leds/for-leds-next (59cf91cf87ab), because the driver uses
the hw_offloaded() callback queued there.
Tested on a Turris 1.1 with leds/for-leds-next plus this series, the
driver as a module and CONFIG_PROVE_LOCKING:
- the colour set through rgb:lan-1 shows on all LAN LEDs that are on,
also while rgb:lan-1 is off or under a trigger
- brightness levels, triggers, unbind/bind and rmmod work as in v3
- no lockdep report from the driver
- after a reboot, the stock U-Boot (2015.04) finds the LEDs back under
CPLD control, after sysrq-b they keep the Linux state (checked with
v3, the shutdown code is the same)
W=1 and sparse on powerpc, COMPILE_TEST on x86_64 and arm64,
dt_binding_check, dtbs_check and get_abi.py show nothing new.
checkpatch --strict only asks about MAINTAINERS on 1/2 and warns about
a macro argument reuse on 2/2.
[1] https://lore.kernel.org/r/20220705000448.14337-1-pali@kernel.org/
[2] https://lore.kernel.org/r/20220705155929.25565-1-pali@kernel.org/
[3] https://lore.kernel.org/r/20221226123630.6515-1-pali@kernel.org/
[4] https://lore.kernel.org/r/20260928111907.72592-1-pepe.schlehofer@gmail.com/
Pali Rohár (2):
dt-bindings: leds: Add CZ.NIC Turris 1.x LED controller
leds: turris-1x: Add support for CZ.NIC Turris 1.x LEDs
.../testing/sysfs-class-led-driver-turris1x | 58 ++
.../bindings/leds/cznic,turris1x-leds.yaml | 132 ++++
MAINTAINERS | 9 +
drivers/leds/Kconfig | 13 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-turris-1x.c | 624 ++++++++++++++++++
6 files changed, 837 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-led-driver-turris1x
create mode 100644 Documentation/devicetree/bindings/leds/cznic,turris1x-leds.yaml
create mode 100644 drivers/leds/leds-turris-1x.c
base-commit: 59cf91cf87abb67a49b1bb7b9d3b06486abde8cf
--
2.54.0 (Apple Git-157)
next reply other threads:[~2026-10-26 19:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 19:51 Josef Schlehofer [this message]
2026-10-26 19:51 ` [PATCH v4 1/2] dt-bindings: leds: Add CZ.NIC Turris 1.x LED controller Josef Schlehofer
2026-10-26 19:51 ` [PATCH v4 2/2] leds: turris-1x: Add support for CZ.NIC Turris 1.x LEDs Josef Schlehofer
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=20261026195120.12759-1-pepe.schlehofer@gmail.com \
--to=pepe.schlehofer@gmail.com \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=griffin@kroah.com \
--cc=i@rong.moe \
--cc=kabel@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lee@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=pali@kernel.org \
--cc=pavel@kernel.org \
--cc=robh@kernel.org \
--cc=u.kleine-koenig@baylibre.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
all inboxes | Powered by JetHome®