Re: [RFC PATCH] [RFC PATCH] iio: position: rust: add initial AS5600 driver

[Muchamad Coirul Anwar]

Hi Jonathan, Miguel,

Thank you both for taking the time to review this early RFC. I truly
appreciate the architectural pointers and the lessons on kernel driver
culture. It has been incredibly helpful.

On Mon, 20 Apr 2026 16:49:00 +0200 Miguel Ojeda
<miguel.ojeda.sandonis@xxxxxxxxx> wrote:
> On Mon, 20 Apr 2026 01:33:00 +0100 Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
> >
> > Do we have a rust equivalent of BIT()?  That tends to be easier to compare with
> > datasheets that don't use hex for this.
>
> We do! Please see:
>
>   https://rust.docs.kernel.org/kernel/bits/

Thanks for the pointer, Miguel. I will update the constants to use
`kernel::bits` in the next iteration so they map cleanly to the
datasheet.

On Mon, 20 Apr 2026 01:33:00 +0100 Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
> Have those been posted anywhere? Or are you working on them?
> I've kind of been wondering if anyone was interested in rust bindings
> for IIO drivers (and dreaming of having the time to write them), so
> this suggests that you are at least.
>
> In the mean time this stub of a driver isn't particularly interesting
> to review.  My concern is the common one on whether we will have enough
> folk familiar with both rust and IIO to review drivers.

To my knowledge, there are no official Rust IIO abstractions posted
yet. I initially planned to wait for them, but seeing the interest, I
will take the initiative to draft a minimal safe wrapper for `iio_dev`
and `iio_info`.

For v2, my goal is to implement just enough of the abstraction to
support the `read_raw` callback, allowing the AS5600 driver to
properly expose `in_angl_raw` and `in_angl_scale`. I will submit the
IIO abstractions as the first patch in the v2 series so the core
design can be reviewed independently.

> Push testing logs into a cover letter or under the --- so there is no
> chance we end up with them in the git log where they are too verbose.

Noted. All verbose testing logs will be moved below the `---` line or
into a cover letter in v2 to keep the commit history clean.

> ENODEV seems a bit too much of an indication the device is missing rather than
> the magnet.  From my vague understanding of how these are used, the
> magnet may not always be present so perhaps failing on this at probe is too strong?
> If it does make sense to fail, then fail on the strong / weak as well if
> that means the outputs are useless.

This is a great architectural point. I missed the perspective that the
physical magnet is an external factor, whereas the I2C chip is the
actual device being probed. I will remove the `-ENODEV` abort from
`probe()`. The driver will initialize successfully as long as the I2C
communication is verified. The AGC status and magnet validation will
be deferred to the `read_raw` callback instead.

> Too noisy. dev_dbg!() at most even when doing development (assuming that exists
> - this is only the second bit of rust I've ever reviewed ;)
>
> Definitely not, even in an RFC patch. These sorts of things can end up
> making it all the way to the upstream driver so dev_dbg!() only.

Understood. I will downgrade the `dev_info!` calls to `dev_dbg!` and
entirely drop the noise inside the `unbind` function.

Thanks again for the guidance. I will start working on the IIO
wrappers and the v2 patch series.

Best regards,
Muchamad Coirul Anwar

Pada Sel, 21 Apr 2026 pukul 16.49 Miguel Ojeda
<miguel.ojeda.sandonis@xxxxxxxxx> menulis:
>
> On Mon, Apr 20, 2026 at 8:33 PM Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
> >
> > Do we have a rust equivalent of BIT()?  That tends to be easier to compare with
> > datasheets that don't use hex for this.
>
> We do! Please see:
>
>   https://rust.docs.kernel.org/kernel/bits/
>
> Cheers,
> Miguel