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_QUATERNION(), to declare the
array with proper alignment. This is meant to follow the pattern of
the similar IIO_DECLARE_BUFFER_WITH_TS() macro.

Signed-off-by: David Lechner <dlechner@baylibre.com>
---
Changes in v2:
- Rename IIO_DECLARE_REPEATED_ELEMENT() to IIO_DECLARE_QUATERNION().
- Link to v1: https://lore.kernel.org/r/20260214-iio-fix-repeat-alignment-v1-0-47f01288c803@baylibre.com

---
David Lechner (2):
      iio: add IIO_DECLARE_QUATERNION() macro
      iio: orientation: hid-sensor-rotation: fix quaternion alignment

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

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

On Sat, Feb 28, 2026 at 02:02:21PM -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_QUATERNION(), to declare the
> array with proper alignment. This is meant to follow the pattern of
> the similar IIO_DECLARE_BUFFER_WITH_TS() macro.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

But this is in conflict with the other hack-patch in another series.
I'm a bit lost what patch 2 fixes here and that hack-patch fixes
in the same driver. Shouldn't survive only one?

-- 
With Best Regards,
Andy Shevchenko

On Mon, 2026-03-02 at 10:58 +0200, Andy Shevchenko wrote:
> On Sat, Feb 28, 2026 at 02:02:21PM -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_QUATERNION(), to declare the
> > array with proper alignment. This is meant to follow the pattern of
> > the similar IIO_DECLARE_BUFFER_WITH_TS() macro.
> 
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> 
> But this is in conflict with the other hack-patch in another series.
> I'm a bit lost what patch 2 fixes here and that hack-patch fixes
> in the same driver. Shouldn't survive only one?

+1.

I see this is older so should we only look at the other series?

- Nuno Sá

On 3/2/26 6:32 AM, Nuno Sá wrote:
> On Mon, 2026-03-02 at 10:58 +0200, Andy Shevchenko wrote:
>> On Sat, Feb 28, 2026 at 02:02:21PM -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_QUATERNION(), to declare the
>>> array with proper alignment. This is meant to follow the pattern of
>>> the similar IIO_DECLARE_BUFFER_WITH_TS() macro.
>>
>> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
>>
>> But this is in conflict with the other hack-patch in another series.
>> I'm a bit lost what patch 2 fixes here and that hack-patch fixes
>> in the same driver. Shouldn't survive only one?
> 
> +1.
> 
> I see this is older so should we only look at the other series?
> 
> - Nuno Sá

They are fixing two separate bugs.

This bug (which is a recent regression) is that the size of the struct is
wrong. It is supposed to be 32 bytes, but a recent change make it only 24.
This causes iio_push_to_buffers_with_ts() to write over data past the end
of the struct.

The other bug (which has been a bug for 6 years) is that the the timestamp
is in the wrong place. That patch also has an effect of making the struct
the right size, but that is only a side-effect.

So yes, I should have mentioned that in the cover letter that this series
should probably be applied first since it is the worse bug. And it looks
like I'll be doing a v2 of the other series anyway, so I can properly rebase
it and declare the dependency.

On Mon, 2 Mar 2026 09:52:58 -0600
David Lechner <dlechner@baylibre.com> wrote:

> On 3/2/26 6:32 AM, Nuno Sá wrote:
> > On Mon, 2026-03-02 at 10:58 +0200, Andy Shevchenko wrote:  
> >> On Sat, Feb 28, 2026 at 02:02:21PM -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_QUATERNION(), to declare the
> >>> array with proper alignment. This is meant to follow the pattern of
> >>> the similar IIO_DECLARE_BUFFER_WITH_TS() macro.  
> >>
> >> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> >>
> >> But this is in conflict with the other hack-patch in another series.
> >> I'm a bit lost what patch 2 fixes here and that hack-patch fixes
> >> in the same driver. Shouldn't survive only one?  
> > 
> > +1.
> > 
> > I see this is older so should we only look at the other series?
> > 
> > - Nuno Sá  
> 
> They are fixing two separate bugs.
> 
> This bug (which is a recent regression) is that the size of the struct is
> wrong. It is supposed to be 32 bytes, but a recent change make it only 24.
> This causes iio_push_to_buffers_with_ts() to write over data past the end
> of the struct.
> 
> The other bug (which has been a bug for 6 years) is that the the timestamp
> is in the wrong place. That patch also has an effect of making the struct
> the right size, but that is only a side-effect.
> 
> So yes, I should have mentioned that in the cover letter that this series
> should probably be applied first since it is the worse bug. And it looks
> like I'll be doing a v2 of the other series anyway, so I can properly rebase
> it and declare the dependency.
> 
> 
I've applied these two to the fixes-togreg branch with them marked for stable
inclusion.  For the first one I added a comment to the tags block to say
it's stable as a precusor for the second.

Thanks,

Jonathan