Re: iio: accel: dmard09: in_accel_scale always returns -EINVAL

[Maxwell Doose]

Hi Mert,

On Wed, Jun 17, 2026 at 11:10 AM Mert Seftali <mertsftl@xxxxxxxxx> wrote:
>
> Hi,
>
> I've been digging into IIO to learn my way around it, and the dmard09
> accelerometer driver caught my eye as I think its scale attribute has
> been broken since day one, so I wanted to flag it.
>
> The channels advertise scale:
>
>     .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),
>
> which makes the core create in_accel_scale. The trouble is
> dmard09_read_raw() never handles IIO_CHAN_INFO_SCALE, it only does
> RAW, and SCALE drops straight into 'default: return -EINVAL'. So
> reading the scale just errors out:
>
>     $ cat .../iio:deviceX/in_accel_scale
>     cat: in_accel_scale: Invalid argument
>
> and userspace is left with raw counts it can't turn into m/s^2.
>

Interesting, so userspace was broken from the start.

>
> To be clear about how I found this: I don't have the hardware, I traced
> it through the core (iio_read_channel_info() -> read_raw() with the
> SCALE mask) rather than seeing it fail on a device. But the path looks
> unambiguous.
>
> I went looking to fix it properly; add a SCALE case returning the
> sensitivity, the way dmard06 and dmard10 do, but I couldn't find a
> DMARD09 datasheet anywhere. Digging through the list archives, it looks
> like the scale was declared in the original 2016 submission but never
> implemented, and the driver was written from a vendor source without a
> datasheet to begin with. So I don't have a real number to use, and I'd
> rather not make one up.
>

If you can, try contacting the vendor, they may have a datasheet to
reference. Otherwise check Documentation/iio/ because sometimes
dev-written datasheets will end up in there.

>
> Hence the email instead of a patch: would you prefer to just drop the
> scale declaration so the driver stops advertising something it can't
> deliver, or does anyone happen to have the DMARD09 sensitivity so it
> can be done right? I'm happy to send a patch either way.
>

Perhaps the scale declaration should be dropped; I'd argue if it's
unimplemented it's dead, and dead code removal is always a good thing
:) Let's let the maintainer for this driver chime in first though
because I wonder if they might just want you to implement it.

-- 
best regards,
max