public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: David Lechner <dlechner@baylibre.com>
Cc: "Nechita, Ramona" <Ramona.Nechita@analog.com>,
	Lars-Peter Clausen <lars@metafoo.de>,
	"Tanislav, Cosmin" <Cosmin.Tanislav@analog.com>,
	"Hennerich, Michael" <Michael.Hennerich@analog.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	"Sa, Nuno" <Nuno.Sa@analog.com>,
	Andy Shevchenko <andy@kernel.org>,
	"Schmitt, Marcelo" <Marcelo.Schmitt@analog.com>,
	Olivier Moysan <olivier.moysan@foss.st.com>,
	Dumitru Ceclan <mitrutzceclan@gmail.com>,
	Matteo Martelli <matteomartelli3@gmail.com>,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	Alisa-Dariana Roman <alisadariana@gmail.com>,
	Ivan Mikhaylov <fr0st61te@gmail.com>,
	Mike Looijmans <mike.looijmans@topic.nl>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v5 3/3] drivers: iio: adc: add support for ad777x family
Date: Sat, 28 Sep 2024 15:29:28 +0100	[thread overview]
Message-ID: <20240928152928.38ee18b1@jic23-huawei> (raw)
In-Reply-To: <CAMknhBFyydCJeAazDYMkkH=rKU2DbJGy=Kpb0242Vn81MHn0mQ@mail.gmail.com>

On Mon, 23 Sep 2024 14:51:28 +0200
David Lechner <dlechner@baylibre.com> wrote:

> On Fri, Sep 20, 2024 at 3:24 PM Nechita, Ramona
> <Ramona.Nechita@analog.com> wrote:
> >
> > Hello all,
> >
> > Just a minor question
> > ...  
> > >  
> > >> +
> > >> +static irqreturn_t ad7779_trigger_handler(int irq, void *p) {
> > >> +    struct iio_poll_func *pf = p;
> > >> +    struct iio_dev *indio_dev = pf->indio_dev;
> > >> +    struct ad7779_state *st = iio_priv(indio_dev);
> > >> +    int ret;
> > >> +    int bit;
> > >> +    int k = 0;
> > >> +    /*
> > >> +     * Each channel shifts out HEADER + 24 bits of data therefore 8 * u32
> > >> +     * for the data and 64 bits for the timestamp
> > >> +     */
> > >> +    u32 tmp[10];
> > >> +
> > >> +    struct spi_transfer sd_readback_tr[] = {
> > >> +            {
> > >> +                    .rx_buf = st->spidata_rx,
> > >> +                    .tx_buf = st->spidata_tx,
> > >> +                    .len = AD7779_NUM_CHANNELS * AD7779_CHAN_DATA_SIZE,
> > >> +            }
> > >> +    };
> > >> +
> > >> +    if (!iio_buffer_enabled(indio_dev))
> > >> +            goto exit_handler;  
> > >
> > >If buffers aren't enabled, the push to buffers won't do anything. So this race shouldn't matter.  If it does, what happens?
> > >I'm curious because I'd expect any races that cause trouble in this case to be pretty universal across drivers.  
> >
> > I added that condition rather because the DRDY pulse will keep on being generated even when the buffers are not active,
> > and it would be better to exit the function sooner. I tested it and it does not break to remove the condition, I just
> > thought it made more sense like this. Should I delete it?
> >  
> > >....  
> >
> > Best regards,
> > Ramona Nechita
> >
> >  
> 
> Perhaps a better way to handle this would be to move
> 
>     disable_irq(st->spi->irq);
> 
> to the buffer predisable callback instead of doing it in the buffer
> postdisable callback. Then we will be sure to not get any more DRDY
> interrupts after the buffer is disabled.
> 
> (And to keep things balanced, moved the corresponding irq_enable() to
> the buffer postenable callback.)

That makes logical sense but in reality in the vast majority of cases
it makes no practical difference whether things are in the pre or
post callbacks as the fundamental races with tear down are there in
both cases but shouldn't matter as they correspond to slightly
earlier or later disabling of the buffer.  So this is a nice to
have for readabilty and understanding rather than a required change I think.

> 
> Since ad7779_trigger_handler is the IIO trigger interrupt handler and
> not the DRDY interrupt handler though, it is already not possible for
> this interrupt handler to be called while the IIO buffer is enabled.
> So it should be safe to remove the if
> (!iio_buffere_enabled(indio_dev)) even without the other changes I
> suggested.
Exactly.  

Jonathan



  reply	other threads:[~2024-09-28 14:29 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-12 12:15 [PATCH v5 0/3] add support for ad777x family Ramona Alexandra Nechita
2024-09-12 12:15 ` [PATCH v5 1/3] dt-bindings: iio: adc: add a7779 doc Ramona Alexandra Nechita
2024-09-12 13:15   ` Rob Herring (Arm)
2024-09-14 16:38   ` Jonathan Cameron
2024-09-12 12:15 ` [PATCH v5 2/3] Documentation: ABI: added filter mode doc in sysfs-bus-iio Ramona Alexandra Nechita
2024-09-12 14:47   ` Andy Shevchenko
2024-09-13 14:06     ` Nechita, Ramona
2024-09-13 17:36       ` Andy Shevchenko
2024-09-14 16:42         ` Jonathan Cameron
2024-09-13  4:16   ` kernel test robot
2024-09-14 16:43     ` Jonathan Cameron
2024-09-12 12:15 ` [PATCH v5 3/3] drivers: iio: adc: add support for ad777x family Ramona Alexandra Nechita
2024-09-12 15:15   ` Andy Shevchenko
2024-09-14 16:46     ` Jonathan Cameron
2024-09-14  1:44   ` kernel test robot
2024-09-14 16:48     ` Jonathan Cameron
2024-09-14 17:06   ` Jonathan Cameron
2024-09-20 13:24     ` Nechita, Ramona
2024-09-23 12:51       ` David Lechner
2024-09-28 14:29         ` Jonathan Cameron [this message]
2024-09-26 13:41     ` Nechita, Ramona
2024-09-28 14:31       ` Jonathan Cameron
2024-10-10 14:35         ` Nechita, Ramona
2024-10-10 16:40           ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240928152928.38ee18b1@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Cosmin.Tanislav@analog.com \
    --cc=Marcelo.Schmitt@analog.com \
    --cc=Michael.Hennerich@analog.com \
    --cc=Nuno.Sa@analog.com \
    --cc=Ramona.Nechita@analog.com \
    --cc=alisadariana@gmail.com \
    --cc=andy@kernel.org \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=fr0st61te@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matteomartelli3@gmail.com \
    --cc=mike.looijmans@topic.nl \
    --cc=mitrutzceclan@gmail.com \
    --cc=olivier.moysan@foss.st.com \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox