Re: [RFC PATCH v3 2/4] rust: add minimal IIO subsystem abstractions

[Muchamad Coirul Anwar]

On Thu, 28 May 2026 17:09:00 +0100
Jonathan Cameron <jic23@xxxxxxxxxx> wrote:

> You'll need a lot more stuff before it makes any sense to be messing
> with claims on the state.  They only come in once drivers are dealing
> with buffers etc. I'd leave them until then.

> As above with the level of bindings you are doing so far, neither of these
> should ever be called.  They are not for use by drivers simply wanting
> to serialize things but about controlling the ability of the IIO core to
> change the fundamental data flow from simple polling to streaming data to
> user space accessible kfifos.

Understood. I was conflating "serialize concurrent sysfs reads" with
"prevent mode transitions", which are two different things. The driver's
Mutex handles the former; DirectModeGuard is for the latter and has no
business being here until buffer support exists.

Dropping DirectModeGuard entirely from v4: struct, C helpers, and the
trampoline call. Will bring it back when adding buffer/trigger support,
where it belongs in the individual driver rather than the generic
trampoline.

> Sort of. It ensures the state doesn't change.  Given buffer/trigger
> operations only occur when in a buffer state it sort of prevents their
> operations. That's not including stuff like setting up buffers though -
> just the data streaming.
>
> Anyhow, kick it in the long grass (drop for now) given you don't support
> buffer state. Good to see what this probably looks like though.

Noted. Good to have the shape sketched out at least.

> We only need to do this if the particular device the driver is supporting
> needs for the specific operation to ensure that no accesses occur to
> the device. We should not do this for reading stuff back that is cached in the
> driver for instance.  In many cases devices have interfaces where absolutely
> anything is safe in buffer modes.
>
> This is unfortunately going to be hard to do other than in specific drivers
> that knows those rules. + doesn't belong here at all yet as a rust driver
> can't get into a state where this fails and should never be relying on this
> for its own synchronization (e.g. between concurrent calls of read_raw()).

Right. The trampoline shouldn't be making policy decisions about when to
claim direct mode, that's driver-specific knowledge. Removing from the
generic abstraction.

> why .get() for this one.

I used .get() because NonZeroI32 is a wrapper type, meaning we have to
explicitly extract the
inner i32. Since the other variants use a plain i32, they don't need
it. I'll add a quick comment in
v4 to clarify this.

> The data accessed in c by iio_priv() is zeroed, not uninitialized but
> I'm not sure that's what you are referring to.

You're right, `iio_device_alloc` uses `kzalloc`, so `priv_` is zeroed.
The SAFETY comment was wrong. Fixing in v4 to say "zeroed memory" and
note that PinInit overwrites it with the initialized state.

> Can channels be static const?  It is in most IIO drivers written in C.

Yes. Moving it to a module-level static in v4. That removes the KBox
allocation and the lifetime question around `indio_dev->channels`
outliving `priv_`.

Thanks,
Coirul