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

[Jonathan Cameron <jic23@kernel.org>]

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