linux-kernel - Re: [PATCH 16/16] iio: adc: max1027: Enable software triggers to be used without IRQ

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: <20210830115425.3fdb31b9@jic23-huawei>
Date:   Mon, 30 Aug 2021 11:54:25 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Miquel Raynal <miquel.raynal@...tlin.com>
Cc:     Lars-Peter Clausen <lars@...afoo.de>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        linux-iio@...r.kernel.org, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 16/16] iio: adc: max1027: Enable software triggers to be
 used without IRQ

On Wed, 18 Aug 2021 13:11:39 +0200
Miquel Raynal <miquel.raynal@...tlin.com> wrote:

> Software triggers do not need a device IRQ to work. As opposed to
> hardware triggers which need it to yield the data to the IIO core,
> software triggers run a dedicated thread which does all the tasks on
> their behalf. Then, the end of conversion status may either come from an
> interrupt or from a sufficient enough extra delay. IRQs are not
> mandatory so move the triggered buffer setup out of the IRQ condition.

I'd stop referring to software triggers in these descriptions.  This
could just as easily be about enabling a different hardware trigger
such as a gpio trigger or indeed on a dataready trigger provided by
an entirely different device.

Otherwise the logic is correct.

Good to get this more flexible support into the driver.  If we can
make it a tiny bit more flexible by enabling use of the cnvst trigger
to drive this 'and' other drivers that would be even better and
conform more closely to the normal way an IIO driver work.

The validate_device / validate_trigger callbacks are often about
making it easier to bring a device driver up in the first place, so
it's great to see them go away in later improvements like this.
(note I'm not saying there aren't complex cases where we can't remove
them though!)

Jonathan


> 
> Signed-off-by: Miquel Raynal <miquel.raynal@...tlin.com>
> ---
>  drivers/iio/adc/max1027.c | 20 +++++++++++---------
>  1 file changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/iio/adc/max1027.c b/drivers/iio/adc/max1027.c
> index bb437e43adaf..e767437a578e 100644
> --- a/drivers/iio/adc/max1027.c
> +++ b/drivers/iio/adc/max1027.c
> @@ -567,16 +567,18 @@ static int max1027_probe(struct spi_device *spi)
>  	if (!st->buffer)
>  		return -ENOMEM;
>  
> +	/* Enable triggered buffers */
> +	ret = devm_iio_triggered_buffer_setup(&spi->dev, indio_dev,
> +					      &iio_pollfunc_store_time,
> +					      &max1027_trigger_handler,
> +					      NULL);
> +	if (ret < 0) {
> +		dev_err(&indio_dev->dev, "Failed to setup buffer\n");
> +		return ret;
> +	}
> +
> +	/* If there is an EOC interrupt, enable the hardware trigger (cnvst) */
>  	if (spi->irq) {
> -		ret = devm_iio_triggered_buffer_setup(&spi->dev, indio_dev,
> -						      &iio_pollfunc_store_time,
> -						      &max1027_trigger_handler,
> -						      NULL);
> -		if (ret < 0) {
> -			dev_err(&indio_dev->dev, "Failed to setup buffer\n");
> -			return ret;
> -		}
> -
>  		st->trig = devm_iio_trigger_alloc(&spi->dev, "%s-trigger",
>  						  indio_dev->name);
>  		if (st->trig == NULL) {