linux-kernel - Re: [PATCH] iio: pressure: bmp280: drop sensor

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHp75VcHMTSGRrodixsLDS-xCi8KQJ0MtMSMi7tfATUgd3E5uA@mail.gmail.com>
Date: Wed, 23 Apr 2025 01:19:15 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: David Lechner <dlechner@...libre.com>
Cc: Jonathan Cameron <jic23@...nel.org>, Nuno Sá <nuno.sa@...log.com>, 
	Andy Shevchenko <andy@...nel.org>, linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] iio: pressure: bmp280: drop sensor_data array

On Wed, Apr 23, 2025 at 12:22 AM David Lechner <dlechner@...libre.com> wrote:
>
> On 4/22/25 3:57 PM, Andy Shevchenko wrote:
> > On Tue, Apr 22, 2025 at 10:28 PM David Lechner <dlechner@...libre.com> wrote:
> >>
> >> Drop the sensor_data array from struct bmp280_data and replace it using
> >> local structs in each interrupt handler.
> >>
> >> The sensor_data array in struct bmp280_data is not used to share data
> >> between functions and isn't used for DMA, so there isn't really a need
> >> to have it in the struct. Instead, we can use the struct pattern for
> >> scan data in each interrupt handler. This has the advantage of allowing
> >> us to see the actual layout of each scan buffer for each different type
> >> of supported sensor. It also avoid juggling values between local
> >
> > of the supported
>
> I think what I wrote is correct grammar. Same as if I would have written
> "each type of sensor". I would not write "each type of the sensor".

Ah, I meant the plural: of the supported sensors. Otherwise are you
talking only about one sensor?

> >> variables and the array which makes the code a bit simpler by avoiding
> >> some extra assignments.
> >>
> >> We can also drop the BME280_NUM_MAX_CHANNELS macro as it is no longer
> >> used.
> >
> > I like this change so much, thanks!
> > But one comment below.
> >
> > Reviewed-by: Andy Shevchenko <andy@...nel.org>

...

> >>         /* Pressure calculations */
> >> -       memcpy(&data->sensor_data[offset], &data->buf[3], 3);
> >> -
> >> -       offset += sizeof(s32);
> >> +       memcpy(&buffer.comp_press, &data->buf[3], 3);
> >>
> >>         /* Temperature calculations */
> >> -       memcpy(&data->sensor_data[offset], &data->buf[0], 3);
> >> +       memcpy(&buffer.comp_temp, &data->buf[0], 3);
> >
> > Shouldn't these memcpy():s be get_unaligned_be24()/get_unaligned_le24()?
>
> The scan_type.endianness is already defined as IIO_LE, so we must preserve the
> the little-endian order, even on big-endian systems.

Okay. so this should be native, thanks for elaborating this.

-- 
With Best Regards,
Andy Shevchenko