From: Markus Probst <markus.probst@posteo.de>
To: Alice Ryhl <aliceryhl@google.com>
Cc: "Drew Fustini" <fustini@kernel.org>,
"Guo Ren" <guoren@kernel.org>, "Fu Wei" <wefu@redhat.com>,
"Uwe Kleine-König" <ukleinek@kernel.org>,
"Michal Wilczynski" <m.wilczynski@samsung.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
linux-riscv@lists.infradead.org, linux-pwm@vger.kernel.org,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH] Move pwm registration into pwm::Chip::new
Date: Fri, 28 Nov 2025 12:25:04 +0000 [thread overview]
Message-ID: <8711d40496e0e12e3efcd7fd9e11bdea6de68c6d.camel@posteo.de> (raw)
In-Reply-To: <aSlrVLT92kmazgyh@google.com>
[-- Attachment #1: Type: text/plain, Size: 2582 bytes --]
On Fri, 2025-11-28 at 09:28 +0000, Alice Ryhl wrote:
> On Thu, Nov 27, 2025 at 05:15:06PM +0000, Markus Probst wrote:
> > The `pwm::Registration::register` function provides no guarantee that the
> > function isn't called twice with the same pwm chip, which is considered
> > unsafe.
> >
> > Add the code responsible for the registration into `pwm::Chip::new`. The
> > registration will happen before the driver gets access to the refcounted
> > pwm chip and can therefore guarantee that the registration isn't called
> > twice on the same pwm chip.
> >
> > Signed-off-by: Markus Probst <markus.probst@posteo.de>
> > ---
> > This patch provides the additional guarantee that the pwm chip doesn't
> > get registered twice.
> >
> > The following changes were made:
> > - change the visibility of `pwm::Registration` to private
> > - remove the `pwm::Registration::register` function
> > - add code for registering the pwm chip in `pwm::Chip::new`
> > - add Send + Sync bounds to `PwmOps`
> >
> > Note that I wasn't able to test this patch, due to the lack of hardware.
>
> Overall looks reasonable, but I have one question:
>
> > @@ -654,50 +668,23 @@ unsafe fn dec_ref(obj: NonNull<Chip<T>>) {
> > // structure's state is managed and synchronized by the kernel's device model
> > // and PWM core locking mechanisms. Therefore, it is safe to move the `Chip`
> > // wrapper (and the pointer it contains) across threads.
> > -unsafe impl<T: PwmOps + Send> Send for Chip<T> {}
> > +unsafe impl<T: PwmOps> Send for Chip<T> {}
> >
> > // SAFETY: It is safe for multiple threads to have shared access (`&Chip`) because
> > // the `Chip` data is immutable from the Rust side without holding the appropriate
> > // kernel locks, which the C core is responsible for. Any interior mutability is
> > // handled and synchronized by the C kernel code.
> > -unsafe impl<T: PwmOps + Sync> Sync for Chip<T> {}
> > +unsafe impl<T: PwmOps> Sync for Chip<T> {}
>
> Why was this changed?
Registration::register required PwmOps to be Send + Sync.
Prior to this change, Chip::new didn't require it for PwmOps. Meaning
it was possible to allocate a new Chip with a PwmOps that is not Send +
Sync. As there was no use for it and it isn't possible anymore to
allocate a new Chip without registering it, I added Send + Sync as
trait dependency (see 1. hunk of rust/kernel/pwm.rs in the patch).
Because PwmOps now implied Send + Sync, it wasn't necessary anymore to
have the additional bounds there.
Thanks
- Markus Probst
>
> Alice
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2025-11-28 12:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20251127171512eucas1p2eded6a14bdcba1e4dbeb15cc29b7860d@eucas1p2.samsung.com>
2025-11-27 17:15 ` [PATCH] Move pwm registration into pwm::Chip::new Markus Probst
2025-11-27 17:16 ` Markus Probst
2025-11-28 9:28 ` Alice Ryhl
2025-11-28 12:25 ` Markus Probst [this message]
2025-12-01 10:06 ` Alice Ryhl
2025-11-28 13:53 ` Daniel Almeida
2025-11-30 22:13 ` Michal Wilczynski
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=8711d40496e0e12e3efcd7fd9e11bdea6de68c6d.camel@posteo.de \
--to=markus.probst@posteo.de \
--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=fustini@kernel.org \
--cc=gary@garyguo.net \
--cc=guoren@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=lossin@kernel.org \
--cc=m.wilczynski@samsung.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
--cc=ukleinek@kernel.org \
--cc=wefu@redhat.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).