public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
	Eddie James <eajames@linux.ibm.com>, <lars@metafoo.de>,
	<linux-iio@vger.kernel.org>, <joel@jms.id.au>,
	<linux-kernel@vger.kernel.org>, <stable@vger.kernel.org>
Subject: Re: [PATCH v8 2/2] iio: pressure: dps310: Reset chip after timeout
Date: Sun, 18 Sep 2022 16:52:45 +0100	[thread overview]
Message-ID: <20220918165245.005c757a@jic23-huawei> (raw)
In-Reply-To: <20220916162535.00000cf6@huawei.com>

On Fri, 16 Sep 2022 16:25:35 +0100
Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:

> On Fri, 16 Sep 2022 08:51:13 +0300
> Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> 
> > On Thu, Sep 15, 2022 at 10:57 PM Eddie James <eajames@linux.ibm.com> wrote:  
> > >
> > > The DPS310 chip has been observed to get "stuck" such that pressure
> > > and temperature measurements are never indicated as "ready" in the
> > > MEAS_CFG register. The only solution is to reset the device and try
> > > again. In order to avoid continual failures, use a boolean flag to
> > > only try the reset after timeout once if errors persist.    
> > 
> > ...
> >   
> > > +static int dps310_ready(struct dps310_data *data, int ready_bit, int timeout)
> > > +{
> > > +       int rc;
> > > +
> > > +       rc = dps310_ready_status(data, ready_bit, timeout);
> > > +       if (rc) {    
> >   
> > > +               if (rc == -ETIMEDOUT && !data->timeout_recovery_failed) {    
> > 
> > Here you compare rc with a certain error code...
> >   
> > > +                       /* Reset and reinitialize the chip. */
> > > +                       if (dps310_reset_reinit(data)) {
> > > +                               data->timeout_recovery_failed = true;
> > > +                       } else {
> > > +                               /* Try again to get sensor ready status. */    
> >   
> > > +                               if (dps310_ready_status(data, ready_bit, timeout))    
> > 
> > ...but here you assume that the only error code is -ETIMEDOUT. It's
> > kinda inconsistent (if you rely on internals of ready_status, then why
> > to check the certain error code, or otherwise why not to return a real
> > second error code). That's why I asked about re-using rc here.  
> 
> Hmm.
> 
> 1st time around, any other error code would result in us just returning directly
> which is fine.
> 2nd time around I'm not sure we care about what the error code is.  Even if
> something else went wrong we failed to recover and the first error
> that lead to that was -ETIMEDOUT.
> 
> So I think this is correct as is, be it a little unusual!

Given timing late in the cycle, I've queued this up for the next merge
window rather than rushing it in.

Applied to the togreg branch of iio.git and pushed out as testing.
Note I plan to rebase that branch shortly as I need some stuff that
is in upstream for other series.  Hence still time for this discussion to
continue if anyone wants to!

Thanks,

Jonathan

> 
> Jonathan
> 
> > 
> > In any case I don't think this justifies a v9, let's wait for your
> > answer and Jonathan's opinion.
> >   
> > > +                                       data->timeout_recovery_failed = true;
> > > +                               else
> > > +                                       return 0;
> > > +                       }
> > > +               }
> > > +
> > > +               return rc;
> > > +       }
> > > +
> > > +       data->timeout_recovery_failed = false;
> > > +       return 0;
> > > +}    
> >   
> 


      reply	other threads:[~2022-09-18 15:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-15 19:57 [PATCH v8 0/2] iio: pressure: dps310: Reset chip if MEAS_CFG is corrupt Eddie James
2022-09-15 19:57 ` [PATCH v8 1/2] iio: pressure: dps310: Refactor startup procedure Eddie James
2022-09-15 19:57 ` [PATCH v8 2/2] iio: pressure: dps310: Reset chip after timeout Eddie James
2022-09-16  5:51   ` Andy Shevchenko
2022-09-16 15:25     ` Jonathan Cameron
2022-09-18 15:52       ` Jonathan Cameron [this message]

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=20220918165245.005c757a@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=eajames@linux.ibm.com \
    --cc=joel@jms.id.au \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@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