On Mon, Jan 19, 2026 at 12:35:21PM +0000, Alice Ryhl wrote: > > > In fact, I specifically wanted to ensure that this was possible when > > > writing > > > these patches, as it’s needed by drivers. If you want to, I can cover > > > that in > > > the examples, no worries. > > > > Yes, that would be great. I do wonder though if it wouldn't make sense > > to turn it the other way around. It creates a fair share of boilerplate > > for a number of drivers. Can't we keep Clk the way it is as a > > lower-level type, and crate a ManagedClk (or whatever name you prefer) > > that drivers can use, and would be returned by higher-level helpers, if > > they so choose? > > > > That way, we do have the typestate API for whoever wants to, without > > creating too much boilerplate for everybody else. > > I think that if you still want an API where you just call enable/disable > directly on it with no protection against unbalanced calls, then that > should be the special API. Probably called RawClk and functions marked > unsafe. Unbalanced calls seem really dangerous and use should not be > encouraged.
Sure, that makes sense to me. > The current type-state based API is the least-boilerplate option for > drivers that exist today. I wasn't saying that we should add boilerplate to the typestate API either. I was saying that the non-typestated API was common enough that we probably didn't want boilerplate for it either if possible. Maxime
signature.asc
Description: PGP signature
