Re: iio: accel: dmard09: in_accel_scale always returns -EINVAL
From: Mert Seftali
Date: Thu Jun 18 2026 - 12:16:08 EST
Hey Max,
Thanks for the reply and hints. I checked Documentation/ and the
bindings and dmard09 is only in
trivial-devices.yaml, no datasheet notes or scale anywhere in tree.
Will wait for the maintainers call and If they agree on
implementation, I'll try to reach Domintech for the datasheet first so
the scale is a real number.
Mert
Am Do., 18. Juni 2026 um 17:47 Uhr schrieb Maxwell Doose <m32285159@xxxxxxxxx>:
>
> 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