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.

Signed-off-by: David Lechner <dlechner@baylibre.com>
---
David Lechner (2):
      iio: add IIO_DECLARE_REPEATED_ELEMENT() macro
      iio: orientation: hid-sensor-rotation: fix quaternion alignment

 drivers/iio/orientation/hid-sensor-rotation.c |  2 +-
 include/linux/iio/iio.h                       | 13 +++++++++++++
 2 files changed, 14 insertions(+), 1 deletion(-)
---
base-commit: 0f11bb7985ceef2aeeb5c45c3c7bfff3f5a16e03
change-id: 20260214-iio-fix-repeat-alignment-575b2c009e25

Best regards,
-- 
David Lechner <dlechner@baylibre.com>

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() ?

-- 
With Best Regards,
Andy Shevchenko

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() ?
> 

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.

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() ?
> 
> 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?

-- 
With Best Regards,
Andy Shevchenko

On Tue, 17 Feb 2026 10:10:53 +0200
Andy Shevchenko <andriy.shevchenko@intel.com> 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