While looking around the code, I noticed that there are a lot of places
were we are manually filling all of the fields of an IIO timestamp.

This is error-prone (as seen in the first patch) and more verbose than
it needs to be.

I went with the approach of using the existing IIO_CHAN_SOFT_TIMESTAMP()
macro for doing a struct assignment. This does require a cast, which
makes it a bit more verbose, but we were already doing that in to
drivers, so I went with it anyway.

If we want to consider alternatives, we could make a iio helper function
or macro like the first and second patches did.

Signed-off-by: David Lechner <dlechner@baylibre.com>
---
David Lechner (8):
      iio: common: scmi_sensors: simplify timestamp channel definition
      iio: adc: dln2-adc: simplify timestamp channel definition
      iio: adc: at91_adc: simplify timestamp channel definition
      iio: adc: cc10001_adc: simplify timestamp channel definition
      iio: adc: stm32-adc: simplify timestamp channel definition
      iio: common: cros_ec_sensors: simplify timestamp channel definition
      iio: light: cros_ec_light_prox: simplify timestamp channel definition
      iio: pressure: cros_ec_baro: simplify timestamp channel definition

 drivers/iio/adc/at91_adc.c                            | 12 +++---------
 drivers/iio/adc/cc10001_adc.c                         | 10 ++--------
 drivers/iio/adc/dln2-adc.c                            | 12 +-----------
 drivers/iio/adc/stm32-adc.c                           | 10 ++--------
 drivers/iio/common/cros_ec_sensors/cros_ec_activity.c |  8 +-------
 drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c  |  8 +-------
 drivers/iio/common/scmi_sensors/scmi_iio.c            | 13 +------------
 drivers/iio/light/cros_ec_light_prox.c                |  8 +-------
 drivers/iio/pressure/cros_ec_baro.c                   |  8 +-------
 9 files changed, 13 insertions(+), 76 deletions(-)
---
base-commit: 8678fb54958893818ddeccd05fea560a4e1fc759
change-id: 20260517-iio-timestamp-cleanup-1ee82f081a70

Best regards,
--  
David Lechner <dlechner@baylibre.com>

On Sun, May 17, 2026 at 01:17:17PM -0500, David Lechner wrote:
> While looking around the code, I noticed that there are a lot of places
> were we are manually filling all of the fields of an IIO timestamp.
> 
> This is error-prone (as seen in the first patch) and more verbose than
> it needs to be.
> 
> I went with the approach of using the existing IIO_CHAN_SOFT_TIMESTAMP()
> macro for doing a struct assignment. This does require a cast, which
> makes it a bit more verbose, but we were already doing that in to
> drivers, so I went with it anyway.
> 
> If we want to consider alternatives, we could make a iio helper function
> or macro like the first and second patches did.

I like the series, just incorporate my patch, test and issue a v2, I will give
my tag.

-- 
With Best Regards,
Andy Shevchenko

On Sun, May 17, 2026 at 01:17:17PM -0500, David Lechner wrote:
> While looking around the code, I noticed that there are a lot of places
> were we are manually filling all of the fields of an IIO timestamp.
> 
> This is error-prone (as seen in the first patch) and more verbose than
> it needs to be.
> 
> I went with the approach of using the existing IIO_CHAN_SOFT_TIMESTAMP()
> macro for doing a struct assignment. This does require a cast, which

No, it's *not* a cast. It's a compound literal. And instead of doing this in
every driver, add it to the macro (in a separate patch). Oh, let me just cook
it for you (I added that to several cases in the past).

> makes it a bit more verbose, but we were already doing that in to
> drivers, so I went with it anyway.

> If we want to consider alternatives, we could make a iio helper function
> or macro like the first and second patches did.

-- 
With Best Regards,
Andy Shevchenko

On Mon, May 18, 2026 at 10:09:48AM +0300, Andy Shevchenko wrote:
> On Sun, May 17, 2026 at 01:17:17PM -0500, David Lechner wrote:
> > While looking around the code, I noticed that there are a lot of places
> > were we are manually filling all of the fields of an IIO timestamp.
> > 
> > This is error-prone (as seen in the first patch) and more verbose than
> > it needs to be.
> > 
> > I went with the approach of using the existing IIO_CHAN_SOFT_TIMESTAMP()
> > macro for doing a struct assignment. This does require a cast, which
> 
> No, it's *not* a cast. It's a compound literal. And instead of doing this in
> every driver, add it to the macro (in a separate patch). Oh, let me just cook
> it for you (I added that to several cases in the past).

20260518071349.469748-1-andriy.shevchenko@linux.intel.com

> > makes it a bit more verbose, but we were already doing that in to
> > drivers, so I went with it anyway.
> 
> > If we want to consider alternatives, we could make a iio helper function
> > or macro like the first and second patches did.

-- 
With Best Regards,
Andy Shevchenko

On 5/18/26 2:14 AM, Andy Shevchenko wrote:
> On Mon, May 18, 2026 at 10:09:48AM +0300, Andy Shevchenko wrote:
>> On Sun, May 17, 2026 at 01:17:17PM -0500, David Lechner wrote:
>>> While looking around the code, I noticed that there are a lot of places
>>> were we are manually filling all of the fields of an IIO timestamp.
>>>
>>> This is error-prone (as seen in the first patch) and more verbose than
>>> it needs to be.
>>>
>>> I went with the approach of using the existing IIO_CHAN_SOFT_TIMESTAMP()
>>> macro for doing a struct assignment. This does require a cast, which
>>
>> No, it's *not* a cast. It's a compound literal. And instead of doing this in
>> every driver, add it to the macro (in a separate patch). Oh, let me just cook
>> it for you (I added that to several cases in the past).
> 
> 20260518071349.469748-1-andriy.shevchenko@linux.intel.com

Nice, thanks. I agree this will be the cleanest solution.

> 
>>> makes it a bit more verbose, but we were already doing that in to
>>> drivers, so I went with it anyway.
>>
>>> If we want to consider alternatives, we could make a iio helper function
>>> or macro like the first and second patches did.
>

On Mon, 18 May 2026 09:34:48 -0500
David Lechner <dlechner@baylibre.com> wrote:

> On 5/18/26 2:14 AM, Andy Shevchenko wrote:
> > On Mon, May 18, 2026 at 10:09:48AM +0300, Andy Shevchenko wrote:  
> >> On Sun, May 17, 2026 at 01:17:17PM -0500, David Lechner wrote:  
> >>> While looking around the code, I noticed that there are a lot of places
> >>> were we are manually filling all of the fields of an IIO timestamp.
> >>>
> >>> This is error-prone (as seen in the first patch) and more verbose than
> >>> it needs to be.
> >>>
> >>> I went with the approach of using the existing IIO_CHAN_SOFT_TIMESTAMP()
> >>> macro for doing a struct assignment. This does require a cast, which  
> >>
> >> No, it's *not* a cast. It's a compound literal. And instead of doing this in
> >> every driver, add it to the macro (in a separate patch). Oh, let me just cook
> >> it for you (I added that to several cases in the past).  
> > 
> > 20260518071349.469748-1-andriy.shevchenko@linux.intel.com  
> 
> Nice, thanks. I agree this will be the cleanest solution.
With that the series looks good to me.

J
> 
> >   
> >>> makes it a bit more verbose, but we were already doing that in to
> >>> drivers, so I went with it anyway.  
> >>  
> >>> If we want to consider alternatives, we could make a iio helper function
> >>> or macro like the first and second patches did.  
> >   
>

On 5/17/26 1:17 PM, David Lechner wrote:
> While looking around the code, I noticed that there are a lot of places
> were we are manually filling all of the fields of an IIO timestamp.
> 
> This is error-prone (as seen in the first patch) and more verbose than
> it needs to be.
> 
> I went with the approach of using the existing IIO_CHAN_SOFT_TIMESTAMP()
> macro for doing a struct assignment. This does require a cast, which
> makes it a bit more verbose, but we were already doing that in to
> drivers, so I went with it anyway.
> 
> If we want to consider alternatives, we could make a iio helper function
> or macro like the first and second patches did.
> 
I should have looked harder for existing alternatives. Just found one
more that avoids the cast via a local variable (in ad4170-4.c):

	/* Add timestamp channel */
	struct iio_chan_spec ts_chan = IIO_CHAN_SOFT_TIMESTAMP(chan_num);

	st->chans[chan_num] = ts_chan;

And similar code is found in ad7192.c.

On Sun, May 17, 2026 at 02:22:03PM -0500, David Lechner wrote:
> On 5/17/26 1:17 PM, David Lechner wrote:
> > While looking around the code, I noticed that there are a lot of places
> > were we are manually filling all of the fields of an IIO timestamp.
> > 
> > This is error-prone (as seen in the first patch) and more verbose than
> > it needs to be.
> > 
> > I went with the approach of using the existing IIO_CHAN_SOFT_TIMESTAMP()
> > macro for doing a struct assignment. This does require a cast, which
> > makes it a bit more verbose, but we were already doing that in to
> > drivers, so I went with it anyway.
> > 
> > If we want to consider alternatives, we could make a iio helper function
> > or macro like the first and second patches did.
> > 
> I should have looked harder for existing alternatives. Just found one
> more that avoids the cast via a local variable (in ad4170-4.c):
> 
> 	/* Add timestamp channel */
> 	struct iio_chan_spec ts_chan = IIO_CHAN_SOFT_TIMESTAMP(chan_num);
> 
> 	st->chans[chan_num] = ts_chan;
> 
> And similar code is found in ad7192.c.

See my patch. The above with my patch applied can be simplified to the
inline use.

-- 
With Best Regards,
Andy Shevchenko