On Mon Jan 19, 2026 at 12:35 PM GMT, Alice Ryhl wrote:
> On Mon, Jan 19, 2026 at 11:45:57AM +0100, Maxime Ripard wrote:
>> On Thu, Jan 08, 2026 at 11:14:37AM -0300, Daniel Almeida wrote:
>> > > For example, it's quite typical to have (at least) one clock for the bus
>> > > interface that drives the register, and one that drives the main
>> > > component logic. The former needs to be enabled only when you're
>> > > accessing the registers (and can be abstracted with
>> > > regmap_mmio_attach_clk for example), and the latter needs to be enabled
>> > > only when the device actually starts operating.
>> > >
>> > > You have a similar thing for the prepare vs enable thing. The difference
>> > > between the two is that enable can be called into atomic context but
>> > > prepare can't.
>> > >
>> > > So for drivers that would care about this, you would create your device
>> > > with an unprepared clock, and then at various times during the driver
>> > > lifetime, you would mutate that state.
>
> The case where you're doing it only while accessing registers is
> interesting, because that means the Enable bit may be owned by a local
> variable. We may imagine an:
>
> let enabled = self.prepared_clk.enable_scoped();
> ... use registers
> drop(enabled);
>
> Now ... this doesn't quite work with the current API - the current
> Enabled stated owns both a prepare and enable count, but the above keeps
> the prepare count in `self` and the enabled count in a local variable.
> But it could be done with a fourth state, or by a closure method:
>
> self.prepared_clk.with_enabled(|| {
> ... use registers
> });
>
> All of this would work with an immutable variable of type Clk<Prepared>.
>
>> > > AFAIU, encoding the state of the clock into the Clk type (and thus
>> > > forcing the structure that holds it) prevents that mutation. If not, we
>> > > should make it clearer (by expanding the doc maybe?) how such a pattern
>> > > can be supported.
>> > >
>> > > Maxime
>> >
>> > IIUC, your main point seems to be about mutating the state at runtime?
>> > This is
>> > possible with this code. You can just have an enum, for example:
>> >
>> > enum MyClocks {
>> > Unprepared(Clk<Unprepared>),
>> > Prepared(Clk<Prepared>),
>> > Enabled(Clk<Enabled>),
>> > }
>
> I believe you need an extra state if the state is not bound to the scope
> of a function:
>
> enum MyClocks {
> Unprepared(Clk<Unprepared>),
> Prepared(Clk<Prepared>),
> Enabled(Clk<Enabled>),
> Transitioning,
> }
>
> since mem::replace() needs a new value before you can take ownership of
> the existing Clk value.
We can provide `replace_with` in the kernel, it's fine as we don't have
unwinding panics.
Best,
Gary
