iio: accel: dmard09: in_accel_scale always returns -EINVAL

iio: accel: dmard09: in_accel_scale always returns -EINVAL

[Mert Seftali]

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.

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.

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.

Thanks,
Mert

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@gmail.com> 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

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

[Mert Seftali]

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@gmail.com>:
>
> Hi Mert,
>
> On Wed, Jun 17, 2026 at 11:10 AM Mert Seftali <mertsftl@gmail.com> 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

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

[Joshua Crofts]

On Thu, 18 Jun 2026 18:08:58 +0200
Mert Seftali <mertsftl@gmail.com> wrote:

> 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.

Did some research with Gemini and found out that Domintech went bust...
The cover letter for the original submission mentions that the driver
was essentially ported from the Android driver for the DMARD09 (the
Github link for it is dead).

FWIW I found a datasheet for the DMARD06, so maybe it could help
https://www.scribd.com/document/358640331/Accelerometer-DMARD06-Datasheet-V1-0-pdf

-- 
Kind regards

CJD

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

[Mert Seftali]

Hi Joshua,

Thanks for digging into this, their bust explains the missing datasheet.

On the dmard06 sheet, i don't think it carries over though. dmard06 is
a different part as far as i understood: that driver works on an 8-bit
sample with its own scale,
while dmard09 does its own undocumented bit-twiddling on a 16-bit read
(the "<<4 >>7, remove lower
3 bits" dance). Different sample format, and dmard09's resolution isn't
even spelled out in the code, so even with dmard06's range i'd be
guessing dmard09's scale, which is the bit i wanted to avoid.

So unless the real dmard09 numbers turn up, dropping the dead scale
declaration still looks like the honest fix imo. Happy either way once
Jonathan weighs in.


Mert