public inbox for linux-iio@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
	"David Lechner" <dlechner@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	"Joshua Crofts" <joshua.crofts1@gmail.com>
Subject: Re: [PATCH v0 10/14] iio: magnetometer: ak8975: switch to using managed resources
Date: Tue, 28 Apr 2026 17:32:56 +0100	[thread overview]
Message-ID: <20260428173256.25a64370@jic23-huawei> (raw)
In-Reply-To: <20260427201412.3067235-11-andriy.shevchenko@linux.intel.com>

On Mon, 27 Apr 2026 22:09:55 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> Switch the driver to use managed resources (devm_*) which simplifier
> error handling and allows removing ak8975_remove() method from
> the driver.
> 
> Note, on error path we now also set mode to POWER_DOWN state which is
> fine. Even if the device is in that mode, there is no problem to set
> that mode again, it should be no-op.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

One day I'll have time to write up some notes on patterns that work
for runtime pm + devm. I don't think think this one does - note original
code didn't work either as would underflow on regulators in some paths
and hence print warnings.
> ---
>  drivers/iio/magnetometer/ak8975.c | 59 ++++++++++++++-----------------
>  1 file changed, 26 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/iio/magnetometer/ak8975.c b/drivers/iio/magnetometer/ak8975.c
> index 53158ffd173b..d666d9d171bd 100644
> --- a/drivers/iio/magnetometer/ak8975.c
> +++ b/drivers/iio/magnetometer/ak8975.c
> @@ -888,9 +888,16 @@ static irqreturn_t ak8975_handle_trigger(int irq, void *p)
>  	return IRQ_HANDLED;
>  }
>  
> +static void devm_ak8975_power_off(void *data)
> +{
> +	ak8975_set_mode(data, POWER_DOWN);

Add a comment somewhere appropriate on what we are undoing with this.

It's a 'might not be runtime suspended' at time of remove I think
rather than the mode being set at that point in probe.

If it is suspended, we shouldn't call the regulator disables
in power_off.  So maybe gate this whole thing on
whether runtime suspended.  If you do that be careful with what
state we are in until runtime PM is enabled.  Maybe you already have that
covered elsewhere.


> +	ak8975_power_off(data);
> +}
> +
>  static int ak8975_probe(struct i2c_client *client)
>  {
>  	const struct i2c_device_id *id = i2c_client_get_device_id(client);
> +	struct device *dev = &client->dev;
>  	struct ak8975_data *data;
>  	struct iio_dev *indio_dev;
>  	struct gpio_desc *eoc_gpiod;
> @@ -958,10 +965,14 @@ static int ak8975_probe(struct i2c_client *client)
>  	if (ret)
>  		return ret;

If following comments above and below you'd need to set the state
to active here.  If you go that way, make sure to add a comment to
say why it is up here (and hopefully prevent someone thinking they can
move it down).

>  
> +	ret = devm_add_action_or_reset(dev, devm_ak8975_power_off, data);
> +	if (ret)
> +		return ret;
> +
>  	ret = ak8975_who_i_am(client, data->def->type);
>  	if (ret) {
>  		dev_err(&client->dev, "Unexpected device\n");
> -		goto power_off;
> +		return ret;
>  	}
>  	dev_dbg(&client->dev, "Asahi compass chip %s\n", name);
>  
> @@ -969,10 +980,13 @@ static int ak8975_probe(struct i2c_client *client)
>  	ret = ak8975_setup(client);
>  	if (ret) {
>  		dev_err(&client->dev, "%s initialization fails\n", name);
> -		goto power_off;
> +		return ret;
>  	}
>  
> -	mutex_init(&data->lock);
> +	ret = devm_mutex_init(dev, &data->lock);
> +	if (ret)
> +		return ret;
> +
>  	indio_dev->channels = ak8975_channels;
>  	indio_dev->num_channels = ARRAY_SIZE(ak8975_channels);
>  	indio_dev->info = &ak8975_info;
> @@ -980,52 +994,32 @@ static int ak8975_probe(struct i2c_client *client)
>  	indio_dev->modes = INDIO_DIRECT_MODE;
>  	indio_dev->name = name;
>  
> -	ret = iio_triggered_buffer_setup(indio_dev, NULL, ak8975_handle_trigger,
> -					 NULL);
> +	ret = devm_iio_triggered_buffer_setup(dev, indio_dev, NULL,
> +					      ak8975_handle_trigger, NULL);
>  	if (ret) {
>  		dev_err(&client->dev, "triggered buffer setup failed\n");
> -		goto power_off;
> +		return ret;
>  	}
>  
> -	ret = iio_device_register(indio_dev);
> +	ret = devm_iio_device_register(dev, indio_dev);
>  	if (ret) {
>  		dev_err(&client->dev, "device register failed\n");
> -		goto cleanup_buffer;
> +		return ret;
>  	}
>  
>  	/* Enable runtime PM */
> -	pm_runtime_get_noresume(&client->dev);
> -	pm_runtime_set_active(&client->dev);
> -	pm_runtime_enable(&client->dev);
> +	ret = devm_pm_runtime_set_active_enabled(dev);

This hits the race with whether we can query if the device is disabled mentioned
above. Dance where we need to be able to check that before we turn runtime pm on
so that we can correctly do regulator disables if we error out before here.

> +	if (ret)
> +		return ret;
> +
>  	/*
>  	 * The device comes online in 500us, so add two orders of magnitude
>  	 * of delay before autosuspending: 50 ms.
>  	 */
>  	pm_runtime_set_autosuspend_delay(&client->dev, 50);
>  	pm_runtime_use_autosuspend(&client->dev);
> -	pm_runtime_put(&client->dev);
>  
>  	return 0;
> -
> -cleanup_buffer:
> -	iio_triggered_buffer_cleanup(indio_dev);
> -power_off:
> -	ak8975_power_off(data);
> -	return ret;
> -}


  reply	other threads:[~2026-04-28 16:33 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-27 20:09 [PATCH v0 00/14] iio: magnetometer: ak8975: Additional changes to the driver Andy Shevchenko
2026-04-27 20:09 ` [PATCH v0 01/14] drivers/iio/magnetometer/ak8975.c: fixup for the IWYU change Andy Shevchenko
2026-04-27 20:09 ` [PATCH v0 02/14] drivers/iio/magnetometer/ak8975.c: fixup for the errno fix Andy Shevchenko
2026-04-27 20:09 ` [PATCH v0 03/14] drivers/iio/magnetometer/ak8975.c: fixup for the iopoll.h conversion Andy Shevchenko
2026-04-27 20:09 ` [PATCH v0 04/14] iio: magnetometer: ak8975: Inline timeout constants Andy Shevchenko
2026-04-28 16:22   ` Jonathan Cameron
2026-04-28 17:06     ` Andy Shevchenko
2026-04-27 20:09 ` [PATCH v0 05/14] iio: magnetometer: ak8975: Avoid using temporary variable Andy Shevchenko
2026-04-27 20:09 ` [PATCH v0 06/14] iio: magnetometer: ak8975: Drop duplicate NULL check Andy Shevchenko
2026-04-27 20:09 ` [PATCH v0 07/14] iio: magnetometer: ak8975: remove duplicate error message Andy Shevchenko
2026-04-27 20:09 ` [PATCH v0 08/14] iio: magnetometer: ak8975: Reduce usage of magic lengths of the buffer Andy Shevchenko
2026-04-27 20:09 ` [PATCH v0 09/14] iio: magnetometer: ak8975: Unify return code variable name Andy Shevchenko
2026-04-27 20:09 ` [PATCH v0 10/14] iio: magnetometer: ak8975: switch to using managed resources Andy Shevchenko
2026-04-28 16:32   ` Jonathan Cameron [this message]
2026-04-27 20:09 ` [PATCH v0 11/14] iio: magnetometer: ak8975: Consistently use 'data' parameter Andy Shevchenko
2026-04-27 20:09 ` [PATCH v0 12/14] iio: magnetometer: ak8975: Unify messages with help of dev_err_probe() Andy Shevchenko
2026-04-28  9:21   ` Joshua Crofts
2026-04-28  9:46     ` Andy Shevchenko
2026-04-28  9:52       ` Joshua Crofts
2026-04-27 20:09 ` [PATCH v0 13/14] iio: magnetometer: ak8975: Use temporary variable for struct device Andy Shevchenko
2026-04-27 20:09 ` [PATCH v0 14/14] iio: magnetometer: ak8975: Make use of the macros from bits.h Andy Shevchenko
2026-04-28  7:23   ` Joshua Crofts
2026-04-28  7:54     ` Andy Shevchenko
2026-04-27 20:19 ` [PATCH v0 00/14] iio: magnetometer: ak8975: Additional changes to the driver Andy Shevchenko
2026-04-28  6:37 ` Joshua Crofts
2026-04-28  7:03   ` Andy Shevchenko
2026-04-28  7:14     ` Joshua Crofts
2026-04-28 16:16       ` Jonathan Cameron
2026-04-28 16:23         ` Joshua Crofts
2026-04-28 16:35 ` 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=20260428173256.25a64370@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=andy@kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=joshua.crofts1@gmail.com \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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