Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Eddie James <eajames@linux.ibm.com>
To:     jic23@kernel.org
Cc:     lars@metafoo.de, linux-iio@vger.kernel.org, joel@jms.id.au,
        linux-kernel@vger.kernel.org, andy.shevchenko@gmail.com,
        stable@vger.kernel.org, eajames@linux.ibm.com
Subject: [PATCH v7 0/2] iio: pressure: dps310: Reset chip if MEAS_CFG is corrupt
Date:   Mon, 12 Sep 2022 16:27:41 -0500
Message-Id: <20220912212743.37365-1-eajames@linux.ibm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

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. Include a
patch to move the startup procedure into a function.

Changes since v6:
 - Use helper instead of the lengthy regmap_read_poll_timeout twice
 - Just return dps310_startup in dps310_reset_reinit

Changes since v5:
 - Completely rework the second patch to reset and reinit in any
   timeout condition, if there haven't been previous timeouts that
   failed to recover the chip.

Changes since v4:
 - Just check for rc rather than rc < 0 in some cases
 - Split declaration and init of rc

Changes since v3:
 - Don't check regmap* return codes for < 0
 - Fix comment spelling

Changes since v2:
 - Add some comments
 - Fix the clunky control flow

Changes since v1:
 - Separate into two patches
 - Rename 'dps310_verify_meas_cfg' to 'dps310_check_reset_meas_cfg'

Eddie James (2):
  iio: pressure: dps310: Refactor startup procedure
  iio: pressure: dps310: Reset chip after timeout

 drivers/iio/pressure/dps310.c | 266 +++++++++++++++++++++-------------
 1 file changed, 167 insertions(+), 99 deletions(-)

-- 
2.31.1