From: "Nuno Sá" <noname.nuno@gmail.com>
To: Muchamad Coirul Anwar <muchamadcoirulanwar@gmail.com>
Cc: jic23@kernel.org, lars@metafoo.de, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org,
andi.shyti@kernel.org, wsa+renesas@sang-engineering.com,
ojeda@kernel.org, dakr@kernel.org, igor.korotin@linux.dev,
branstj@gmail.com
Subject: Re: [RFC PATCH v4 3/3] iio: position: add Rust driver for ams AS5600
Date: Tue, 4 Aug 2026 15:57:17 +0100 [thread overview]
Message-ID: <anH7kbxvS6z5GlPI@nsa> (raw)
In-Reply-To: <20260707151542.91997-4-muchamadcoirulanwar@gmail.com>
Hi Coirul,
Same as Jonathan on my rust capabilities (maybe now I'll have proper
motivation to learn it :)).
Just one question below...
On Tue, Jul 07, 2026 at 10:15:42PM +0700, Muchamad Coirul Anwar wrote:
> Add a Rust driver for the ams AS5600 12-bit magnetic rotary position
> sensor. The driver exposes in_angl_raw and in_angl_scale via the IIO
> sysfs interface.
>
> Features:
> - ARef<I2cClient> for safe refcounted I2C client access
> - Mutex-serialized status + angle read sequence
> - Static channel spec (module-level const)
> - No magnet validation at probe (deferred to read_raw per IIO convention)
> - Error propagation via ? operator (no recovery state machine)
>
> The byte order for the AS5600's big-endian registers is handled via
> swap_bytes() in-driver. This is equivalent to C's
> i2c_smbus_read_word_swapped(). The long-term solution is regmap-rs
> where endianness is configured once at the transport level.
>
> Tested on BeagleBone Black (AM335x) with AS5600 on i2c-2 (0x36).
>
> Signed-off-by: Muchamad Coirul Anwar <muchamadcoirulanwar@gmail.com>
> ---
...
> +impl IioDriver for As5600Priv {
> + fn read_raw(&self, _chan: *const iio_chan_spec, mask: isize) -> Result<IioVal> {
> + const INFO_RAW: isize = iio_chan_info_enum_IIO_CHAN_INFO_RAW as isize;
> + const INFO_SCALE: isize = iio_chan_info_enum_IIO_CHAN_INFO_SCALE as isize;
Likely stupid question but do we always need the above? Some drivers might have
several INFO_* bits sets and we often need to nest the match if multiple channels have the
same bits. For those cases having to define all of them like this and
then doing the match seems not great to me. I guess we can directly have
` iio_chan_info_enum_IIO_CHAN_INFO_RAW as isize` in match but not sure
if it's also that neat...
So bottom line, it would be nice if we could have something nicely
readable that we could directly pass to match.
On another topic, I believe mask is present in several drivers for
historic reasons but note that this parameter is not really a mask. So
other name like 'info' is more appropriate.
- Nuno Sá
next prev parent reply other threads:[~2026-08-04 14:56 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 15:15 [RFC PATCH v4 0/3] iio: position: add Rust driver for ams AS5600 Muchamad Coirul Anwar
2026-07-07 15:15 ` [RFC PATCH v4 1/3] i2c: rust: implement SMBus read abstraction via kernel::io::Io for I2cClient Muchamad Coirul Anwar
2026-07-11 10:05 ` Igor Korotin
2026-07-11 12:05 ` Danilo Krummrich
2026-07-14 16:08 ` Muchamad Coirul Anwar
2026-07-18 2:48 ` Bruce Robertson
2026-07-19 15:40 ` Muchamad Coirul Anwar
2026-07-19 23:02 ` Danilo Krummrich
2026-07-20 2:26 ` Muchamad Coirul Anwar
2026-07-11 12:08 ` Danilo Krummrich
2026-07-14 16:10 ` Muchamad Coirul Anwar
2026-08-03 0:53 ` Jonathan Cameron
2026-08-03 8:14 ` Muchamad Coirul Anwar
2026-07-07 15:15 ` [RFC PATCH v4 2/3] rust: add minimal IIO subsystem abstractions Muchamad Coirul Anwar
2026-07-11 12:12 ` Danilo Krummrich
2026-07-14 16:20 ` Muchamad Coirul Anwar
2026-08-03 0:43 ` Jonathan Cameron
2026-08-03 7:24 ` Muchamad Coirul Anwar
2026-07-07 15:15 ` [RFC PATCH v4 3/3] iio: position: add Rust driver for ams AS5600 Muchamad Coirul Anwar
2026-08-03 1:13 ` Jonathan Cameron
2026-08-06 1:54 ` Muchamad Coirul Anwar
2026-08-04 14:57 ` Nuno Sá [this message]
2026-08-06 2:51 ` Muchamad Coirul Anwar
2026-07-08 10:36 ` [RFC PATCH v4 0/3] " Miguel Ojeda
2026-07-08 12:37 ` 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=anH7kbxvS6z5GlPI@nsa \
--to=noname.nuno@gmail.com \
--cc=andi.shyti@kernel.org \
--cc=branstj@gmail.com \
--cc=dakr@kernel.org \
--cc=igor.korotin@linux.dev \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=muchamadcoirulanwar@gmail.com \
--cc=ojeda@kernel.org \
--cc=wsa+renesas@sang-engineering.com \
/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