Re: [PATCH 0/2] iio: orientation: hid-sensor-rotation: fix quaternion alignment

[Jonathan Cameron]

On Tue, 17 Feb 2026 10:10:53 +0200
Andy Shevchenko <andriy.shevchenko@xxxxxxxxx> wrote:

> On Mon, Feb 16, 2026 at 09:25:58AM -0600, David Lechner wrote:
> > On 2/16/26 1:44 AM, Andy Shevchenko wrote:  
> > > On Sat, Feb 14, 2026 at 03:00:19PM -0600, David Lechner wrote:  
> > >> The main point of this series is to fix a regression reported in
> > >> hid-sensor-rotation where the alignment of the quaternion field in the
> > >> data was inadvertently changed from 16 bytes to 8 bytes. This is an
> > >> unusually case (one of only 2 in the kernel) where the .repeat field of
> > >> struct iio_scan_type is used and we have such a requirement. (The other
> > >> case uses u16 instead of u32, so it wasn't affected.)
> > >>
> > >> To make the reason for the alignment more explicit to future readers,
> > >> we introduce a new macro, IIO_DECLARE_REPEATED_ELEMENT, to declare the
> > >> array with proper allignment. This is meant to follow the pattern of
> > >> the similar IIO_DECLARE_BUFFER_WITH_TS() macro.  
> > > 
> > > In both cases it's quaternion, maybe be more explicit and define
> > > IIO_DECLARE_QUATERNION() ?  

I like this.  It's special and this shouts that nicely.

> > 
> > It is really the fact that the scan_type has .repeat > 1 that requires
> > this, so I was trying to make a name that shows that link.
> > 
> > But right now, quaternion is the only thing that has .repeat > 1, so
> > I guess it would be OK either way. We'll see if Jonathan has an
> > opinion on the naming.  
> 
> I think we should solve the problems when they appear. Naming explicitly
> for quaternion makes it easier to get from the core reading without having
> a variable name to repeat that. Magic 4  might not always be a quaternion.
> 
> Do we have "repeat" to be used in other cases, btw?
> 
Don't think so.

Note there is a second older bug here.
The timestamp is landing at the wrong location :(  See discussion of
original bug.  I suspect that applies to the bno055 as well (that avoids
the bug we are fixing in this patch because helpfully the quaternion is
a total of 8 bytes. 

Short story - it is just another channel, so should be naturally aligned
at first valid location after the previous channel. That's bytes 32-39 not
55-63 which is where iio_push_to_buffers_with_timestamp() puts it.


Jonathan