From: Pavel Machek <pavel@ucw.cz>
To: Markus Probst <markus.probst@posteo.de>
Cc: Lee Jones <lee@kernel.org>, Danilo Krummrich <dakr@kernel.org>,
Miguel Ojeda <ojeda@kernel.org>,
Alex Gaynor <alex.gaynor@gmail.com>,
Igor Korotin <igor.korotin.linux@gmail.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Uladzislau Rezki <urezki@gmail.com>,
Boqun Feng <boqun.feng@gmail.com>, Gary Guo <gary@garyguo.net>,
bjorn3_gh@protonmail.com, Benno Lossin <lossin@kernel.org>,
Andreas Hindborg <a.hindborg@kernel.org>,
Alice Ryhl <aliceryhl@google.com>,
Trevor Gross <tmgross@umich.edu>,
Daniel Almeida <daniel.almeida@collabora.com>,
linux-leds@vger.kernel.org, rust-for-linux@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] leds: add driver for synology atmega1608 controlled LEDs
Date: Sun, 23 Nov 2025 21:00:07 +0100 [thread overview]
Message-ID: <aSNnx6LNA/zMO4Gw@duo.ucw.cz> (raw)
In-Reply-To: <20251008181027.662616-5-markus.probst@posteo.de>
[-- Attachment #1: Type: text/plain, Size: 3880 bytes --]
Hi!
> The Atmega1608 is a microcontroller used by synology devices to control
> leds via the i2c bus. It can handle up to 24 leds.
Ok, but driver is not really for atmega1608, but for whatever code is
running there, right?
I would not mind that code being opensource.
I would not mind if we had standard interface to these so the next
person can reuse the protocol.
> +++ b/drivers/leds/Kconfig
> @@ -323,6 +323,15 @@ config LEDS_WRAP
> help
> This option enables support for the PCEngines WRAP programmable LEDs.
>
> +config LEDS_ATMEGA1608
> + tristate "LED Support for Atmega1608 used in Synology devices"
There's nothing Atmega specific, right?
"LED Support for Synology devices"?
> + depends on LEDS_CLASS
> + depends on I2C
> + depends on RUST
> + help
> + This option enables support for the Atmega1608 microcontroller used
> + as led controller in synology devices.
led->LED
synology->Synology
> +++ b/drivers/leds/leds_atmega1608.rs
> @@ -0,0 +1,377 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! Led Driver for Synology devices using Atmega1608 as Led Controller.
Led->LED
> +//! Atmega1608 is a microcontroller from Microchip Technology, it is used
> +//! as a led controller in synology nas devices.
led->LED
(Please fix globally).
> +//! # Limitations
> +//!
> +//! DIM0 (and DIM1) are shared across all leds, meaning if DIM0 is used by
> +//! multiple leds, these multiple leds cannot have different brightness
> +//! levels. The same does apply for the hardware accelerated blinking.
> +//!
> +//! In other words, for all 24 leds there can either only be one brightness other
> +//! than 0 and 255, or one hardware accelerated blinking delay.
> +//!
> +//! Furthermore the off and on delay in hardware accelerated blinking cannot
> +//! have different values and have to be equal. We solve this by calculating
> +//! the average of those numbers and use it as delay for both. The delay
> +//! cannot be larger than 765 ms (255*3).
> +//!
> +//! While hardware accelerated blinking is on, the led cycles between
> +//! the current brightness for the mode and full brightness. Because of this
> +//! behaviour, we hardcode the brightness value of 128 if hardware accelerated
> +//! blinking is used.
Maybe we should just pretend that hw acceleration does not exist? Or
pretend it can only do single blinking rate.
> +
> +kernel::module_i2c_driver! {
> + type: Atmega1608LedDriver,
> + name: "atmega1608",
> + authors: ["Markus Probst <markus.probst@posteo.de>"],
> + description: "Led Driver for Synology devices using Atmega1608 as Led Controller",
> + license: "GPL v2",
> +}
This should be called synologyLedDriver or something. We have driver
for Thinkpad LEDs. We don't care what kind of hardware it runs on.
> +impl LedHandler for Atmega1608Led {
> + const BLOCKING: bool = true;
> + const BLINK: bool = true;
> + const MAX_BRIGHTNESS: u32 = 255;
> +
> + fn brightness_set(&self, brightness: u32) -> Result<()> {
> + let brightness = u8::try_from(brightness).unwrap_or(255);
> +
> + let mode = self.update_mode(match brightness {
> + 0 => Atmega1608LedMode::Off,
> + 255 | 254 => Atmega1608LedMode::On,
> + _ => Atmega1608LedMode::Dim0,
> + })?;
Umm... so the hardware can only do on / off and dim. And dim is
strange.
Certainly MAX_BRIGHTNESS should not be 255, but 1 (or 2 if you want to
support dim mode).
One idea: Use hardware diming to have three levels. So MAX_BRIGHTNESS
= 2. Then ignore hardware accelerated blinking. And you should have
working and simpler driver.
Thanks and best regards,
Pavel
--
I don't work for Nazis and criminals, and neither should you.
Boycott Putin, Trump, Netanyahu and Musk!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2025-11-23 20:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-08 18:10 [PATCH 0/4] Add first led driver written in Rust Markus Probst
2025-10-08 18:10 ` [PATCH 1/4] rust: i2c: add read and write byte data abstractions Markus Probst
2025-10-08 18:10 ` [PATCH 2/4] rust: add pinned wrapper of Vec Markus Probst
2025-10-08 18:10 ` [PATCH 3/4] rust: leds: add basic led classdev abstractions Markus Probst
2025-10-08 18:10 ` [PATCH 4/4] leds: add driver for synology atmega1608 controlled LEDs Markus Probst
2025-10-09 12:20 ` Danilo Krummrich
2025-10-09 12:30 ` Markus Probst
2025-10-09 12:41 ` Danilo Krummrich
2025-10-09 13:11 ` Alexandre Courbot
2025-11-23 20:00 ` Pavel Machek [this message]
2025-11-23 22:45 ` Markus Probst
2025-10-09 11:36 ` [PATCH 3/4] rust: leds: add basic led classdev abstractions Danilo Krummrich
2025-11-23 19:47 ` Pavel Machek
2025-10-09 11:23 ` [PATCH 2/4] rust: add pinned wrapper of Vec Alice Ryhl
2025-10-09 12:06 ` Markus Probst
2025-10-09 11:29 ` [PATCH 1/4] rust: i2c: add read and write byte data abstractions Alice Ryhl
2025-10-09 12:08 ` Danilo Krummrich
2025-11-23 19:44 ` Pavel Machek
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=aSNnx6LNA/zMO4Gw@duo.ucw.cz \
--to=pavel@ucw.cz \
--cc=Liam.Howlett@oracle.com \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=gary@garyguo.net \
--cc=igor.korotin.linux@gmail.com \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=lossin@kernel.org \
--cc=markus.probst@posteo.de \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
--cc=urezki@gmail.com \
--cc=vbabka@suse.cz \
/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).