public inbox for linux-iio@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Alexandru Ardelean <ardeleanalex@gmail.com>
Cc: "Sa, Nuno" <Nuno.Sa@analog.com>,
	linux-iio <linux-iio@vger.kernel.org>,
	"Hennerich, Michael" <Michael.Hennerich@analog.com>,
	Lars-Peter Clausen <lars@metafoo.de>
Subject: Re: [PATCH v2 6/9] iio: adis_buffer: update device page after changing it
Date: Sat, 24 Apr 2021 12:31:11 +0100	[thread overview]
Message-ID: <20210424123111.4dc2b284@jic23-huawei> (raw)
In-Reply-To: <20210424121952.38f9c6ae@jic23-huawei>

On Sat, 24 Apr 2021 12:19:52 +0100
Jonathan Cameron <jic23@kernel.org> wrote:

> On Sat, 24 Apr 2021 12:18:06 +0100
> Jonathan Cameron <jic23@kernel.org> wrote:
> 
> > On Fri, 23 Apr 2021 16:56:26 +0300
> > Alexandru Ardelean <ardeleanalex@gmail.com> wrote:
> >   
> > > On Fri, Apr 23, 2021 at 3:20 PM Sa, Nuno <Nuno.Sa@analog.com> wrote:    
> > > >      
> > > > > From: Alexandru Ardelean <ardeleanalex@gmail.com>
> > > > > Sent: Friday, April 23, 2021 9:33 AM
> > > > > To: Sa, Nuno <Nuno.Sa@analog.com>
> > > > > Cc: linux-iio <linux-iio@vger.kernel.org>; Jonathan Cameron
> > > > > <jic23@kernel.org>; Hennerich, Michael
> > > > > <Michael.Hennerich@analog.com>; Lars-Peter Clausen
> > > > > <lars@metafoo.de>
> > > > > Subject: Re: [PATCH v2 6/9] iio: adis_buffer: update device page after
> > > > > changing it
> > > > >
> > > > > [External]
> > > > >
> > > > > On Thu, Apr 22, 2021 at 1:17 PM Nuno Sa <nuno.sa@analog.com>
> > > > > wrote:      
> > > > > >
> > > > > > With commit 58ca347b9b24 ("iio: adis_buffer: don't push data to      
> > > > > buffers on      
> > > > > > failure"), we return if 'spi_sync()' fails which would leave
> > > > > > 'adis->current_page' in an incoherent state. Hence, set this variable
> > > > > > right after we change the device page.
> > > > > >
> > > > > > Signed-off-by: Nuno Sa <nuno.sa@analog.com>
> > > > > > ---
> > > > > >  drivers/iio/imu/adis_buffer.c | 6 +++---
> > > > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/iio/imu/adis_buffer.c      
> > > > > b/drivers/iio/imu/adis_buffer.c      
> > > > > > index a29d22f657ce..dda367071980 100644
> > > > > > --- a/drivers/iio/imu/adis_buffer.c
> > > > > > +++ b/drivers/iio/imu/adis_buffer.c
> > > > > > @@ -140,6 +140,8 @@ static irqreturn_t adis_trigger_handler(int irq,      
> > > > > void *p)      
> > > > > >                                 mutex_unlock(&adis->state_lock);
> > > > > >                                 goto irq_done;
> > > > > >                         }
> > > > > > +
> > > > > > +                       adis->current_page = 0;
> > > > > >                 }
> > > > > >         }
> > > > > >
> > > > > > @@ -151,10 +153,8 @@ static irqreturn_t adis_trigger_handler(int      
> > > > > irq, void *p)      
> > > > > >                 goto irq_done;
> > > > > >         }
> > > > > >
> > > > > > -       if (adis->data->has_paging) {
> > > > > > -               adis->current_page = 0;
> > > > > > +       if (adis->data->has_paging)
> > > > > >                 mutex_unlock(&adis->state_lock);
> > > > > > -       }      
> > > > >
> > > > > So, continuing from my comment here [1]:
> > > > >
> > > > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/li
> > > > > nux-iio/patch/20210422101911.135630-6-
> > > > > nuno.sa@analog.com/__;!!A3Ni8CS0y2Y!u1RyPNeh8e5m7lPfDa5H5ZjT
> > > > > hA9TdsLGvk2m1kFQBbAKe40PmvQS8O8N-f-GEg$
> > > > >
> > > > > This can become more elegant, because this block:
> > > > >        if (adis->data->has_paging)
> > > > >                 mutex_unlock(&adis->state_lock);
> > > > >
> > > > > can be moved right after "ret = spi_sync(adis->spi, &adis->msg);"
> > > > >
> > > > > And then the duplication added in patch [1] can be cleaned up.
> > > > > So maybe a re-ordering of patches could simplify/remove the added
> > > > > duplication.
> > > > >      
> > > >
> > > > Hmmm I'm not following you :). What's your idea? You mean the block
> > > > inside the 'if (ret)' in case spi_sync fails? If so, we can move it but then
> > > > we cannot do the goto jump... you mean something like?
> > > >
> > > > ret = spi_sync();
> > > > if (adis->data->has_paging)
> > > >         mutex_unlock(&adis->state_lock);
> > > > if (ret) {
> > > >         dev_err();
> > > >         goto irq_done;
> > > > }
> > > >
> > > > I don't particularly like the paging stuff after the spi_sync but this avoids
> > > > some duplication for sure... and reduces some lines of code :)      
> > > 
> > > Yeah, this was the suggestion.
> > > No strong opinion about it.    
> > Ah. I should probably read ahead a bit before commenting on earlier patches ;)
> > 
> > I was thinking this was the way to go.  It would be an entirely standard pattern 
> > if not for the if (adis->data->has_paging) being there.
> > 
> > Hmm maybe some helpers would make this more readable?  
> > 
> > adis_mutex_lock_if_paging(adis);
> > adis_mutex_unlock_if_paging(adis);
> > 
> > Probably not worth it given single usecase.  I'd go with what you have above.  
> Ah realised this was unclear just after hitting send.   I mean the 
> 
> > > > ret = spi_sync();
> > > > if (adis->data->has_paging)
> > > >         mutex_unlock(&adis->state_lock);
> > > > if (ret) {
> > > >         dev_err();
> > > >         goto irq_done;
> > > > }  
> 
> approach.

As I love replying to myself ;)

From the other adis patch, I noticed that we have adis_dev_lock()

Probably good to have a follow up patch that tidies the drivers up to use
that where appropriate.  Good not to do it in these patches though as that
would just make them locally harder to read.

Thanks,

Jonathan

> 
> > I'd also reorder this before the previous patch as that will make that one simpler.
> > 
> > Jonathan
> >   
> > >     
> > > >
> > > > - Nuno Sá      
> >   
> 


  reply	other threads:[~2021-04-24 11:30 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-22 10:19 [PATCH v2 0/9] Adis IRQ fixes and minor improvements Nuno Sa
2021-04-22 10:19 ` [PATCH v2 1/9] iio: adis_buffer: do not return ints in irq handlers Nuno Sa
2021-04-24 10:59   ` Jonathan Cameron
2021-04-22 10:19 ` [PATCH v2 2/9] iio: adis16400: " Nuno Sa
2021-04-24 11:00   ` Jonathan Cameron
2021-04-22 10:19 ` [PATCH v2 3/9] iio: adis16475: " Nuno Sa
2021-04-23  6:41   ` Alexandru Ardelean
2021-04-24 11:06     ` Jonathan Cameron
2021-04-26  9:45       ` Sa, Nuno
2021-04-22 10:19 ` [PATCH v2 4/9] iio: adis_buffer: check return value on page change Nuno Sa
2021-04-23  7:14   ` Alexandru Ardelean
2021-04-24 11:07     ` Jonathan Cameron
2021-04-22 10:19 ` [PATCH v2 5/9] iio: adis_buffer: don't push data to buffers on failure Nuno Sa
2021-04-23  7:28   ` Alexandru Ardelean
2021-04-24 11:13     ` Jonathan Cameron
2021-04-22 10:19 ` [PATCH v2 6/9] iio: adis_buffer: update device page after changing it Nuno Sa
2021-04-23  7:32   ` Alexandru Ardelean
2021-04-23 12:20     ` Sa, Nuno
2021-04-23 13:56       ` Alexandru Ardelean
2021-04-24 11:18         ` Jonathan Cameron
2021-04-24 11:19           ` Jonathan Cameron
2021-04-24 11:31             ` Jonathan Cameron [this message]
2021-04-26  9:54               ` Sa, Nuno
2021-04-26  9:46           ` Sa, Nuno
2021-04-22 10:19 ` [PATCH v2 7/9] iio: adis: add burst_max_speed_hz variable Nuno Sa
2021-04-23  7:34   ` Alexandru Ardelean
2021-04-24 11:26     ` Jonathan Cameron
2021-04-22 10:19 ` [PATCH v2 8/9] iio: adis16475: do not directly change spi 'max_speed_hz' Nuno Sa
2021-04-23  7:36   ` Alexandru Ardelean
2021-04-22 10:19 ` [PATCH v2 9/9] iio: adis16400: " Nuno Sa
2021-04-23  7:37   ` Alexandru Ardelean

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=20210424123111.4dc2b284@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Michael.Hennerich@analog.com \
    --cc=Nuno.Sa@analog.com \
    --cc=ardeleanalex@gmail.com \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.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