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

[Jonathan Cameron]

On Tue, 30 Jun 2026 15:59:59 +0200
Mert Seftali <mertsftl@xxxxxxxxx> wrote:

> On Mon, 29 Jun 2026 21:06:..., Jelle van der Waa wrote:
> > Thanks for digging into this, I no longer have the device in question.
> > But the vendor driver can be found on GitHub:
> >
> > https://github.com/minstrelsy/mediatek/blob/.../dmard09/dmard09.c  
> 
> Thanks Jelle, got this from the repository;
> 
> It has the sensitivity, and it's used in the driver's own conversion:
> 
>     acc = raw * GRAVITY_EARTH_1000 / sensitivity   (then / 1000 -> m/s^2)
> 
> with sensitivity = 32 and GRAVITY_EARTH_1000 = 9807 ("about
> (9.80665)*1000" in the MTK header), so 32 counts == 1 g.
> 
> It also clears up that bit-twiddling i was worried about. The vendor does
> 'data >>= 3; data &= 0x1ff' plus a sign-extend of bit 8 on the 16-bit
> read, i.e. a signed 9-bit value (register bits [11:3]), and our '<<4 >>7'
> dance lands on the exact same number. So the 32 applies to what the driver
> already returns as raw. Self consistent too: 256 / 32 = 8g, which matches
> the +/-8g.
> 
> So this time i think we can implement it instead of dropping it:
> 
>     scale = 9.80665 / 32 = 0.3064578125 m/s^2 per LSB
> 
> happy to send that Jonathan, it's the vendor's 32, so same
> no-datasheet situation as before. or just drop the scale declaration if
> you'd rather not. Whichever way you point.

Thanks for digging into this.  Ideally good to fix it if we can rather
than just dropping the support.  If it looks doubtful dropping is fine
given it never worked anyway so it's not a regression :)

Which is basically me saying I'll take either - up to you!

Jonathan

> 
> 
> Thanks,
> Mert
> 
> 
> Am Mo., 29. Juni 2026 um 21:06 Uhr schrieb Jelle van der Waa <jelle@xxxxxxxx>:
> >
> > Hi,
> >
> > On 17/06/2026 17:53, Mert Seftali 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.
> > >
> > > 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.  
> > Thanks for digging into this, I no longer have the device in question.
> > But the vendor driver can be found on GitHub:
> >
> > https://github.com/minstrelsy/mediatek/blob/1f49d8c87b839651bc89afc870277e8e0f2e2d55/custom/common/kernel/accelerometer/dmard09/dmard09.c
> >
> > Greetings,
> >
> > Jelle van der Waa