From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
This is sort of a fix as I assume this device only exists on
architectures that do 8 byte alignment of 8 byte types. However,
drivers should not be written with that assumption and should allow
for the 4 byte alignment of these types as seen for example on
x86_32. As such, we need to force the alignment of the timestamp
field itself not the containing structure, which will also be aligned
appropriate given C structure alignment guarantees alignment to at least
the alignment of structure member that needs highest alignment.
This is even more in the 'sort of' category because if we did
have insufficient alignment of the timestamp, then marking the structure
__aligned(8) would result in padding after the timestamp field.
iio_push_to_buffers_with_timestamp() doesn't actually use the field, but
instead where it is expected to be so will place the timestamp
in the last 8 bytes, whether or not the structure definition puts it there.
Hence it all works before the change. The reasoning is too subtle,
just mark the right element aligned and use the new aligned_s64 to do so
also clearing up the inconsistency of an int64_t timestamp relative
to most other IIO drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
---
drivers/iio/adc/mt6360-adc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/adc/mt6360-adc.c b/drivers/iio/adc/mt6360-adc.c
index 4eb2455d6ffa..f8e98b6fa7e9 100644
--- a/drivers/iio/adc/mt6360-adc.c
+++ b/drivers/iio/adc/mt6360-adc.c
@@ -263,8 +263,8 @@ static irqreturn_t mt6360_adc_trigger_handler(int irq, void *p)
struct mt6360_adc_data *mad = iio_priv(indio_dev);
struct {
u16 values[MT6360_CHAN_MAX];
- int64_t timestamp;
- } data __aligned(8);
+ aligned_s64 timestamp;
+ } data;
int i = 0, bit, val, ret;
memset(&data, 0, sizeof(data));
--
2.47.1
