All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nuno Sá" <noname.nuno@gmail.com>
To: Joshua Crofts <joshua.crofts1@gmail.com>
Cc: "Jonathan Cameron" <jic23@kernel.org>,
	"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,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>
Subject: Re: [PATCH 3/8] iio: magnetometer: ak8975: switch to using managed resources
Date: Tue, 12 May 2026 09:07:22 +0100	[thread overview]
Message-ID: <agLd7t10HBjbEzYq@nsa> (raw)
In-Reply-To: <CALoEA-x9TtnWbGCtTo-jhrJ7Zic1S7J=xRYSL0VZgOvTb1GGCA@mail.gmail.com>

On Sat, May 09, 2026 at 03:32:59PM +0200, Joshua Crofts wrote:
> On Sat, 9 May 2026 at 11:02, Nuno Sá <noname.nuno@gmail.com> wrote:
> >
> > On Thu, 2026-05-07 at 16:35 +0200, Joshua Crofts via B4 Relay wrote:
> > > From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > >
> > > 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.
> > >
> > > Additionally, remove any pm_runtime_get/put*() function calls that
> > > dummy cycled the counter to autosuspend the device.
> > >
> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > Co-developed-by: Joshua Crofts <joshua.crofts1@gmail.com>
> > > Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com>
> > > ---
> > >  drivers/iio/magnetometer/ak8975.c | 74 ++++++++++++++++++++++-----------------
> > >  1 file changed, 41 insertions(+), 33 deletions(-)
> > >
> > > diff --git a/drivers/iio/magnetometer/ak8975.c b/drivers/iio/magnetometer/ak8975.c
> > > index
> > > 63b6e8465f5f3873841550a1cd03ce86b95d1d67..1d8f448d5179fe9b33af989cc2f456ac91bc2f17
> > > 100644
> > > --- a/drivers/iio/magnetometer/ak8975.c
> > > +++ b/drivers/iio/magnetometer/ak8975.c
> > > @@ -898,9 +898,24 @@ static irqreturn_t ak8975_handle_trigger(int irq, void *p)
> > >       return IRQ_HANDLED;
> > >  }
> > >
> > > +static void devm_ak8975_power_off(void *data)
> > > +{
> > > +     struct ak8975_data *ak = data;
> > > +     struct device *dev = &ak->client->dev;
> > > +
> > > +     /* Only power down if currently active */
> > > +     if (pm_runtime_status_suspended(dev))
> > > +             return;
> > > +
> > > +     /* Soft-stop the chip before hard-stopping the regulators */
> > > +     ak8975_set_mode(data, POWER_DOWN);
> > > +     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;
> > > @@ -968,10 +983,21 @@ static int ak8975_probe(struct i2c_client *client)
> > >       if (ret)
> > >               return ret;
> > >
> > > +     /*
> > > +      * Set device as active early so pm_runtime_status_suspended() works
> > > +      * correctly if probe fails before pm_runtime is enabled. Do not attempt
> > > +      * to move this line lower.
> > > +      */
> > > +     pm_runtime_set_active(dev);
> > > +
> > > +     ret = devm_add_action_or_reset(dev, devm_ak8975_power_off, data);
> > > +     if (ret)
> > > +             return ret;
> >
> > This looks a bit hackish to me. Why don't we just register this powerdown action
> > after enabling PM?
> 
> This is to prevent a resource leak. If we register the power_off
> function at the end,
> any potential probe() failures will leave the regulators on.

Okay it does make sense! I now see the action is registered after
ak8975_power_on() which what makes sense. Still would like to avoid that
weird pm_runtime_set_active() call. It would be nice if we could
guarantee through PM that the device get's suspended on unbind. Oh well,
I guess this is ok.

- Nuno Sá

> 
> > > +
> > >       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);
> > >
> > > @@ -979,10 +1005,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;
> > > @@ -990,52 +1019,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_enable(dev);
> > > +     if (ret)
> > > +             return ret;
> >
> > Maybe it would make sense to move this before devm_iio_device_register(). At the
> > point we register the device, userspace can start to interact with the device where
> > we have pm calls? Not that it is a problem (I think) but makes sense to me to enable
> > PM before exposing the device.
> 
> Sure, I agree with this.
> 
> -- 
> Kind regards
> 
> CJD

  reply	other threads:[~2026-05-12  8:06 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-07 14:35 [PATCH 0/8] iio: magnetometer: ak8975: driver cleanup Joshua Crofts
2026-05-07 14:35 ` Joshua Crofts via B4 Relay
2026-05-07 14:35 ` [PATCH 1/8] iio: magnetometer: ak8975: modernize polling loops with iopoll() macros Joshua Crofts
2026-05-07 14:35   ` Joshua Crofts via B4 Relay
2026-05-09  8:48   ` Nuno Sá
2026-05-07 14:35 ` [PATCH 2/8] iio: magnetometer: ak8975: check if gpiod read was successful Joshua Crofts
2026-05-07 14:35   ` Joshua Crofts via B4 Relay
2026-05-09  8:49   ` Nuno Sá
2026-05-07 14:35 ` [PATCH 3/8] iio: magnetometer: ak8975: switch to using managed resources Joshua Crofts
2026-05-07 14:35   ` Joshua Crofts via B4 Relay
2026-05-08  9:58   ` Andy Shevchenko
2026-05-08 13:51     ` Joshua Crofts
2026-05-09  6:52       ` Andy Shevchenko
2026-05-09  7:47         ` Joshua Crofts
2026-05-09  7:54           ` Andy Shevchenko
2026-05-11 18:17             ` Jonathan Cameron
2026-05-09  9:03   ` Nuno Sá
2026-05-09 13:32     ` Joshua Crofts
2026-05-12  8:07       ` Nuno Sá [this message]
2026-05-12  8:12         ` Joshua Crofts
2026-05-12  8:23           ` Andy Shevchenko
2026-05-12 11:15             ` Jonathan Cameron
2026-05-09 17:15     ` Andy Shevchenko
2026-05-11  7:04       ` Joshua Crofts
2026-05-11 13:12         ` Jonathan Cameron
2026-05-07 14:35 ` [PATCH 4/8] iio: magnetometer: ak8975: consistently use 'data' parameter Joshua Crofts
2026-05-07 14:35   ` Joshua Crofts via B4 Relay
2026-05-09  9:04   ` Nuno Sá
2026-05-07 14:35 ` [PATCH 5/8] iio: magnetometer: ak8975: unify messages with help of dev_err_probe() Joshua Crofts
2026-05-07 14:35   ` Joshua Crofts via B4 Relay
2026-05-09  9:05   ` Nuno Sá
2026-05-07 14:35 ` [PATCH 6/8] iio: magnetometer: ak8975: use temporary variable for struct device Joshua Crofts
2026-05-07 14:35   ` Joshua Crofts via B4 Relay
2026-05-09  9:06   ` Nuno Sá
2026-05-07 14:35 ` [PATCH 7/8] iio: magnetometer: ak8975: add scan mask index enum Joshua Crofts
2026-05-07 14:35   ` Joshua Crofts via B4 Relay
2026-05-09  9:07   ` Nuno Sá
2026-05-07 14:35 ` [PATCH 8/8] iio: magnetometer: ak8975: make use of the macros from bits.h Joshua Crofts
2026-05-07 14:35   ` Joshua Crofts via B4 Relay
2026-05-09  9:09   ` Nuno Sá
2026-05-09  9:15     ` Joshua Crofts
2026-05-09 17:16     ` Andy Shevchenko
2026-05-08  7:39 ` [PATCH 0/8] iio: magnetometer: ak8975: driver cleanup Andy Shevchenko
2026-05-08  8:59   ` Joshua Crofts
2026-05-08  9:19     ` Andy Shevchenko
2026-05-08 13:34       ` Jonathan Cameron
2026-05-08 13:45         ` Joshua Crofts

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=agLd7t10HBjbEzYq@nsa \
    --to=noname.nuno@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=andy@kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=jic23@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.