mpu3050_runtime_resume() only calls mpu3050_power_up(), which clears
the SLEEP bit and waits 200 ms for the chip's register file to come
back. It does not reprogram the full-scale, low-pass filter or sample
rate divisor, all of which return to the chip's power-on defaults
across a power cycle.

The driver's cached state (mpu3050->fullscale, mpu3050->lpf,
mpu3050->divisor) is the source of truth for what userspace observes
through the IIO ABI: in_anglvel_sampling_frequency goes through
mpu3050_get_freq() which reads the cached lpf and divisor, and
in_anglvel_scale similarly reads cached fullscale. After the first
autosuspend cycle the chip's actual sample rate diverges from what
sysfs reports, until the next IIO_CHAN_INFO_RAW read incidentally
reprograms the chip via mpu3050_set_8khz_samplerate() and the cached
state restoration paths in mpu3050_fifo_read_one().

That incidental restoration is only triggered by direct sysfs raw
reads, not by buffered/triggered mode. A user who configures the
sample rate, starts buffered capture and then leaves the device idle
long enough to autosuspend will see chip-default-rate samples after
resume rather than the configured rate.

Reprogram the chip from the cached state in mpu3050_runtime_resume()
by calling mpu3050_start_sampling() after mpu3050_power_up() succeeds.
On failure power the chip back down to keep regulator and pm_runtime
reference counts in sync with the error path.

Fixes: 3904b28efb2c ("iio: gyro: Add driver for the MPU-3050 gyroscope")
Signed-off-by: Herman van Hazendonk <github.com@herrie.org>
---
 drivers/iio/gyro/mpu3050-core.c | 27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/gyro/mpu3050-core.c b/drivers/iio/gyro/mpu3050-core.c
index d84e04e4b431..ac041074cfdf 100644
--- a/drivers/iio/gyro/mpu3050-core.c
+++ b/drivers/iio/gyro/mpu3050-core.c
@@ -1291,7 +1291,32 @@ static int mpu3050_runtime_suspend(struct device *dev)
 
 static int mpu3050_runtime_resume(struct device *dev)
 {
-	return mpu3050_power_up(iio_priv(dev_get_drvdata(dev)));
+	struct mpu3050 *mpu3050 = iio_priv(dev_get_drvdata(dev));
+	int ret;
+
+	ret = mpu3050_power_up(mpu3050);
+	if (ret)
+		return ret;
+
+	/*
+	 * mpu3050_power_up() only clears the SLEEP bit; it leaves the
+	 * full-scale, low-pass filter and sample rate divisor at the
+	 * chip's power-on defaults. Restore them from the driver's
+	 * cached state so the hardware matches what userspace observes
+	 * via the IIO ABI (in_anglvel_sampling_frequency, in_anglvel_scale)
+	 * across a suspend/resume cycle. Without this the chip continues
+	 * to deliver samples at chip-default rate after the first
+	 * autosuspend cycle, until the next IIO_CHAN_INFO_RAW read
+	 * incidentally reprograms it.
+	 */
+	ret = mpu3050_start_sampling(mpu3050);
+	if (ret) {
+		dev_err(dev, "failed to restore sampling config on resume\n");
+		mpu3050_power_down(mpu3050);
+		return ret;
+	}
+
+	return 0;
 }
 
 DEFINE_RUNTIME_DEV_PM_OPS(mpu3050_dev_pm_ops, mpu3050_runtime_suspend,
-- 
2.43.0

On Fri, Jun 5, 2026 at 10:47 AM Herman van Hazendonk
<github.com@herrie.org> wrote:

> mpu3050_runtime_resume() only calls mpu3050_power_up(), which clears
> the SLEEP bit and waits 200 ms for the chip's register file to come
> back. It does not reprogram the full-scale, low-pass filter or sample
> rate divisor, all of which return to the chip's power-on defaults
> across a power cycle.
>
> The driver's cached state (mpu3050->fullscale, mpu3050->lpf,
> mpu3050->divisor) is the source of truth for what userspace observes
> through the IIO ABI: in_anglvel_sampling_frequency goes through
> mpu3050_get_freq() which reads the cached lpf and divisor, and
> in_anglvel_scale similarly reads cached fullscale. After the first
> autosuspend cycle the chip's actual sample rate diverges from what
> sysfs reports, until the next IIO_CHAN_INFO_RAW read incidentally
> reprograms the chip via mpu3050_set_8khz_samplerate() and the cached
> state restoration paths in mpu3050_fifo_read_one().
>
> That incidental restoration is only triggered by direct sysfs raw
> reads, not by buffered/triggered mode. A user who configures the
> sample rate, starts buffered capture and then leaves the device idle
> long enough to autosuspend will see chip-default-rate samples after
> resume rather than the configured rate.
>
> Reprogram the chip from the cached state in mpu3050_runtime_resume()
> by calling mpu3050_start_sampling() after mpu3050_power_up() succeeds.
> On failure power the chip back down to keep regulator and pm_runtime
> reference counts in sync with the error path.
>
> Fixes: 3904b28efb2c ("iio: gyro: Add driver for the MPU-3050 gyroscope")
> Signed-off-by: Herman van Hazendonk <github.com@herrie.org>

Overall looks good to me, consider Andy's suggestion.
Reviewed-by: Linus Walleij <linusw@kernel.org>

Yours,
Linus Walleij

On Fri, Jun 05, 2026 at 10:47:22AM +0200, Herman van Hazendonk wrote:
> mpu3050_runtime_resume() only calls mpu3050_power_up(), which clears
> the SLEEP bit and waits 200 ms for the chip's register file to come
> back. It does not reprogram the full-scale, low-pass filter or sample
> rate divisor, all of which return to the chip's power-on defaults
> across a power cycle.
> 
> The driver's cached state (mpu3050->fullscale, mpu3050->lpf,
> mpu3050->divisor) is the source of truth for what userspace observes
> through the IIO ABI: in_anglvel_sampling_frequency goes through
> mpu3050_get_freq() which reads the cached lpf and divisor, and
> in_anglvel_scale similarly reads cached fullscale. After the first
> autosuspend cycle the chip's actual sample rate diverges from what
> sysfs reports, until the next IIO_CHAN_INFO_RAW read incidentally
> reprograms the chip via mpu3050_set_8khz_samplerate() and the cached
> state restoration paths in mpu3050_fifo_read_one().
> 
> That incidental restoration is only triggered by direct sysfs raw
> reads, not by buffered/triggered mode. A user who configures the
> sample rate, starts buffered capture and then leaves the device idle
> long enough to autosuspend will see chip-default-rate samples after
> resume rather than the configured rate.
> 
> Reprogram the chip from the cached state in mpu3050_runtime_resume()
> by calling mpu3050_start_sampling() after mpu3050_power_up() succeeds.
> On failure power the chip back down to keep regulator and pm_runtime
> reference counts in sync with the error path.

The commit message (at least) looks like AI assisted. Is it true?

...

> +	/*
> +	 * mpu3050_power_up() only clears the SLEEP bit; it leaves the
> +	 * full-scale, low-pass filter and sample rate divisor at the
> +	 * chip's power-on defaults. Restore them from the driver's
> +	 * cached state so the hardware matches what userspace observes
> +	 * via the IIO ABI (in_anglvel_sampling_frequency, in_anglvel_scale)
> +	 * across a suspend/resume cycle. Without this the chip continues
> +	 * to deliver samples at chip-default rate after the first
> +	 * autosuspend cycle, until the next IIO_CHAN_INFO_RAW read
> +	 * incidentally reprograms it.
> +	 */
> +	ret = mpu3050_start_sampling(mpu3050);
> +	if (ret) {
> +		dev_err(dev, "failed to restore sampling config on resume\n");
> +		mpu3050_power_down(mpu3050);
> +		return ret;
> +	}
> +
> +	return 0;

Can be

	if (ret) {
		dev_err(dev, "failed to restore sampling config on resume\n");
		mpu3050_power_down(mpu3050);
	}

	return ret;

-- 
With Best Regards,
Andy Shevchenko

On Fri,  5 Jun 2026 10:47:22 +0200
Herman van Hazendonk <github.com@herrie.org> wrote:

> mpu3050_runtime_resume() only calls mpu3050_power_up(), which clears
> the SLEEP bit and waits 200 ms for the chip's register file to come
> back. It does not reprogram the full-scale, low-pass filter or sample
> rate divisor, all of which return to the chip's power-on defaults
> across a power cycle.
> 
> The driver's cached state (mpu3050->fullscale, mpu3050->lpf,
> mpu3050->divisor) is the source of truth for what userspace observes
> through the IIO ABI: in_anglvel_sampling_frequency goes through
> mpu3050_get_freq() which reads the cached lpf and divisor, and
> in_anglvel_scale similarly reads cached fullscale. After the first
> autosuspend cycle the chip's actual sample rate diverges from what
> sysfs reports, until the next IIO_CHAN_INFO_RAW read incidentally
> reprograms the chip via mpu3050_set_8khz_samplerate() and the cached
> state restoration paths in mpu3050_fifo_read_one().
> 
> That incidental restoration is only triggered by direct sysfs raw
> reads, not by buffered/triggered mode. A user who configures the
> sample rate, starts buffered capture and then leaves the device idle
> long enough to autosuspend will see chip-default-rate samples after
> resume rather than the configured rate.
> 
> Reprogram the chip from the cached state in mpu3050_runtime_resume()
> by calling mpu3050_start_sampling() after mpu3050_power_up() succeeds.
> On failure power the chip back down to keep regulator and pm_runtime
> reference counts in sync with the error path.
> 
> Fixes: 3904b28efb2c ("iio: gyro: Add driver for the MPU-3050 gyroscope")
> Signed-off-by: Herman van Hazendonk <github.com@herrie.org>
This one looks fine to me, but I'd like some more eyes on it so will leave
it on list for a little while.

Jonathan

> ---
>  drivers/iio/gyro/mpu3050-core.c | 27 ++++++++++++++++++++++++++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/gyro/mpu3050-core.c b/drivers/iio/gyro/mpu3050-core.c
> index d84e04e4b431..ac041074cfdf 100644
> --- a/drivers/iio/gyro/mpu3050-core.c
> +++ b/drivers/iio/gyro/mpu3050-core.c
> @@ -1291,7 +1291,32 @@ static int mpu3050_runtime_suspend(struct device *dev)
>  
>  static int mpu3050_runtime_resume(struct device *dev)
>  {
> -	return mpu3050_power_up(iio_priv(dev_get_drvdata(dev)));
> +	struct mpu3050 *mpu3050 = iio_priv(dev_get_drvdata(dev));
> +	int ret;
> +
> +	ret = mpu3050_power_up(mpu3050);
> +	if (ret)
> +		return ret;
> +
> +	/*
> +	 * mpu3050_power_up() only clears the SLEEP bit; it leaves the
> +	 * full-scale, low-pass filter and sample rate divisor at the
> +	 * chip's power-on defaults. Restore them from the driver's
> +	 * cached state so the hardware matches what userspace observes
> +	 * via the IIO ABI (in_anglvel_sampling_frequency, in_anglvel_scale)
> +	 * across a suspend/resume cycle. Without this the chip continues
> +	 * to deliver samples at chip-default rate after the first
> +	 * autosuspend cycle, until the next IIO_CHAN_INFO_RAW read
> +	 * incidentally reprograms it.
> +	 */
> +	ret = mpu3050_start_sampling(mpu3050);
> +	if (ret) {
> +		dev_err(dev, "failed to restore sampling config on resume\n");
> +		mpu3050_power_down(mpu3050);
> +		return ret;
> +	}
> +
> +	return 0;
>  }
>  
>  DEFINE_RUNTIME_DEV_PM_OPS(mpu3050_dev_pm_ops, mpu3050_runtime_suspend,