These traits are required for drivers to embed the Clk type in their own
data structures because driver data structures are usually required to
be Send. See e.g. [1] for the kind of workaround that drivers currently
need due to lacking this annotation.

Link: https://lore.kernel.org/rust-for-linux/20250812-tyr-v2-1-9e0f3dc9da95@collabora.com/ [1]
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
I'm not sure if there was already sent a patch for this. I recall
being told that one had been sent, but I could not find it. Maybe I
mixed it up with the regulator change, so now I'm sending a change for
clk.
---
 rust/kernel/clk.rs | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/rust/kernel/clk.rs b/rust/kernel/clk.rs
index 1e6c8c42fb3a321951e275101848b35e1ae5c2a8..0a290202da69669d670ddad2b6762a1d5f1d912e 100644
--- a/rust/kernel/clk.rs
+++ b/rust/kernel/clk.rs
@@ -129,6 +129,13 @@ mod common_clk {
     #[repr(transparent)]
     pub struct Clk(*mut bindings::clk);
 
+    // SAFETY: It is safe to call `clk_put` on another thread than where `clk_get` was called.
+    unsafe impl Send for Clk {}
+
+    // SAFETY: It is safe to call any combination of the `&self` methods in parallel, as the
+    // methods are synchronized internally.
+    unsafe impl Sync for Clk {}
+
     impl Clk {
         /// Gets [`Clk`] corresponding to a [`Device`] and a connection id.
         ///

---
base-commit: 1b237f190eb3d36f52dffe07a40b5eb210280e00
change-id: 20250904-clk-send-sync-3cfa7f4e1ce2

Best regards,
-- 
Alice Ryhl <aliceryhl@google.com>

> On 4 Sep 2025, at 06:03, Alice Ryhl <aliceryhl@google.com> wrote:
> 
> These traits are required for drivers to embed the Clk type in their own
> data structures because driver data structures are usually required to
> be Send. See e.g. [1] for the kind of workaround that drivers currently
> need due to lacking this annotation.
> 
> Link: https://lore.kernel.org/rust-for-linux/20250812-tyr-v2-1-9e0f3dc9da95@collabora.com/ [1]
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
> I'm not sure if there was already sent a patch for this. I recall
> being told that one had been sent, but I could not find it. Maybe I
> mixed it up with the regulator change, so now I'm sending a change for
> clk.
> ---
> rust/kernel/clk.rs | 7 +++++++
> 1 file changed, 7 insertions(+)
> 
> diff --git a/rust/kernel/clk.rs b/rust/kernel/clk.rs
> index 1e6c8c42fb3a321951e275101848b35e1ae5c2a8..0a290202da69669d670ddad2b6762a1d5f1d912e 100644
> --- a/rust/kernel/clk.rs
> +++ b/rust/kernel/clk.rs
> @@ -129,6 +129,13 @@ mod common_clk {
>     #[repr(transparent)]
>     pub struct Clk(*mut bindings::clk);
> 
> +    // SAFETY: It is safe to call `clk_put` on another thread than where `clk_get` was called.
> +    unsafe impl Send for Clk {}
> +
> +    // SAFETY: It is safe to call any combination of the `&self` methods in parallel, as the
> +    // methods are synchronized internally.
> +    unsafe impl Sync for Clk {}
> +
>     impl Clk {
>         /// Gets [`Clk`] corresponding to a [`Device`] and a connection id.
>         ///
> 
> ---
> base-commit: 1b237f190eb3d36f52dffe07a40b5eb210280e00
> change-id: 20250904-clk-send-sync-3cfa7f4e1ce2
> 
> Best regards,
> -- 
> Alice Ryhl <aliceryhl@google.com>
> 
> 

I’ve included this on my series here [0], as it would otherwise conflict with the type-state work.

I did not see anyone against the type-state patch itself, so perhaps both can go together.

— Daniel

[0]: https://lore.kernel.org/rust-for-linux/20250910-clk-type-state-v2-0-1b97c11bb631@collabora.com/T/#t

On 9/4/25 11:03 AM, Alice Ryhl wrote:
> These traits are required for drivers to embed the Clk type in their own
> data structures because driver data structures are usually required to
> be Send. See e.g. [1] for the kind of workaround that drivers currently
> need due to lacking this annotation.
> 
> Link: https://lore.kernel.org/rust-for-linux/20250812-tyr-v2-1-9e0f3dc9da95@collabora.com/ [1]
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>

Reviewed-by: Danilo Krummrich <dakr@kernel.org>

Hi Alice, good catch, this is indeed missing.

> On 4 Sep 2025, at 06:03, Alice Ryhl <aliceryhl@google.com> wrote:
> 
> These traits are required for drivers to embed the Clk type in their own
> data structures because driver data structures are usually required to
> be Send. See e.g. [1] for the kind of workaround that drivers currently
> need due to lacking this annotation.
> 
> Link: https://lore.kernel.org/rust-for-linux/20250812-tyr-v2-1-9e0f3dc9da95@collabora.com/ [1]
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
> I'm not sure if there was already sent a patch for this. I recall
> being told that one had been sent, but I could not find it. Maybe I
> mixed it up with the regulator change, so now I'm sending a change for
> clk.
> ---
> rust/kernel/clk.rs | 7 +++++++
> 1 file changed, 7 insertions(+)
> 
> diff --git a/rust/kernel/clk.rs b/rust/kernel/clk.rs
> index 1e6c8c42fb3a321951e275101848b35e1ae5c2a8..0a290202da69669d670ddad2b6762a1d5f1d912e 100644
> --- a/rust/kernel/clk.rs
> +++ b/rust/kernel/clk.rs
> @@ -129,6 +129,13 @@ mod common_clk {
>     #[repr(transparent)]
>     pub struct Clk(*mut bindings::clk);
> 
> +    // SAFETY: It is safe to call `clk_put` on another thread than where `clk_get` was called.
> +    unsafe impl Send for Clk {}
> +
> +    // SAFETY: It is safe to call any combination of the `&self` methods in parallel, as the
> +    // methods are synchronized internally.
> +    unsafe impl Sync for Clk {}
> +
>     impl Clk {
>         /// Gets [`Clk`] corresponding to a [`Device`] and a connection id.
>         ///
> 
> ---
> base-commit: 1b237f190eb3d36f52dffe07a40b5eb210280e00
> change-id: 20250904-clk-send-sync-3cfa7f4e1ce2
> 
> Best regards,
> -- 
> Alice Ryhl <aliceryhl@google.com>
> 

Can you base your change on top of [0]? Otherwise it will become stale rather
quickly, as this introduces new types, i.e.: Clk<Unprepared>, Clk<Prepared>
etc.

I will push out a new version today.

[0]: https://lore.kernel.org/rust-for-linux/20250729-clk-type-state-v1-1-896b53816f7b@collabora.com/

On Thu, Sep 4, 2025 at 2:31 PM Daniel Almeida
<daniel.almeida@collabora.com> wrote:
> Can you base your change on top of [0]? Otherwise it will become stale rather
> quickly, as this introduces new types, i.e.: Clk<Unprepared>, Clk<Prepared>
> etc.
>
> I will push out a new version today.
>
> [0]: https://lore.kernel.org/rust-for-linux/20250729-clk-type-state-v1-1-896b53816f7b@collabora.com/

I would suggest the reverse. If your series is based on top of mine,
then this patch can land today regardless of how long it takes to
finish the clk refactor.

Alice

> On 4 Sep 2025, at 10:07, Alice Ryhl <aliceryhl@google.com> wrote:
> 
> On Thu, Sep 4, 2025 at 2:31 PM Daniel Almeida
> <daniel.almeida@collabora.com> wrote:
>> Can you base your change on top of [0]? Otherwise it will become stale rather
>> quickly, as this introduces new types, i.e.: Clk<Unprepared>, Clk<Prepared>
>> etc.
>> 
>> I will push out a new version today.
>> 
>> [0]: https://lore.kernel.org/rust-for-linux/20250729-clk-type-state-v1-1-896b53816f7b@collabora.com/
> 
> I would suggest the reverse. If your series is based on top of mine,
> then this patch can land today regardless of how long it takes to
> finish the clk refactor.
> 
> Alice
> 

True,

Ok then:

Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>

On 04-09-25, 09:03, Alice Ryhl wrote:
> These traits are required for drivers to embed the Clk type in their own
> data structures because driver data structures are usually required to
> be Send. See e.g. [1] for the kind of workaround that drivers currently
> need due to lacking this annotation.
> 
> Link: https://lore.kernel.org/rust-for-linux/20250812-tyr-v2-1-9e0f3dc9da95@collabora.com/ [1]
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
> I'm not sure if there was already sent a patch for this. I recall
> being told that one had been sent, but I could not find it. Maybe I
> mixed it up with the regulator change, so now I'm sending a change for
> clk.
> ---
>  rust/kernel/clk.rs | 7 +++++++
>  1 file changed, 7 insertions(+)

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh