.../iio/imu/inv_icm42607/inv_icm42607_core.c | 38 ++++++++++++++----- 1 file changed, 29 insertions(+), 9 deletions(-)
The recently queued ICM-42607 PM support has two error paths that can leave the PM core's state inconsistent with the device. Patch 1 propagates sensor shutdown failures from runtime suspend. Patch 2 ensures that system resume restores runtime PM management on both of its error paths, so that a failed resume does not leave runtime PM disabled for good. Changes since v3: - Patch 1: commit message expanded with the practical effect of the current behaviour, the cost of propagating the error, and a description of the recovery path that does not assume a particular regmap bus implementation. No code change. - Patch 2: unchanged. Neither patch was reproduced on hardware; both were found by code inspection. They were compile-tested with W=1 and checked with smatch. Whether patch 1 is worth making is still a fair question - it trades a possible idle power leak that may be cleared by a later successful access for a runtime PM error state that needs an explicit reset. The commit message spells that out; happy to drop it if you would rather not take that trade. Linmao Li (2): iio: imu: inv_icm42607: propagate runtime suspend errors iio: imu: inv_icm42607: restore runtime PM on system resume errors .../iio/imu/inv_icm42607/inv_icm42607_core.c | 38 ++++++++++++++----- 1 file changed, 29 insertions(+), 9 deletions(-) base-commit: 350d1fb9204b13c5f95e511e98b8bcb47574d425 -- 2.25.1
> The recently queued ICM-42607 PM support has two error paths that can leave > the PM core's state inconsistent with the device. > > Patch 1 propagates sensor shutdown failures from runtime suspend. Patch 2 > ensures that system resume restores runtime PM management on both of its > error paths, so that a failed resume does not leave runtime PM disabled for > good. > > Changes since v3: > - Patch 1: commit message expanded with the practical effect of the current > behaviour, the cost of propagating the error, and a description of the > recovery path that does not assume a particular regmap bus > implementation. No code change. > - Patch 2: unchanged. > > Neither patch was reproduced on hardware; both were found by code > inspection. They were compile-tested with W=1 and checked with smatch. > > Whether patch 1 is worth making is still a fair question - it trades a > possible idle power leak that may be cleared by a later successful access > for a runtime PM error state that needs an explicit reset. The commit > message spells that out; happy to drop it if you would rather not take > that trade. > > Linmao Li (2): > iio: imu: inv_icm42607: propagate runtime suspend errors > iio: imu: inv_icm42607: restore runtime PM on system resume errors > > .../iio/imu/inv_icm42607/inv_icm42607_core.c | 38 ++++++++++++++----- > 1 file changed, 29 insertions(+), 9 deletions(-) > > base-commit: 350d1fb9204b13c5f95e511e98b8bcb47574d425 > -- > 2.25.1 Tested on Invensense, ICM-42370-P development board. Performed testing with basic r/w to the device and checking the PM runtime status. It worked as expeted. Tested-by: Kanak Shilledar <kanak.shilledar@axis.com> -- Kanak Shilledar <kanak.shilledar@axis.com>
On Mon, 24 Aug 2026 11:55:29 +0800 Linmao Li <lilinmao@kylinos.cn> wrote: > The recently queued ICM-42607 PM support has two error paths that can leave > the PM core's state inconsistent with the device. > > Patch 1 propagates sensor shutdown failures from runtime suspend. Patch 2 > ensures that system resume restores runtime PM management on both of its > error paths, so that a failed resume does not leave runtime PM disabled for > good. These look fine to me, but I want input from Chris (and ideally some sanity check testing) before picking them up. The dead chicken test that they don't active break operation when we don't see errors is probably enough given the analysis seems fine to me for what happens on error. Thanks, Jonathan > > Changes since v3: > - Patch 1: commit message expanded with the practical effect of the current > behaviour, the cost of propagating the error, and a description of the > recovery path that does not assume a particular regmap bus > implementation. No code change. > - Patch 2: unchanged. > > Neither patch was reproduced on hardware; both were found by code > inspection. They were compile-tested with W=1 and checked with smatch. > > Whether patch 1 is worth making is still a fair question - it trades a > possible idle power leak that may be cleared by a later successful access > for a runtime PM error state that needs an explicit reset. The commit > message spells that out; happy to drop it if you would rather not take > that trade. > > Linmao Li (2): > iio: imu: inv_icm42607: propagate runtime suspend errors > iio: imu: inv_icm42607: restore runtime PM on system resume errors > > .../iio/imu/inv_icm42607/inv_icm42607_core.c | 38 ++++++++++++++----- > 1 file changed, 29 insertions(+), 9 deletions(-) > > > base-commit: 350d1fb9204b13c5f95e511e98b8bcb47574d425
On Tue, 1 Sep 2026 02:22:43 +0100 Jonathan Cameron <jic23@kernel.org> wrote: > On Mon, 24 Aug 2026 11:55:29 +0800 > Linmao Li <lilinmao@kylinos.cn> wrote: > > > The recently queued ICM-42607 PM support has two error paths that can leave > > the PM core's state inconsistent with the device. > > > > Patch 1 propagates sensor shutdown failures from runtime suspend. Patch 2 > > ensures that system resume restores runtime PM management on both of its > > error paths, so that a failed resume does not leave runtime PM disabled for > > good. > > These look fine to me, but I want input from Chris (and ideally some sanity > check testing) before picking them up. The dead chicken test that they > don't active break operation when we don't see errors is probably enough > given the analysis seems fine to me for what happens on error. Kanak, given you are looking at this driver perhaps you could take a look at this series as well? Thanks, Jonathan > > Thanks, > > Jonathan > > > > > Changes since v3: > > - Patch 1: commit message expanded with the practical effect of the current > > behaviour, the cost of propagating the error, and a description of the > > recovery path that does not assume a particular regmap bus > > implementation. No code change. > > - Patch 2: unchanged. > > > > Neither patch was reproduced on hardware; both were found by code > > inspection. They were compile-tested with W=1 and checked with smatch. > > > > Whether patch 1 is worth making is still a fair question - it trades a > > possible idle power leak that may be cleared by a later successful access > > for a runtime PM error state that needs an explicit reset. The commit > > message spells that out; happy to drop it if you would rather not take > > that trade. > > > > Linmao Li (2): > > iio: imu: inv_icm42607: propagate runtime suspend errors > > iio: imu: inv_icm42607: restore runtime PM on system resume errors > > > > .../iio/imu/inv_icm42607/inv_icm42607_core.c | 38 ++++++++++++++----- > > 1 file changed, 29 insertions(+), 9 deletions(-) > > > > > > base-commit: 350d1fb9204b13c5f95e511e98b8bcb47574d425 > >
Hi, On Mon, 2026-09-14 at 04:05 +0100, Jonathan Cameron wrote: > On Tue, 1 Sep 2026 02:22:43 +0100 > Jonathan Cameron <jic23@kernel.org> wrote: > > > On Mon, 24 Aug 2026 11:55:29 +0800 > > Linmao Li <lilinmao@kylinos.cn> wrote: > > > > > The recently queued ICM-42607 PM support has two error paths that > > > can leave > > > the PM core's state inconsistent with the device. > > > > > > Patch 1 propagates sensor shutdown failures from runtime > > > suspend. Patch 2 > > > ensures that system resume restores runtime PM management on both > > > of its > > > error paths, so that a failed resume does not leave runtime PM > > > disabled for > > > good. > > > > These look fine to me, but I want input from Chris (and ideally > > some sanity > > check testing) before picking them up. The dead chicken test that > > they > > don't active break operation when we don't see errors is probably > > enough > > given the analysis seems fine to me for what happens on error. > > Kanak, given you are looking at this driver perhaps you could take > a look at this series as well? Sure, I will have a look at this. Thanks and Regards, Kanak Shilledar
© 2016 - 2026 Red Hat, Inc.