From: Jonathan Cameron <jic23@kernel.org>
To: Muchamad Coirul Anwar <muchamadcoirulanwar@gmail.com>
Cc: linux-iio@vger.kernel.org, rust-for-linux@vger.kernel.org,
linux-kernel@vger.kernel.org, Miguel Ojeda <ojeda@kernel.org>,
Igor Korotin <igor.korotin.linux@gmail.com>,
Brandon Saint-John <branstj@gmail.com>
Subject: Re: [RFC PATCH v3 3/4] iio: position: add Rust driver for ams AS5600
Date: Tue, 2 Jun 2026 13:06:42 +0100 [thread overview]
Message-ID: <20260602130642.068b24ea@jic23-huawei> (raw)
In-Reply-To: <CAO26r3R5+xYQM=_uxF32MQRuxkhpeY3bTwq6M3o8dPCr8-kdnA@mail.gmail.com>
> > > + let angle_h = match hw_guard.io.try_read8(AS5600_REG_RAW_ANGLE_H as usize) {
> > > + Ok(v) => v as u16,
> > > + Err(_) => return Err(hw_guard.handle_io_error()),
> > > + };
> > > + let angle_l = match hw_guard.io.try_read8(AS5600_REG_RAW_ANGLE_L as usize) {
> > > + Ok(v) => v as u16,
> > > + Err(_) => return Err(hw_guard.handle_io_error()),
> > > + };
> > > +
> > > + let angle = (angle_h << 8 | angle_l) & 0x0FFF;
> >
> > This is the sort of thing we'd never do in a C driver because we have well
> > defined meaningful functions / macros for doing this. I'd like to see
> > something equivalent in the rust code of.
> > Bulk read int a two byte array. i2c_smbus_read_word_data() or swapped variant.
> > Unaligned endian read get_unaligned_be16()
> > Masking to extract the 12 bits that are valid. FIELD_GET() whatever.
>
> Switching to `try_read16()` (calls `i2c_smbus_read_word_data`) plus
> `swap_bytes()` for the byte order, then mask:
>
> const AS5600_RAW_ANGLE_MASK: u16 = 0x0FFF;
>
> let raw = client.try_read16(AS5600_REG_RAW_ANGLE_H as usize)?;
> let angle = raw.swap_bytes() & AS5600_RAW_ANGLE_MASK;
That swap goes back to a pattern we ripped out of the C code years ago
and why we have the smbus swapped functions and regmap support fort htat.
If a given part always does the bytes in opposite byte order of smbus
then it should be handled as part of the read function rather than every
word read having to be followed by a swap. Here you only have one so
it doesn't look that bad, but for some other devices this is the common
call sequence to ready almost anything.
>
> Rust doesn't have FIELD_GET yet, but a named constant serves the same
> documentation purpose. Single call, no manual byte assembly.
A named constant serves only part of the purpose. The main gain from FIELD_GET()
is we don't have to go check if a shift is also needed. I'd strongly
support work on getting something similar for rust as it makes for a lot
more consistent and readable driver code.
Basically I want all the useful helper stuff we've built up in C to be
available in Rust. In cases like this one I would prefer there was never
a legacy of doing it any other way!
Jonathan
next prev parent reply other threads:[~2026-06-02 12:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-24 13:28 [RFC PATCH v3 0/4] iio: position: add Rust driver for ams AS5600 Muchamad Coirul Anwar
2026-05-24 13:28 ` [RFC PATCH v3 1/4] i2c: rust: implement kernel::io::Io trait for I2cClient Muchamad Coirul Anwar
2026-05-28 15:25 ` Jonathan Cameron
2026-06-01 7:58 ` Muchamad Coirul Anwar
2026-06-01 9:05 ` Jonathan Cameron
2026-06-02 8:11 ` Muchamad Coirul Anwar
2026-06-02 11:59 ` Jonathan Cameron
2026-05-24 13:28 ` [RFC PATCH v3 2/4] rust: add minimal IIO subsystem abstractions Muchamad Coirul Anwar
2026-05-28 16:09 ` Jonathan Cameron
2026-06-01 8:30 ` Muchamad Coirul Anwar
2026-06-01 9:10 ` Jonathan Cameron
2026-05-24 13:28 ` [RFC PATCH v3 3/4] iio: position: add Rust driver for ams AS5600 Muchamad Coirul Anwar
2026-05-28 16:08 ` Jonathan Cameron
2026-06-01 11:11 ` Muchamad Coirul Anwar
2026-06-02 12:06 ` Jonathan Cameron [this message]
2026-06-03 8:52 ` Muchamad Coirul Anwar
2026-05-29 5:37 ` Brandon Saint-John
2026-06-01 11:33 ` Muchamad Coirul Anwar
2026-05-24 13:28 ` [RFC PATCH v3 4/4] iio: position: as5600: add Kconfig and Makefile entries Muchamad Coirul Anwar
2026-05-28 16:09 ` Jonathan Cameron
2026-06-01 8:00 ` Muchamad Coirul Anwar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260602130642.068b24ea@jic23-huawei \
--to=jic23@kernel.org \
--cc=branstj@gmail.com \
--cc=igor.korotin.linux@gmail.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=muchamadcoirulanwar@gmail.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).