Re: [PATCH v1 0/2] iio: core: remove iio_validate_own_trigger() function

[Vasileios Amoiridis <vassilisamir@gmail.com>]

On Sat, Sep 21, 2024 at 12:23:39PM -0700, Lars-Peter Clausen wrote:
> On 9/21/24 11:19, Vasileios Amoiridis wrote:
> > The iio_validate_own_trigger() function was added in this commit [1] but it is
> > the same with the below function called iio_trigger_validate_own_device(). The
> > bodies of the functions can be found in [2], [3].
> > 
> > [1]: https://lore.kernel.org/all/51cd3e3e74a6addf8d333f4a109fb9c5a11086ee.1683541225.git.mazziesaccount@gmail.com/
> > [2]: https://elixir.bootlin.com/linux/v6.11/source/drivers/iio/industrialio-trigger.c#L732
> > [3]: https://elixir.bootlin.com/linux/v6.11/source/drivers/iio/industrialio-trigger.c#L752
> 
> The signature of the two functions are different, the order of the
> parameters is switched. So you can't just swap them out for the
> `validate_trigger` callback since the signature is not compatible. But maybe
> you can update the implementation of one of the functions to calling the
> other function.
> 

Hi Lars,

Hmm, I see what you mean. Still though, do you think that we could do some
cleaning here? I can see 3 approaches:

1) One of the 2 functions calls the other internally and nothing else has
to change.

1) The default iio_validate_own_trigger() is used only by 2 out of many drivers
who use the .validate_trigger call. If this is deprecated, many function
signatures will need to change (swap the args) and then rename the rest.

The default iio_trigger_validate_own_device() is used in almost all of the
drivers apart from 3 
	* gyro/st_gyro_core.c
	* common/st_sensors/st_sensors_trigger.c
	* trigger/stm32-lptimer-trigger.c

So it will be less noise to change the iio_trigger_validate_own_device()
in the sense that the signature of 3 functions will need to change
(swap args) and then rename the rest.

1 is by far the less noisy as only a couple lines need to change but we
still endup with 2 functions doing the same thing. 2 and 3 require more
noise but we end up having 1 implementation which looks cleaner.

What would you say?

Cheers,
Vasilis