Linux IIO development
 help / color / mirror / Atom feed
From: Linmao Li <lilinmao@kylinos.cn>
To: Jonathan Cameron <jic23@kernel.org>
Cc: "Andy Shevchenko" <andriy.shevchenko@intel.com>,
	"Chris Morgan" <macromorgan@hotmail.com>,
	"David Lechner" <dlechner@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH togreg v3 1/2] iio: imu: inv_icm42607: propagate runtime suspend errors
Date: Mon, 24 Aug 2026 11:15:38 +0800	[thread overview]
Message-ID: <cfc66816-b8ca-4ed6-bf48-d4ab17249bb0@kylinos.cn> (raw)
In-Reply-To: <20260824012059.0a38fe2b@jic23-huawei>


在 2026/8/24 8:20, Jonathan Cameron 写道:
> On Mon, 17 Aug 2026 17:32:43 +0800
> Linmao Li <lilinmao@kylinos.cn> wrote:
>
>> 在 2026/8/16 4:52, Jonathan Cameron 写道:
>>> On Tue, 11 Aug 2026 18:33:00 +0800
>>> Linmao Li <lilinmao@kylinos.cn> wrote:
>>>   
>>>> The runtime suspend callback always returns success even when updating
>>>> PWR_MGMT0 fails. The PM core can then mark the device suspended while one
>>>> or both sensors remain enabled.
>>>>
>>>> The sibling ICM-42600 driver propagates the corresponding
>>>> inv_icm42600_set_pwr_mgmt0() failure from its runtime suspend callback.
>>>> Make ICM-42607 follow the same behavior by returning the sensor shutdown
>>>> error. Keep a void wrapper for the managed teardown action, where errors
>>>> can only be logged.
>>> What is the practical affect of a sensor remaining enabled?  Bit of
>>> power loss or something more significant?  This info matter when deciding
>>> if we should rush this in during the rc phase, or wait for the next
>>> merge window.
>> As far as I can tell, the practical effect is additional power
>> consumption while the device is idle.  I found no corruption path, but I
>> have no ICM-42607 hardware to reproduce the failure or measure the
>> current.
>>
>> It does not necessarily persist indefinitely.  If the PWR_MGMT0 write
>> fails, regmap may contain the requested OFF state while the hardware
>> remains ON.  A later sensor read requests an enabled mode, so
>> inv_icm42607_set_pwr_mgmt0() retries the write instead of taking its
>> "no change" return.  If the bus error was transient, the cache and
>> hardware are then resynchronized.
> Please capture some of that for the commit description for v2.
I need to correct one detail there.  For the I2C and SPI regmap paths
this driver uses, defer_caching is enabled, and _regmap_raw_write_impl()
drops the affected cache entry when the bus write fails.  So the failure
does not normally leave a cached OFF value.

The conclusion is unchanged, but the mechanism is different: a later
access misses in the cache, so regmap_read() reads PWR_MGMT0 from the
hardware again.  If the bus error was transient, the driver then sees
the actual state and can restore the requested mode if necessary.

I will use the corrected explanation in the next revision.  Sorry for
the confusion.


Thanks,
Linmao
>
>> I also noticed a cost to this patch: returning an error such as -EIO from
>> .runtime_suspend() makes the PM core set power.runtime_error. Subsequent
>> reads then fail in PM_RUNTIME_ACQUIRE_AUTOSUSPEND() before any sensor
>> register is accessed, until the PM status is reset.  A successful system
>> suspend may clear that state.
>>
>> The patch therefore trades a logged idle power leak that may recover on
>> a later access for a potentially sticky runtime-PM failure.  Since this
>> was found by inspection only, I would not rush it into the rc phase.  I
>> would rather revisit the error handling and target the next merge window.
>>
> That is fair enough.
>
> J
>> Linmao
>>
>>> Jonathan
>>>
>>>   
>>>> Fixes: 3007c1530f96 ("iio: imu: inv_icm42607: Add PM support for icm42607")
>>>> Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
>>>> ---
>>>> Unchanged since v1.
>>>>
>>>>    drivers/iio/imu/inv_icm42607/inv_icm42607_core.c | 15 ++++++++++-----
>>>>    1 file changed, 10 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
>>>> index 190e998f7b8ef..0da362967f63b 100644
>>>> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
>>>> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
>>>> @@ -537,9 +537,8 @@ static int inv_icm42607_enable_vddio_reg(struct inv_icm42607_state *st)
>>>>    	return 0;
>>>>    }
>>>>    
>>>> -static void inv_icm42607_sensors_off(void *_data)
>>>> +static int inv_icm42607_sensors_off(struct inv_icm42607_state *st)
>>>>    {
>>>> -	struct inv_icm42607_state *st = _data;
>>>>    	const struct device *dev = regmap_get_device(st->map);
>>>>    	int ret;
>>>>    
>>>> @@ -552,6 +551,13 @@ static void inv_icm42607_sensors_off(void *_data)
>>>>    					 st->conf.accel.mode);
>>>>    	if (ret)
>>>>    		dev_err(dev, "Unable to turn off sensors\n");
>>>> +
>>>> +	return ret;
>>>> +}
>>>> +
>>>> +static void inv_icm42607_sensors_off_action(void *data)
>>>> +{
>>>> +	inv_icm42607_sensors_off(data);
>>>>    }
>>>>    
>>>>    static void inv_icm42607_disable_vddio_reg(void *_data)
>>>> @@ -619,7 +625,7 @@ int inv_icm42607_core_probe(struct regmap *regmap,
>>>>    	 * Ensure if sensors get turned on at some point, they're turned off
>>>>    	 * as part of teardown.
>>>>    	 */
>>>> -	ret = devm_add_action_or_reset(dev, inv_icm42607_sensors_off, st);
>>>> +	ret = devm_add_action_or_reset(dev, inv_icm42607_sensors_off_action, st);
>>>>    	if (ret)
>>>>    		return ret;
>>>>    
>>>> @@ -688,8 +694,7 @@ static int inv_icm42607_runtime_suspend(struct device *dev)
>>>>    	 * however the tradeoff is that an unused sensor won't be
>>>>    	 * turned off until the entire chip is no longer in use.
>>>>    	 */
>>>> -	inv_icm42607_sensors_off(st);
>>>> -	return 0;
>>>> +	return inv_icm42607_sensors_off(st);
>>>>    }
>>>>    
>>>>    EXPORT_NS_GPL_DEV_PM_OPS(inv_icm42607_pm_ops, IIO_ICM42607) = {

  reply	other threads:[~2026-08-24  3:15 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-05  3:54 [PATCH togreg 0/2] iio: imu: inv_icm42607: fix PM error handling Linmao Li
2026-08-05  3:54 ` [PATCH togreg 1/2] iio: imu: inv_icm42607: propagate runtime suspend errors Linmao Li
2026-08-05  3:54 ` [PATCH togreg 2/2] iio: imu: inv_icm42607: restore runtime PM on system resume errors Linmao Li
2026-08-10 19:38   ` Andy Shevchenko
2026-08-11  2:03 ` [PATCH togreg v2 0/2] iio: imu: inv_icm42607: fix PM error handling Linmao Li
2026-08-11  2:03   ` [PATCH togreg v2 1/2] iio: imu: inv_icm42607: propagate runtime suspend errors Linmao Li
2026-08-11  2:03   ` [PATCH togreg v2 2/2] iio: imu: inv_icm42607: restore runtime PM on system resume errors Linmao Li
2026-08-11  8:54     ` Andy Shevchenko
2026-08-11 10:32       ` Linmao Li
2026-08-11  7:40   ` [PATCH togreg v2 0/2] iio: imu: inv_icm42607: fix PM error handling Andy Shevchenko
2026-08-11 10:32   ` [PATCH togreg v3 " Linmao Li
2026-08-11 10:33     ` [PATCH togreg v3 1/2] iio: imu: inv_icm42607: propagate runtime suspend errors Linmao Li
2026-08-15 20:52       ` Jonathan Cameron
2026-08-17  9:32         ` Linmao Li
2026-08-24  0:20           ` Jonathan Cameron
2026-08-24  3:15             ` Linmao Li [this message]
2026-08-11 10:33     ` [PATCH togreg v3 2/2] iio: imu: inv_icm42607: restore runtime PM on system resume errors Linmao Li
2026-08-15 20:58       ` Jonathan Cameron
2026-08-17  9:40         ` Linmao Li
2026-08-15 20:45   ` [PATCH togreg v2 0/2] iio: imu: inv_icm42607: fix PM error handling 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=cfc66816-b8ca-4ed6-bf48-d4ab17249bb0@kylinos.cn \
    --to=lilinmao@kylinos.cn \
    --cc=andriy.shevchenko@intel.com \
    --cc=andy@kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=jic23@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macromorgan@hotmail.com \
    --cc=nuno.sa@analog.com \
    /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