[PATCH v2 1/2] rust: clk: implement Send and Sync

[PATCH v2 1/2] rust: clk: implement Send and Sync

[Daniel Almeida]

From: Alice Ryhl <aliceryhl@google.com>

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: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
---
 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.
         ///

-- 
2.51.0

Re: [PATCH v2 1/2] rust: clk: implement Send and Sync

[Boqun Feng]

On Wed, Sep 10, 2025 at 02:28:27PM -0300, Daniel Almeida wrote:
> From: Alice Ryhl <aliceryhl@google.com>
> 
> 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: Daniel Almeida <daniel.almeida@collabora.com>
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> Reviewed-by: Danilo Krummrich <dakr@kernel.org>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>

This tag list looks a bit weird to me. Why is there a SoB from you
before Alice's SoB? At least for the usage I'm familiar with, outside
the case of Co-developed-bys, multiple SoBs is used for recording how
the patches are routed. For example, if I have a patch that has my SoB
and I send it to you, you queue in your tree and then send out to other
maintainers for merging, in general you would put your SoB after mine in
that case. But I don't think that's case here? Alice's patch has only
her SoB:

	https://lore.kernel.org/rust-for-linux/20250904-clk-send-sync-v1-1-48d023320eb8@google.com/

What's the intention of the SoB tag here?

Otherwise the patch looks good to me. If we get the tag list resolved,
feel free to add:

Reviewed-by: Boqun Feng <boqun.feng@gmail.com>

Regards,
Boqun

> ---
>  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.
>          ///
> 
> -- 
> 2.51.0
> 

Re: [PATCH v2 1/2] rust: clk: implement Send and Sync

[Daniel Almeida]

Hi Boqun,

> On 10 Sep 2025, at 14:49, Boqun Feng <boqun.feng@gmail.com> wrote:
> 
> On Wed, Sep 10, 2025 at 02:28:27PM -0300, Daniel Almeida wrote:
>> From: Alice Ryhl <aliceryhl@google.com>
>> 
>> 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: Daniel Almeida <daniel.almeida@collabora.com>
>> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
>> Reviewed-by: Danilo Krummrich <dakr@kernel.org>
>> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
> 
> This tag list looks a bit weird to me. Why is there a SoB from you
> before Alice's SoB? At least for the usage I'm familiar with, outside
> the case of Co-developed-bys, multiple SoBs is used for recording how
> the patches are routed. For example, if I have a patch that has my SoB
> and I send it to you, you queue in your tree and then send out to other
> maintainers for merging, in general you would put your SoB after mine in
> that case. But I don't think that's case here? Alice's patch has only
> her SoB:
> 
> https://lore.kernel.org/rust-for-linux/20250904-clk-send-sync-v1-1-48d023320eb8@google.com/
> 
> What's the intention of the SoB tag here?
> 
> Otherwise the patch looks good to me. If we get the tag list resolved,
> feel free to add:
> 
> Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
> 
> Regards,
> Boqun
> 

You have to include your SOB when submitting patches from others.

This is something I tend to forget often, so I made sure it was there. The
order may be indeed off though.

— Daniel

Re: [PATCH v2 1/2] rust: clk: implement Send and Sync

[Boqun Feng]

On Wed, Sep 10, 2025 at 03:47:30PM -0300, Daniel Almeida wrote:
> Hi Boqun,
> 
> > On 10 Sep 2025, at 14:49, Boqun Feng <boqun.feng@gmail.com> wrote:
> > 
> > On Wed, Sep 10, 2025 at 02:28:27PM -0300, Daniel Almeida wrote:
> >> From: Alice Ryhl <aliceryhl@google.com>
> >> 
> >> 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: Daniel Almeida <daniel.almeida@collabora.com>
> >> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> >> Reviewed-by: Danilo Krummrich <dakr@kernel.org>
> >> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> >> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
> > 
> > This tag list looks a bit weird to me. Why is there a SoB from you
> > before Alice's SoB? At least for the usage I'm familiar with, outside
> > the case of Co-developed-bys, multiple SoBs is used for recording how
> > the patches are routed. For example, if I have a patch that has my SoB
> > and I send it to you, you queue in your tree and then send out to other
> > maintainers for merging, in general you would put your SoB after mine in
> > that case. But I don't think that's case here? Alice's patch has only
> > her SoB:
> > 
> > https://lore.kernel.org/rust-for-linux/20250904-clk-send-sync-v1-1-48d023320eb8@google.com/
> > 
> > What's the intention of the SoB tag here?
> > 
> > Otherwise the patch looks good to me. If we get the tag list resolved,
> > feel free to add:
> > 
> > Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
> > 
> > Regards,
> > Boqun
> > 
> 
> You have to include your SOB when submitting patches from others.
> 
> This is something I tend to forget often, so I made sure it was there. The
> order may be indeed off though.
> 

I mean you can just use `b4 shazam -s` to apply the patch and add your
SoB at the end ;-)

Regards,
Boqun

> - Daniel
> 

Re: [PATCH v2 1/2] rust: clk: implement Send and Sync

[Stephen Boyd]

Quoting Daniel Almeida (2025-09-10 11:47:30)
> Hi Boqun,
> 
> > On 10 Sep 2025, at 14:49, Boqun Feng <boqun.feng@gmail.com> wrote:
> > 
> > On Wed, Sep 10, 2025 at 02:28:27PM -0300, Daniel Almeida wrote:
> >> From: Alice Ryhl <aliceryhl@google.com>
> >> 
> >> 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: Daniel Almeida <daniel.almeida@collabora.com>
> >> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> >> Reviewed-by: Danilo Krummrich <dakr@kernel.org>
> >> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> >> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
> > 
> > This tag list looks a bit weird to me. Why is there a SoB from you
> > before Alice's SoB? At least for the usage I'm familiar with, outside
> > the case of Co-developed-bys, multiple SoBs is used for recording how
> > the patches are routed. For example, if I have a patch that has my SoB
> > and I send it to you, you queue in your tree and then send out to other
> > maintainers for merging, in general you would put your SoB after mine in
> > that case. But I don't think that's case here? Alice's patch has only
> > her SoB:
> > 
> > https://lore.kernel.org/rust-for-linux/20250904-clk-send-sync-v1-1-48d023320eb8@google.com/
> > 
> > What's the intention of the SoB tag here?
> > 
> > Otherwise the patch looks good to me. If we get the tag list resolved,
> > feel free to add:
> > 
> > Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
> > 
> > Regards,
> > Boqun
> > 
> 
> You have to include your SOB when submitting patches from others.
> 
> This is something I tend to forget often, so I made sure it was there. The
> order may be indeed off though.

Yes the order is wrong. The first SoB should be the commit author.

Re: [PATCH v2 1/2] rust: clk: implement Send and Sync

[Daniel Almeida]

Hi Stephen,

[…]

>> 
>> You have to include your SOB when submitting patches from others.
>> 
>> This is something I tend to forget often, so I made sure it was there. The
>> order may be indeed off though.
> 
> Yes the order is wrong. The first SoB should be the commit author.

Do you want me to send a new version, or do you prefer fixing this before applying?

For trivial changes some maintainers prefer the latter to reduce the amount of noise.

— Daniel

Re: [PATCH v2 1/2] rust: clk: implement Send and Sync

[Alice Ryhl]

On Sat, Sep 20, 2025 at 7:06 AM Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting Daniel Almeida (2025-09-10 11:47:30)
> > Hi Boqun,
> >
> > > On 10 Sep 2025, at 14:49, Boqun Feng <boqun.feng@gmail.com> wrote:
> > >
> > > On Wed, Sep 10, 2025 at 02:28:27PM -0300, Daniel Almeida wrote:
> > >> From: Alice Ryhl <aliceryhl@google.com>
> > >>
> > >> 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: Daniel Almeida <daniel.almeida@collabora.com>
> > >> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> > >> Reviewed-by: Danilo Krummrich <dakr@kernel.org>
> > >> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> > >> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
> > >
> > > This tag list looks a bit weird to me. Why is there a SoB from you
> > > before Alice's SoB? At least for the usage I'm familiar with, outside
> > > the case of Co-developed-bys, multiple SoBs is used for recording how
> > > the patches are routed. For example, if I have a patch that has my SoB
> > > and I send it to you, you queue in your tree and then send out to other
> > > maintainers for merging, in general you would put your SoB after mine in
> > > that case. But I don't think that's case here? Alice's patch has only
> > > her SoB:
> > >
> > > https://lore.kernel.org/rust-for-linux/20250904-clk-send-sync-v1-1-48d023320eb8@google.com/
> > >
> > > What's the intention of the SoB tag here?
> > >
> > > Otherwise the patch looks good to me. If we get the tag list resolved,
> > > feel free to add:
> > >
> > > Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
> > >
> > > Regards,
> > > Boqun
> > >
> >
> > You have to include your SOB when submitting patches from others.
> >
> > This is something I tend to forget often, so I made sure it was there. The
> > order may be indeed off though.
>
> Yes the order is wrong. The first SoB should be the commit author.

One optoin is to just land the original patch:
https://lore.kernel.org/all/20250904-clk-send-sync-v1-1-48d023320eb8@google.com/

Alice

Re: [PATCH v2 1/2] rust: clk: implement Send and Sync

[Daniel Almeida]

> On 20 Sep 2025, at 19:12, Alice Ryhl <aliceryhl@google.com> wrote:
> 
> On Sat, Sep 20, 2025 at 7:06 AM Stephen Boyd <sboyd@kernel.org> wrote:
>> 
>> Quoting Daniel Almeida (2025-09-10 11:47:30)
>>> Hi Boqun,
>>> 
>>>> On 10 Sep 2025, at 14:49, Boqun Feng <boqun.feng@gmail.com> wrote:
>>>> 
>>>> On Wed, Sep 10, 2025 at 02:28:27PM -0300, Daniel Almeida wrote:
>>>>> From: Alice Ryhl <aliceryhl@google.com>
>>>>> 
>>>>> 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: Daniel Almeida <daniel.almeida@collabora.com>
>>>>> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
>>>>> Reviewed-by: Danilo Krummrich <dakr@kernel.org>
>>>>> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>>>>> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
>>>> 
>>>> This tag list looks a bit weird to me. Why is there a SoB from you
>>>> before Alice's SoB? At least for the usage I'm familiar with, outside
>>>> the case of Co-developed-bys, multiple SoBs is used for recording how
>>>> the patches are routed. For example, if I have a patch that has my SoB
>>>> and I send it to you, you queue in your tree and then send out to other
>>>> maintainers for merging, in general you would put your SoB after mine in
>>>> that case. But I don't think that's case here? Alice's patch has only
>>>> her SoB:
>>>> 
>>>> https://lore.kernel.org/rust-for-linux/20250904-clk-send-sync-v1-1-48d023320eb8@google.com/
>>>> 
>>>> What's the intention of the SoB tag here?
>>>> 
>>>> Otherwise the patch looks good to me. If we get the tag list resolved,
>>>> feel free to add:
>>>> 
>>>> Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
>>>> 
>>>> Regards,
>>>> Boqun
>>>> 
>>> 
>>> You have to include your SOB when submitting patches from others.
>>> 
>>> This is something I tend to forget often, so I made sure it was there. The
>>> order may be indeed off though.
>> 
>> Yes the order is wrong. The first SoB should be the commit author.
> 
> One optoin is to just land the original patch:
> https://lore.kernel.org/all/20250904-clk-send-sync-v1-1-48d023320eb8@google.com/
> 
> Alice

I guess this makes even more sense. I was hoping to land these two together,
but clearly this will not be possible for the time being as the second patch
has no r-b tags.

— Daniel

Re: [PATCH v2 1/2] rust: clk: implement Send and Sync

[Stephen Boyd]

Quoting Daniel Almeida (2025-09-20 03:33:07)
> Hi Stephen,
> 
> […]
> 
> >> 
> >> You have to include your SOB when submitting patches from others.
> >> 
> >> This is something I tend to forget often, so I made sure it was there. The
> >> order may be indeed off though.
> > 
> > Yes the order is wrong. The first SoB should be the commit author.
> 
> Do you want me to send a new version, or do you prefer fixing this before applying?
> 
> For trivial changes some maintainers prefer the latter to reduce the amount of noise.
> 

You can send another round. I'm waiting to see if anyone will review the
second patch. Maybe sending another round will prompt a review.

[PATCH v2 0/2] Implement Send and Sync for clk

[Alice Ryhl]

I added a patch to remove the Send/Sync impl for the Tyr driver as well.
I think it's fine for the Tyr patch to land through whichever tree takes
the clk patch, as there should be no non-trivial merge conflicts. Or we
can also take the clk patch through drm-rust where tyr patches normally
go if preferred by clk maintainers.

Regarding Daniel's patch [1], I suggest that Daniel sends his type-state
change rebased on top of this series (without including the patches in
this series in his).

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

Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
Changes in v2:
- Rebase on v6.18-rc1.
- Add patch to tyr driver.
- Link to v1: https://lore.kernel.org/r/20250904-clk-send-sync-v1-1-48d023320eb8@google.com

---
Alice Ryhl (2):
      rust: clk: implement Send and Sync
      tyr: remove impl Send/Sync for TyrData

 drivers/gpu/drm/tyr/driver.rs | 12 ------------
 rust/kernel/clk.rs            |  7 +++++++
 2 files changed, 7 insertions(+), 12 deletions(-)
---
base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
change-id: 20250904-clk-send-sync-3cfa7f4e1ce2

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

[PATCH v2 1/2] rust: clk: implement Send and Sync

[Alice Ryhl]

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. Since the Clk type is thread-safe, implement the relevant
traits.

Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
 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.
         ///

-- 
2.51.0.915.g61a8936c21-goog

[PATCH v2 2/2] tyr: remove impl Send/Sync for TyrData

[Alice Ryhl]

Now that clk implements Send and Sync, we no longer need to manually
implement these traits for TyrData. Thus remove the implementations.

The comment also mentions the regulator. However, the regulator had the
traits added in commit 9a200cbdb543 ("rust: regulator: implement Send
and Sync for Regulator<T>"), which is already in mainline.

Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
 drivers/gpu/drm/tyr/driver.rs | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/tyr/driver.rs b/drivers/gpu/drm/tyr/driver.rs
index d5625dd1e41c8406494b267d4ac560c442a8012c..574b85bbc497f8d1053d16a11f77ecbe2c87bfb2 100644
--- a/drivers/gpu/drm/tyr/driver.rs
+++ b/drivers/gpu/drm/tyr/driver.rs
@@ -53,18 +53,6 @@ pub(crate) struct TyrData {
     pub(crate) gpu_info: GpuInfo,
 }
 
-// Both `Clk` and `Regulator` do not implement `Send` or `Sync`, but they
-// should. There are patches on the mailing list to address this, but they have
-// not landed yet.
-//
-// For now, add this workaround so that this patch compiles with the promise
-// that it will be removed in a future patch.
-//
-// SAFETY: This will be removed in a future patch.
-unsafe impl Send for TyrData {}
-// SAFETY: This will be removed in a future patch.
-unsafe impl Sync for TyrData {}
-
 fn issue_soft_reset(dev: &Device<Bound>, iomem: &Devres<IoMem>) -> Result {
     regs::GPU_CMD.write(dev, iomem, regs::GPU_CMD_SOFT_RESET)?;
 

-- 
2.51.0.915.g61a8936c21-goog

Re: [PATCH v2 1/2] rust: clk: implement Send and Sync

[Viresh Kumar]

On 20-10-25, 09:35, 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. Since the Clk type is thread-safe, implement the relevant
> traits.
> 
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
>  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.
>          ///

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

-- 
viresh

Re: [PATCH v2 0/2] Implement Send and Sync for clk

[Boqun Feng]

On Mon, Oct 20, 2025 at 09:35:33AM +0000, Alice Ryhl wrote:
> I added a patch to remove the Send/Sync impl for the Tyr driver as well.
> I think it's fine for the Tyr patch to land through whichever tree takes
> the clk patch, as there should be no non-trivial merge conflicts. Or we
> can also take the clk patch through drm-rust where tyr patches normally
> go if preferred by clk maintainers.
> 
> Regarding Daniel's patch [1], I suggest that Daniel sends his type-state
> change rebased on top of this series (without including the patches in
> this series in his).
> 
> [1]: https://lore.kernel.org/rust-for-linux/20250910-clk-type-state-v2-2-1b97c11bb631@collabora.com/
> 
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>

For the whole series:

Reviewed-by: Boqun Feng <boqun.feng@gmail.com>

Regards,
Boqun

> ---
> Changes in v2:
> - Rebase on v6.18-rc1.
> - Add patch to tyr driver.
> - Link to v1: https://lore.kernel.org/r/20250904-clk-send-sync-v1-1-48d023320eb8@google.com
> 
> ---
> Alice Ryhl (2):
>       rust: clk: implement Send and Sync
>       tyr: remove impl Send/Sync for TyrData
> 
>  drivers/gpu/drm/tyr/driver.rs | 12 ------------
>  rust/kernel/clk.rs            |  7 +++++++
>  2 files changed, 7 insertions(+), 12 deletions(-)
> ---
> base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
> change-id: 20250904-clk-send-sync-3cfa7f4e1ce2
> 
> Best regards,
> -- 
> Alice Ryhl <aliceryhl@google.com>
> 

Re: [PATCH v2 1/2] rust: clk: implement Send and Sync

[Alice Ryhl]

On Wed, Oct 22, 2025 at 09:21:38AM +0530, Viresh Kumar wrote:
> On 20-10-25, 09:35, 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. Since the Clk type is thread-safe, implement the relevant
> > traits.
> > 
> > Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> > ---
> >  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.
> >          ///
> 
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

I'm guessing this means you want me to take it through drm-rust? See
what I put in the cover letter about choice of tree.

Alice

Re: [PATCH v2 1/2] rust: clk: implement Send and Sync

[Danilo Krummrich]

On 10/20/25 11:35 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. Since the Clk type is thread-safe, implement the relevant
> traits.
> 
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>

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

Re: [PATCH v2 2/2] tyr: remove impl Send/Sync for TyrData

[Danilo Krummrich]

On 10/20/25 11:35 AM, Alice Ryhl wrote:
> Now that clk implements Send and Sync, we no longer need to manually
> implement these traits for TyrData. Thus remove the implementations.
> 
> The comment also mentions the regulator. However, the regulator had the
> traits added in commit 9a200cbdb543 ("rust: regulator: implement Send
> and Sync for Regulator<T>"), which is already in mainline.
> 
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>

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

Re: [PATCH v2 1/2] rust: clk: implement Send and Sync

[Viresh Kumar]

On 22-10-25, 08:19, Alice Ryhl wrote:
> I'm guessing this means you want me to take it through drm-rust? See
> what I put in the cover letter about choice of tree.

I was expecting Stephen to pick it up directly.

-- 
viresh

Re: [PATCH v2 1/2] rust: clk: implement Send and Sync

[Alice Ryhl]

On Wed, Oct 22, 2025 at 03:03:26PM +0530, Viresh Kumar wrote:
> On 22-10-25, 08:19, Alice Ryhl wrote:
> > I'm guessing this means you want me to take it through drm-rust? See
> > what I put in the cover letter about choice of tree.
> 
> I was expecting Stephen to pick it up directly.

Ah, that's fine, thanks.

Alice