Re: [PATCH v3 1/3] rust: clk: use the type-state pattern

["Danilo Krummrich" <dakr@kernel.org>]

On Thu Feb 12, 2026 at 8:59 AM CET, Maxime Ripard wrote:
> On Wed, Feb 11, 2026 at 05:47:09PM +0100, Danilo Krummrich wrote:
>> On Wed Feb 11, 2026 at 5:37 PM CET, Maxime Ripard wrote:
>> > I do think we can find a compromise though. Miguel suggested for example
>> > to make the current enable/prepare/disable/unprepare function unsafe,
>> > and that's totally reasonable to me.
>> >
>> > Then we can implement the "managed" clock version on that unsafe API,
>> 
>> What do you mean with "managed" clock? Do you mean devres managed? If so, I
>> don't think there is any reason to switch to the unsafe API to be able to
>> implement devres managed APIs (see also [1]).
>> 
>> [1] https://lore.kernel.org/all/DFVW9MS5YLON.CVJDBYQKJ0P6@kernel.org/
>
> By that, I mean what Daniel has been proposing to achieve with this series.
>
>> > and we would end up with a "raw", unsafe, version kind of equivalent to
>> > the one we have today, and where callers would have to justify why their
>> > usage of the API is actually safe, or the new, managed, variant that is
>> > safe and can be easily used by most drivers.
>> >
>> > And we can call these RawClk vs Clk, or Clk vs ManagedClk, or whatever.
>> >
>> > How does that sound?
>> 
>> What about we just wait until we have a user that really requires an unsafe API
>> for some reason? And if it never appears, even better. :)
>
> It works *today*.
>
> And the "oh but driver is using the API" is kind of ironic in the
> context of the Rust bindings which have globally been in that situation
> for years. You can't argue it both ways.

I can't remember ever advocating for merging code that does not have at least a
user in prospect.

> Either way, I'm not sure what the point of that submission was if you
> will just dismiss diverging opinions, including attempts to compromise.

Sorry -- I'm a bit confused here, since I did not submit this code.

I'm also not dismissing your opinion; I just have a different one.

In particular, I don't think we need an unsafe API until we see a concrete
example where the proposed safe API does not work (and no other safe API would
work either).

Framing a difference in opinion as "dismissing diverging opinions" doesn't feel
fair to me.

> Do whatever you want, but it's really hard to root for you some times.

I'm starting to wonder if the mail is addressed to me in the first place.

Thanks,
Danilo

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv