[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e92f919e59974bb2ae32a8d961e07538@analog.com>
Date: Wed, 21 Jun 2023 00:38:08 +0000
From: "Paller, Kim Seer" <KimSeer.Paller@...log.com>
To: Andy Shevchenko <andy.shevchenko@...il.com>
CC: "jic23@...nel.org" <jic23@...nel.org>,
"lars@...afoo.de" <lars@...afoo.de>,
"lgirdwood@...il.com" <lgirdwood@...il.com>,
"broonie@...nel.org" <broonie@...nel.org>,
"Hennerich, Michael" <Michael.Hennerich@...log.com>,
"robh@...nel.org" <robh@...nel.org>,
"krzysztof.kozlowski@...aro.org" <krzysztof.kozlowski@...aro.org>,
"conor+dt@...nel.org" <conor+dt@...nel.org>,
"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: RE: [PATCH v7 2/2] iio: adc: max14001: New driver
> -----Original Message-----
> From: Andy Shevchenko <andy.shevchenko@...il.com>
> Sent: Tuesday, June 20, 2023 11:15 PM
> To: Paller, Kim Seer <KimSeer.Paller@...log.com>
> Cc: jic23@...nel.org; lars@...afoo.de; lgirdwood@...il.com;
> broonie@...nel.org; Hennerich, Michael <Michael.Hennerich@...log.com>;
> robh@...nel.org; krzysztof.kozlowski@...aro.org; conor+dt@...nel.org; linux-
> iio@...r.kernel.org; linux-kernel@...r.kernel.org; devicetree@...r.kernel.org
> Subject: Re: [PATCH v7 2/2] iio: adc: max14001: New driver
>
> [External]
>
> On Tue, Jun 20, 2023 at 4:27 PM Kim Seer Paller
> <kimseer.paller@...log.com> wrote:
> >
> > The MAX14001 is configurable, isolated 10-bit ADCs for multi-range
> > binary inputs.
>
> ...
>
> > + /*
> > + * Align received data from the receive buffer, reversing and reordering
> > + * it to match the expected MSB-first format.
> > + */
> > + *data = (__force u16)(be16_to_cpu(bitrev16(st->spi_rx_buffer))) &
> > + MAX14001_DATA_MASK;
>
> Using __force in the C files is somehow stinky.
>
> ...
>
> > + /*
> > + * Convert transmit buffer to big-endian format and reverse transmit
> > + * buffer to align with the LSB-first input on SDI port.
> > + */
> > + st->spi_tx_buffer = (__force u16)(cpu_to_be16(bitrev16(
>
> You have a different type of spi_tx_buffer than u16, don't you?
I have the same type of spi_tx_buffer as u16.
Other than using force cast, is there any way to resolve the endian warning? I have
actually swapped the order of bitrev16() and cpu_to_be16/be16_to_cpu() functions.
I have tested and they also work fine.
Best regards,
Kim Seer Paller
Powered by blists - more mailing lists