linux-kernel - Re: linux-next: manual merge of the iio tree with the iio-fixes tree

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] [day] [month] [year] [list]
Message-ID: <20240502095834.00000e7c@Huawei.com>
Date: Thu, 2 May 2024 09:58:34 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@....com>
CC: Stephen Rothwell <sfr@...b.auug.org.au>, Linux Kernel Mailing List
	<linux-kernel@...r.kernel.org>, Linux Next Mailing List
	<linux-next@...r.kernel.org>
Subject: Re: linux-next: manual merge of the iio tree with the iio-fixes
 tree

 

On Thu, 2 May 2024 08:36:21 +0000
Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@....com> wrote:

> Hello Stephen and Jonathan,
> 
> sorry for the mess, I should have warned Jonathan about it.
> 
> The manual fix is obviously correct, no problem.
> 
> Thanks and sorry for the inconvenience,
> JB

This should be sorted today.
Given timing (and busy week as ever!) I decided I didn't have enough fixes
to do a separate pull and the merge window is close.  So I dragged
the fixes across to the branch targeting the merge window and dealt with
the merge there.  The togreg-fixes branch should no longer have
thse fixes on it.

Jonathan


> 
> 
> ________________________________________
> From: Stephen Rothwell
> Sent: Tuesday, April 30, 2024 07:15
> To: Jonathan Cameron
> Cc: Jean-Baptiste Maneyrol; Linux Kernel Mailing List; Linux Next Mailing List
> Subject: linux-next: manual merge of the iio tree with the iio-fixes tree
> 
> 
> Hi all,
> 
> 
> 
> Today's linux-next merge of the iio tree got a conflict in:
> 
> 
> 
>   drivers/iio/imu/inv_icm42600/inv_icm42600_buffer.c
> 
> 
> 
> between commit:
> 
> 
> 
>   d7230b995246 ("iio: invensense: fix timestamp glitches when switching frequency")
> 
> 
> 
> from the iio-fixes tree and commit:
> 
> 
> 
>   a1432b5b4f4c ("iio: imu: inv_icm42600: add support of ICM-42686-P")
> 
> 
> 
> from the iio tree.
> 
> 
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> 
> is now fixed as far as linux-next is concerned, but any non trivial
> 
> conflicts should be mentioned to your upstream maintainer when your tree
> 
> is submitted for merging.  You may also want to consider cooperating
> 
> with the maintainer of the conflicting tree to minimise any particularly
> 
> complex conflicts.
> 
> 
> 
> --
> 
> Cheers,
> 
> Stephen Rothwell
> 
> 
> 
> diff --cc drivers/iio/imu/inv_icm42600/inv_icm42600_buffer.c
> 
> index 9cde9a9337ad,cfb4a41ab7c1..000000000000
> 
> --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_buffer.c
> 
> +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_buffer.c
> 
> @@@ -509,20 -512,20 +512,20 @@@ int inv_icm42600_buffer_fifo_parse(stru
> 
>                  return 0;
> 
>  
> 
>          /* handle gyroscope timestamp and FIFO data parsing */
> 
>  -       ts = &gyro_st->ts;
> 
>  -       inv_sensors_timestamp_interrupt(ts, st->fifo.period, st->fifo.nb.total,
> 
>  -                                       st->fifo.nb.gyro, st->timestamp.gyro);
> 
>          if (st->fifo.nb.gyro > 0) {
> 
> -                ts = iio_priv(st->indio_gyro);
> 
> ++              ts = &gyro_st->ts;
> 
>  +               inv_sensors_timestamp_interrupt(ts, st->fifo.nb.gyro,
> 
>  +                                               st->timestamp.gyro);
> 
>                  ret = inv_icm42600_gyro_parse_fifo(st->indio_gyro);
> 
>                  if (ret)
> 
>                          return ret;
> 
>          }
> 
>  
> 
>          /* handle accelerometer timestamp and FIFO data parsing */
> 
>  -       ts = &accel_st->ts;
> 
>  -       inv_sensors_timestamp_interrupt(ts, st->fifo.period, st->fifo.nb.total,
> 
>  -                                       st->fifo.nb.accel, st->timestamp.accel);
> 
>          if (st->fifo.nb.accel > 0) {
> 
> -                ts = iio_priv(st->indio_accel);
> 
> ++              ts = &accel_st->ts;
> 
>  +               inv_sensors_timestamp_interrupt(ts, st->fifo.nb.accel,
> 
>  +                                               st->timestamp.accel);
> 
>                  ret = inv_icm42600_accel_parse_fifo(st->indio_accel);
> 
>                  if (ret)
> 
>                          return ret;
> 
> @@@ -549,16 -554,20 +554,16 @@@ int inv_icm42600_buffer_hwfifo_flush(st
> 
>                  return 0;
> 
>  
> 
>          if (st->fifo.nb.gyro > 0) {
> 
> -                ts = iio_priv(st->indio_gyro);
> 
> +                ts = &gyro_st->ts;
> 
>  -               inv_sensors_timestamp_interrupt(ts, st->fifo.period,
> 
>  -                                               st->fifo.nb.total, st->fifo.nb.gyro,
> 
>  -                                               gyro_ts);
> 
>  +               inv_sensors_timestamp_interrupt(ts, st->fifo.nb.gyro, gyro_ts);
> 
>                  ret = inv_icm42600_gyro_parse_fifo(st->indio_gyro);
> 
>                  if (ret)
> 
>                          return ret;
> 
>          }
> 
>  
> 
>          if (st->fifo.nb.accel > 0) {
> 
> -                ts = iio_priv(st->indio_accel);
> 
> +                ts = &accel_st->ts;
> 
>  -               inv_sensors_timestamp_interrupt(ts, st->fifo.period,
> 
>  -                                               st->fifo.nb.total, st->fifo.nb.accel,
> 
>  -                                               accel_ts);
> 
>  +               inv_sensors_timestamp_interrupt(ts, st->fifo.nb.accel, accel_ts);
> 
>                  ret = inv_icm42600_accel_parse_fifo(st->indio_accel);
> 
>                  if (ret)
> 
>                          return ret;
>