From: Markus Probst <markus.probst@posteo.de>
To: Danilo Krummrich <dakr@kernel.org>
Cc: Lee Jones <lee@kernel.org>, Pavel Machek <pavel@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: Thu, 09 Oct 2025 12:30:17 +0000 [thread overview]
Message-ID: <53fd34386cefd4a789c56a6e6d7c5618c06c531b.camel@posteo.de> (raw)
In-Reply-To: <DDDSCBNFRLG9.26UA3ZEOA9LJH@kernel.org>
On Thu, 2025-10-09 at 14:20 +0200, Danilo Krummrich wrote:
> (Not a full review (let's work out the dependencies first), but
> there's one
> thing that stood out to me.)
>
> On Wed Oct 8, 2025 at 8:10 PM CEST, Markus Probst wrote:
> > +struct Atmega1608Led {
> > + addr: Atmega1608LedAddress,
> > + id: Atmega1608LedId,
> > +
> > + client: ARef<I2cClient>,
> > +
> > + mode_lock: Arc<Mutex<()>>,
>
> Mutex<()> raises an eyebrow, since a mutex that doesn't protect
> anything is
> pointless. So, I assume it is protecting some data, but in an unsound
> way.
>
> > +impl Atmega1608Led {
> > + fn update_mode(&self, mode: Atmega1608LedMode) ->
> > Result<Atmega1608LedMode> {
> > + let _guard = self.mode_lock.lock();
>
> What exactly does the mutex protect in the code below?
Otherwise there would be a race condition. Each register has 8 bits,
each led has 2 bits. If the led mode is updated at the same time with
another one in the same register, it could lead to the first action
being overwritten by the second.
Meaning if two actions run at the same time:
- led0 reads from the register
- led1 reads from the register
- led0 writes to the register
- led1 writes to the register (the changes for led0 have been
overwritten here, as it did read the register before led0 has written
to it)
>
> > +
> > + let mut current = self
> > + .client
> > + .read_byte_data(self.addr as u8)
> > + .inspect_err(|err| {
> > + dev_err!(
> > + self.client.as_ref(),
> > + "failed to read {:#2x}: {err:?}\n",
> > + self.addr as u8
> > + );
> > + })?;
> > +
> > + current =
> > + (current & !self.id.mask()) | (((mode as u8) <<
> > self.id.shift()) & self.id.mask());
> > +
> > + self.client
> > + .write_byte_data(self.addr as u8, current)
> > + .inspect_err(|err| {
> > + dev_err!(
> > + self.client.as_ref(),
> > + "failed to write {:#2x}: {err:?}",
> > + self.addr as u8
> > + );
> > + })?;
> > +
> > + Ok(mode)
> > + }
> > +}
Thanks
- Markus Probst
next prev parent reply other threads:[~2025-10-09 12:30 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 [this message]
2025-10-09 12:41 ` Danilo Krummrich
2025-10-09 13:11 ` Alexandre Courbot
2025-11-23 20:00 ` Pavel Machek
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=53fd34386cefd4a789c56a6e6d7c5618c06c531b.camel@posteo.de \
--to=markus.probst@posteo.de \
--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=ojeda@kernel.org \
--cc=pavel@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