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

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]

Hi all,

Today's linux-next merge of the iio tree got a conflict in:

  drivers/iio/adc/aspeed_adc.c

between commit:

  eb795cd97365 ("iio: adc: aspeed: set driver data when adc probe.")

from the iio-fixes tree and commit:

  e96b152c6cc2 ("iio: adc: aspeed: Keep model data to driver data.")

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/adc/aspeed_adc.c
index 34ec0c28b2df,9e2c85c3cbe9..000000000000
--- a/drivers/iio/adc/aspeed_adc.c
+++ b/drivers/iio/adc/aspeed_adc.c
@@@ -183,7 -492,7 +492,8 @@@ static int aspeed_adc_probe(struct plat
  
  	data = iio_priv(indio_dev);
  	data->dev = &pdev->dev;
 +	platform_set_drvdata(pdev, indio_dev);
+ 	data->model_data = of_device_get_match_data(&pdev->dev);
  
  	data->base = devm_platform_ioremap_resource(pdev, 0);
  	if (IS_ERR(data->base))

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Jonathan Cameron]

On Fri, 1 Oct 2021 13:38:41 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the iio tree got a conflict in:
> 
>   drivers/iio/adc/aspeed_adc.c
> 
> between commit:
> 
>   eb795cd97365 ("iio: adc: aspeed: set driver data when adc probe.")
> 
> from the iio-fixes tree and commit:
> 
>   e96b152c6cc2 ("iio: adc: aspeed: Keep model data to driver data.")
> 
> 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.
> 

Thanks.

Looks good to me.

Jonathan

> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/iio/adc/aspeed_adc.c
> index 34ec0c28b2df,9e2c85c3cbe9..000000000000
> --- a/drivers/iio/adc/aspeed_adc.c
> +++ b/drivers/iio/adc/aspeed_adc.c
> @@@ -183,7 -492,7 +492,8 @@@ static int aspeed_adc_probe(struct plat
>   
>   	data = iio_priv(indio_dev);
>   	data->dev = &pdev->dev;
>  +	platform_set_drvdata(pdev, indio_dev);
> + 	data->model_data = of_device_get_match_data(&pdev->dev);
>   
>   	data->base = devm_platform_ioremap_resource(pdev, 0);
>   	if (IS_ERR(data->base))

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2929 bytes --]

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;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Jean-Baptiste Maneyrol]

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


________________________________________
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;

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

[Jonathan Cameron]

 

On Thu, 2 May 2024 08:36:21 +0000
Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@tdk.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;
> 

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

Hi all,

Today's linux-next merge of the iio tree got a conflict in:

  drivers/iio/pressure/bmp280-core.c

between commit:

  0f0f6306617c ("iio: pressure: bmp280: Fix BMP580 temperature reading")

from the iio-fixes tree and commit:

  d58479ff81c0 ("iio: pressure: bmp280: Generalize read_{temp,press,humid}() functions")

from the iio tree.

I fixed it up (I just used the latter) 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2232 bytes --]

Hi all,

Today's linux-next merge of the iio tree got a conflict in:

  drivers/iio/adc/Kconfig

between commit:

  169eaf9ccfb0 ("iio: adc: ti-ads1298: Kconfig: add kfifo dependency to fix module build")

from the iio-fixes tree and commit:

  0de3748d80f3 ("iio: adc: sort TI drivers alphanumerical")

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/adc/Kconfig
index b7aac84e5224,ad06cf556785..000000000000
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@@ -1512,6 -1546,41 +1547,42 @@@ config TI_ADS111
           This driver can also be built as a module. If so, the module will be
           called ti-ads1119.
  
+ config TI_ADS124S08
+ 	tristate "Texas Instruments ADS124S08"
+ 	depends on SPI
+ 	select IIO_BUFFER
+ 	select IIO_TRIGGERED_BUFFER
+ 	help
+ 	  If you say yes here you get support for Texas Instruments ADS124S08
+ 	  and ADS124S06 ADC chips
+ 
+ 	  This driver can also be built as a module. If so, the module will be
+ 	  called ti-ads124s08.
+ 
+ config TI_ADS1298
+ 	tristate "Texas Instruments ADS1298"
+ 	depends on SPI
+ 	select IIO_BUFFER
++	select IIO_KFIFO_BUF
+ 	help
+ 	  If you say yes here you get support for Texas Instruments ADS1298
+ 	  medical ADC chips
+ 
+ 	  This driver can also be built as a module. If so, the module will be
+ 	  called ti-ads1298.
+ 
+ config TI_ADS131E08
+ 	tristate "Texas Instruments ADS131E08"
+ 	depends on SPI
+ 	select IIO_BUFFER
+ 	select IIO_TRIGGERED_BUFFER
+ 	help
+ 	  Say yes here to get support for Texas Instruments ADS131E04, ADS131E06
+ 	  and ADS131E08 chips.
+ 
+ 	  This driver can also be built as a module. If so, the module will be
+ 	  called ti-ads131e08.
+ 
  config TI_ADS7138
  	tristate "Texas Instruments ADS7128 and ADS7138 ADC driver"
  	depends on I2C

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]

Hi all,

Today's linux-next merge of the iio tree got a conflict in:

  drivers/iio/adc/ad7606.c

between commit:

  3f5fd1717ae9 ("iio: adc: ad7606: fix raw read for 18-bit chips")

from the iio-fixes tree and commit:

  3b5b55ca9407 ("iio: adc: ad7606: dynamically allocate channel info")

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/adc/ad7606.c
index 8ed65a35b486,aa96247d6757..000000000000
--- a/drivers/iio/adc/ad7606.c
+++ b/drivers/iio/adc/ad7606.c
@@@ -726,17 -657,20 +657,18 @@@ static int ad7606_scan_direct(struct ii
  	if (ret)
  		goto error_ret;
  
- 	chan = &indio_dev->channels[ch + 1];
+ 	chan = &indio_dev->channels[ch];
+ 	realbits = chan->scan_type.realbits;
  
 -	if (chan->scan_type.sign == 'u') {
 -		if (realbits > 16)
 -			*val = st->data.buf32[ch];
 -		else
 -			*val = st->data.buf16[ch];
 -	} else {
 -		if (realbits > 16)
 -			*val = sign_extend32(st->data.buf32[ch], realbits - 1);
 -		else
 -			*val = sign_extend32(st->data.buf16[ch], realbits - 1);
 -	}
 +	if (realbits > 16)
 +		*val = st->data.buf32[ch];
 +	else
 +		*val = st->data.buf16[ch];
 +
 +	*val &= GENMASK(realbits - 1, 0);
 +
 +	if (chan->scan_type.sign == 's')
 +		*val = sign_extend32(*val, realbits - 1);
  
  error_ret:
  	if (!st->gpio_convst) {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]