On 05/01/2012 09:56 AM, Jonathan Cameron wrote: > On 4/30/2012 9:01 PM, Lars-Peter Clausen wrote: >> On 04/30/2012 09:26 PM, joseph daniel wrote: >>> Signed-off-by: joseph daniel<josephdanielwalter@xxxxxxxxx> >>> --- >>> Hi Lars, >>> Thanks for review. how about the below change? >>> drivers/staging/iio/meter/ade7854-i2c.c | 6 +++++- >>> 1 file changed, 5 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/staging/iio/meter/ade7854-i2c.c >>> b/drivers/staging/iio/meter/ade7854-i2c.c >>> index 1e1faa0..52bdb05 100644 >>> --- a/drivers/staging/iio/meter/ade7854-i2c.c >>> +++ b/drivers/staging/iio/meter/ade7854-i2c.c >>> @@ -181,6 +181,7 @@ static int ade7854_i2c_read_reg_32(struct device >>> *dev, >>> { >>> struct iio_dev *indio_dev = dev_get_drvdata(dev); >>> struct ade7854_state *st = iio_priv(indio_dev); >>> + uint32_t value; >>> int ret; >>> >>> mutex_lock(&st->buf_lock); >>> @@ -195,7 +196,10 @@ static int ade7854_i2c_read_reg_32(struct device >>> *dev, >>> if (ret) >>> goto out; >>> >>> - *val = (st->rx[0]<< 24) | (st->rx[1]<< 16) | (st->rx[2]<< 8) >>> | st->rx[3]; >>> + memcpy(&value, st->rx, sizeof(uint32_t)); >>> + >> Uhm, yes, you are right st->rx is unaligned. The memcpy is not >> necessary though >> if you use get_unaligned_be32. Sorry for the pointer to the wrong >> function. > Or we could just force the alignment of st->rx? Might not be worth > bothering. Yes, but be32_to_cpu wants a be32 and there is another functions which only does a 16 bit access on rx, so we'd need to cast and things get messy. Also for tx we store first a 16bit value and then a 32bit value and while it is possible to get this properly aligned this gets a bit messy too. I think we are fine with {get,set}_unaligned for now. -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html