linux-kernel - Re: [PATCH v4 14/16] iio: adc: max1027: Use the EOC IRQ when populated for single reads

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20210927163004.54f1a824@xps13>
Date:   Mon, 27 Sep 2021 16:30:04 +0200
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Jonathan Cameron <jic23@...nel.org>
Cc:     Lars-Peter Clausen <lars@...afoo.de>, linux-iio@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Nuno Sa <Nuno.Sa@...log.com>
Subject: Re: [PATCH v4 14/16] iio: adc: max1027: Use the EOC IRQ when
 populated for single reads

Hi Jonathan,

jic23@...nel.org wrote on Sun, 26 Sep 2021 15:36:59 +0100:

> On Tue, 21 Sep 2021 13:54:06 +0200
> Miquel Raynal <miquel.raynal@...tlin.com> wrote:
> 
> > So far the End-Of-Conversion interrupt was only used in conjunction with
> > the internal trigger to process the data. Let's extend the use of this
> > interrupt handler to support regular single-shot conversions as well.
> > 
> > Doing so requires writing our own hard IRQ handler. This handler has to
> > check if buffers are enabled or not:
> > 
> > *** Buffers disabled condition ***
> > 
> >   This means the user requested a single conversion and the sample is
> >   ready to be retrieved.
> >   
> >     -> This implies adding the relevant completion boilerplate.    
> > 
> > *** Buffers enabled condition ***
> > 
> >   Triggers are used. So far there is only support for the internal
> >   trigger but this trigger might soon be attached to another device as
> >   well so it is the core duty to decide which handler to call in order
> >   to process the data. The core will decide to either:
> > 
> >   * Call the internal trigger handler which will extract the data that
> >     is already present in the ADC FIFOs
> > 
> >   or
> > 
> >   * Call the trigger handler of another driver when using this trigger
> >     with another device, even though this call will be slightly delayed
> >     by the fact that the max1027 IRQ is a data-ready interrupt rather
> >     than a real trigger:
> >   
> >   -> The new handler will manually inform the core about the trigger    
> >      having transitioned by directly calling iio_trigger_poll() (which
> >      iio_trigger_generic_data_rdy_poll() initially did).
> > 
> > In order for the handler to be "source" agnostic, we also need to change
> > the private pointer and provide the IIO device instead of the trigger
> > object.
> > 
> > Signed-off-by: Miquel Raynal <miquel.raynal@...tlin.com>
> > ---
> > 
> > Jonathan,
> > 
> > I hope this fits the IIO model now. In order to be sure I got the big
> > picture I first refused to look at your code snippets. Just with your
> > "plain english" explanations I wrote most of these three patches, before
> > checking back that they were indeed fully aligned with your examples. I
> > truly hope they do now, but do not hesitate if I missed something.  
> 
> Looks great to me (in fact I just applied it but I'll reply to the cover letter
> shortly for that).

Great, thanks!

> Thanks for persisting with this and I'm looking forward to that blog you
> mentioned.

Thank you for all the time you put in these reviews.

I wrote most of it, it's not very long but I tried to cover most of the
common interactions with the core. It is under internal review, I'll
certainly show you its content before publishing in case you have
comments or spot any mistake.

>  If you have time / inclination to help improve the documentation
> in the kernel tree that would also be great.  This discussion has made it
> clear to me that it would be great to have a set of 'patterns' for common
> types of device + how we map them onto the model of IIO (particularly
> when they don't quite fit that idealised model).  There are similar
> compromises around when to use multiple buffers for instance.
> 
> It is always on the list of things to work on but somehow there is always
> something else more urgent :(

Hehe :) I know, documentation is always a good-to-have item that is not
often reached... I feel I need more occasions to work in the IIO
area (for example with hardware fifos/buffers or events) before being
able to fully appreciate the internal design, but I agree having a set
of 'usual patterns' that drivers should conform with depending on the
devices capabilities/constraints would be a must.

In the mean time, let's start by clarifying this 'iio_dev->modes'
property :)

Thanks,
Miquèl