From: Jonathan Cameron <jic23@kernel.org>
To: "Ondřej Jirman" <megi@xff.cz>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Lars-Peter Clausen <lars@metafoo.de>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Andrey Skvortsov <andrej.skvortzov@gmail.com>,
Icenowy Zheng <icenowy@aosc.io>,
Dalton Durst <dalton@ubports.com>,
Shoji Keita <awaittrot@shjk.jp>,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/4] iio: magnetometer: add a driver for Voltafield AF8133J magnetometer
Date: Fri, 16 Feb 2024 15:39:25 +0000 [thread overview]
Message-ID: <20240216153925.291e65e7@jic23-huawei> (raw)
In-Reply-To: <q2w6ll3dbr2pjcm3kuh2yckbgwk2er7k44uyq6hmdcdci4acek@htxdnogdpoza>
On Wed, 14 Feb 2024 18:43:10 +0100
Ondřej Jirman <megi@xff.cz> wrote:
> Hi Jonathan,
Gah. Runtime pm always gives me a headache. I'd indeed misunderstood some
of what you are doing.
>
> On Wed, Feb 14, 2024 at 05:01:36PM +0000, Jonathan Cameron wrote:
> > On Mon, 12 Feb 2024 18:53:55 +0100
> > Ondřej Jirman <megi@xff.cz> wrote:
> >
> > > From: Icenowy Zheng <icenowy@aosc.io>
> > >
> > > AF8133J is a simple I2C-connected magnetometer, without interrupts.
> > >
> > > Add a simple IIO driver for it.
> > >
> > > Co-developed-by: Icenowy Zheng <icenowy@aosc.io>
> > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > > Signed-off-by: Dalton Durst <dalton@ubports.com>
> > > Signed-off-by: Shoji Keita <awaittrot@shjk.jp>
> > > Co-developed-by: Ondrej Jirman <megi@xff.cz>
> > > Signed-off-by: Ondrej Jirman <megi@xff.cz>
> >
> >
> > Hi a few comments (mostly on changes)
> >
> > The runtime_pm handling can be simplified somewhat if you
> > rearrange probe a little.
> >
> > > diff --git a/drivers/iio/magnetometer/af8133j.c b/drivers/iio/magnetometer/af8133j.c
> > > new file mode 100644
> > > index 000000000000..1f64a2337f6e
> > > --- /dev/null
> > > +++ b/drivers/iio/magnetometer/af8133j.c
> > > @@ -0,0 +1,528 @@
> >
> >
> > > +static int af8133j_take_measurement(struct af8133j_data *data)
> > > +{
> > > + unsigned int val;
> > > + int ret;
> > > +
> > > + ret = regmap_write(data->regmap,
> > > + AF8133J_REG_STATE, AF8133J_REG_STATE_WORK);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + /* The datasheet says "Mesaure Time <1.5ms" */
> > > + ret = regmap_read_poll_timeout(data->regmap, AF8133J_REG_STATUS, val,
> > > + val & AF8133J_REG_STATUS_ACQ,
> > > + 500, 1500);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + ret = regmap_write(data->regmap,
> > > + AF8133J_REG_STATE, AF8133J_REG_STATE_STBY);
> >
> > return regmap_write()
> >
> > regmap accesses return 0 or a negative error code enabling little code
> > reductions like this.
>
> Yeah, some reviewers dislike this, because modifying the code in the future
> creates a more unpleasant diff. But if you like this style, I don't mind
> changing it.
Always a gamble on chance of a modification coming.
In general I'd check regmap calls with if (ret) but don't feel that strongly
about that either.
So not really important either way.
>
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int af8133j_read_measurement(struct af8133j_data *data, __le16 buf[3])
> > > +{
> > > + struct device *dev = &data->client->dev;
> > > + int ret;
> > > +
> > > + ret = pm_runtime_resume_and_get(dev);
> > > + if (ret) {
> > > + /*
> > > + * Ignore EACCES because that happens when RPM is disabled
> > > + * during system sleep, while userspace leave eg. hrtimer
> > > + * trigger attached and IIO core keeps trying to do measurements.
> >
> > Yeah. We still need to fix that more elegantly :(
> >
> > > + */
> > > + if (ret != -EACCES)
> > > + dev_err(dev, "Failed to power on (%d)\n", ret);
> > > + return ret;
> > > + }
> > > +
> > > + scoped_guard(mutex, &data->mutex) {
> > > + ret = af8133j_take_measurement(data);
> > > + if (ret)
> > > + goto out_rpm_put;
> > > +
> > > + ret = regmap_bulk_read(data->regmap, AF8133J_REG_OUT,
> > > + buf, sizeof(__le16) * 3);
> > > + }
> > > +
> > > +out_rpm_put:
> > > + pm_runtime_mark_last_busy(dev);
> > > + pm_runtime_put_autosuspend(dev);
> > > +
> > > + return ret;
> > > +}
> > > +
> >
> >
> > > +
> > > +static int af8133j_set_scale(struct af8133j_data *data,
> > > + unsigned int val, unsigned int val2)
> > > +{
> > > + struct device *dev = &data->client->dev;
> > > + u8 range;
> > > + int ret = 0;
> > > +
> > > + if (af8133j_scales[0][0] == val && af8133j_scales[0][1] == val2)
> > > + range = AF8133J_REG_RANGE_12G;
> > > + else if (af8133j_scales[1][0] == val && af8133j_scales[1][1] == val2)
> > > + range = AF8133J_REG_RANGE_22G;
> > > + else
> > > + return -EINVAL;
> > > +
> > > + pm_runtime_disable(dev);
> > > +
> > > + /*
> > > + * When suspended, just store the new range to data->range to be
> > > + * applied later during power up.
> > Better to just do
> > pm_runtime_resume_and_get() here
> >
> > > + */
> > > + if (!pm_runtime_status_suspended(dev))
> > > + ret = regmap_write(data->regmap, AF8133J_REG_RANGE, range);
> > > +
> > > + pm_runtime_enable(dev);
> > and
> > pm_runtime_mark_last_busy(dev);
> > pm_runtime_put_autosuspend(dev);
> > here.
> >
> > The userspace interface is only way this function is called so rearrange
> > probe a little so that you don't need extra complexity in these functions.
>
> It doesn't make sense to wakeup the device for range change, because it will
> forget the range the moment it's powered off again, after changing the range.
Ah. I'd missed understood that. Thanks for extra explanation.
I'm not keen on the enable / disable dance but anything else is probably worse
(delaying update until we actually using it etc).
>
> Also this function has nothing to do with probe. data->range is authoritative
> value, not cache. It gets applied to HW on each power up.
>
> >
> > > +
> > > + data->range = range;
> >
> > If the write failed, generally don't update the cached value.
>
> Right.
>
> > > + return ret;
> > > +}
> > > +
> > > +static int af8133j_write_raw(struct iio_dev *indio_dev,
> > > + struct iio_chan_spec const *chan,
> > > + int val, int val2, long mask)
> > > +{
> > > + struct af8133j_data *data = iio_priv(indio_dev);
> > > + int ret;
> > > +
> > > + switch (mask) {
> > > + case IIO_CHAN_INFO_SCALE:
> > > + scoped_guard(mutex, &data->mutex)
> > > + ret = af8133j_set_scale(data, val, val2);
> >
> > Look more closely at what scoped_guard() does.
> > return af8133j_set_scale(data, val, val2);
> > is fine and simpler as no local variable needed.
>
> I did, it will not work as you suggest. It's implemented as for loop with
> condition, and the compiler will complain about fallthrough.
>
> I can do:
>
> scoped_guard(mutex, &data->mutex)
> return af8133j_set_scale(data, val, val2);
> return 0;
>
> but it looks weirder at first glance, at least to my eye.
I agree that bit is less than ideal, but with your code it should also
get confused about whether ret is ever set.
scoped_guard(mutex, &data->mutex)
return ...
unreachable();
perhaps? or just use a guard and add scope manually
case IIO_CHAN_INFO_SCALE: {
guard(mutex)(&data->mutex);
return af8133j_set_scale(...);
}
I'd go with this as the cleanest solution in this case.
>
> > > + return ret;
> > > + default:
> > > + return -EINVAL;
> > > + }
> > > +}
> >
> > > +static void af8133j_power_down_action(void *ptr)
> > > +{
> > > + struct af8133j_data *data = ptr;
> > > + struct device *dev = &data->client->dev;
> > > +
> > > + pm_runtime_disable(dev);
> > You group together unwinding of calls that occur in very
> > different places in probe. Don't do that as it leas
> > to disabling runtime pm having never enabled it
> > in some error paths. That may be safe but if fails the
> > obviously correct test.
>
> This whole disable/enable dance is here so that pm_runtime_status_suspended can
> be trusted. Not for disabling PM during device remove or in error paths.
>
> There's no imbalance here or problem with disabling PM when it's already
> disabled. Disable/enable is reference counted, and this function keeps the
> balance.
Whilst not buggy but I still want to be able to cleanly associate a given
bit of cleanup with what is being cleaned up. That is the path to
maintainable code longer term. Runtime PM does make a mess of doing this
but tends to have somewhat logical sets of calls that go together.
As long as we hold a reference, doesn't matter when we turn it on in probe()
Only the put_autosuspend has to come after we done talking to it.
>
> > So this is a good solution to the normal dance of turning power on
> > just to turn it off shortly afterwards.
> >
> > > + af8133j_power_down(data);
> > > + pm_runtime_enable(dev);
> > Why?
>
> See above. To keep the disable ref count balanced.
>
> Looks like actual RPM disable already happened at this point a bit earlier in
> another callback registered via devm_pm_runtime_enable(). I guess this
> pm_runtime_enable()/pm_runtime_disable() guard can just be skipped, because RPM
> is already disabled thanks to reverse ordering of devm callbacks during device
> remove. So while this is safe, it's redundant at this point and call to
> pm_runtime_status_suspended() is safe without this.
Yes, That's a side effect of only enabling it right at the end.
>
> > > +}
> > > +
> > > +static int af8133j_probe(struct i2c_client *client)
> > > +{
> > > + struct device *dev = &client->dev;
> > > + struct af8133j_data *data;
> > > + struct iio_dev *indio_dev;
> > > + struct regmap *regmap;
> > > + int ret, i;
> > > +
> > > + indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
> > > + if (!indio_dev)
> > > + return -ENOMEM;
> > > +
> > > + regmap = devm_regmap_init_i2c(client, &af8133j_regmap_config);
> > > + if (IS_ERR(regmap))
> > > + return dev_err_probe(dev, PTR_ERR(regmap),
> > > + "regmap initialization failed\n");
> > > +
> > > + data = iio_priv(indio_dev);
> > > + i2c_set_clientdata(client, indio_dev);
> > > + data->client = client;
> > > + data->regmap = regmap;
> > > + data->range = AF8133J_REG_RANGE_12G;
> > > + mutex_init(&data->mutex);
> > > +
> > > + data->reset_gpiod = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
> > > + if (IS_ERR(data->reset_gpiod))
> > > + return dev_err_probe(dev, PTR_ERR(data->reset_gpiod),
> > > + "Failed to get reset gpio\n");
> > > +
> > > + for (i = 0; i < ARRAY_SIZE(af8133j_supply_names); i++)
> > > + data->supplies[i].supply = af8133j_supply_names[i];
> > > + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(data->supplies),
> > > + data->supplies);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = iio_read_mount_matrix(dev, &data->orientation);
> > > + if (ret)
> > > + return dev_err_probe(dev, ret, "Failed to read mount matrix\n");
> > > +
> > > + ret = af8133j_power_up(data);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + pm_runtime_set_active(dev);
> > > +
> > > + ret = devm_add_action_or_reset(dev, af8133j_power_down_action, data);
> >
> > As mentioned above, this should only undo things done before this point.
> > So just the af8133j_power_down() I think.
>
> The callback doesn't do anything else but power down. It leaves everything
> else as is after it exits.
>
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = af8133j_product_check(data);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + indio_dev->info = &af8133j_info;
> > > + indio_dev->name = "af8133j";
> > > + indio_dev->channels = af8133j_channels;
> > > + indio_dev->num_channels = ARRAY_SIZE(af8133j_channels);
> > > + indio_dev->modes = INDIO_DIRECT_MODE;
> > > +
> > > + ret = devm_iio_triggered_buffer_setup(dev, indio_dev, NULL,
> > > + &af8133j_trigger_handler, NULL);
> > > + if (ret < 0)
> > > + return dev_err_probe(&client->dev, ret,
> > > + "Failed to setup iio triggered buffer\n");
> > > +
> > > + ret = devm_iio_device_register(dev, indio_dev);
> > > + if (ret)
> > > + return dev_err_probe(dev, ret, "Failed to register iio device");
> > > +
> > > + pm_runtime_get_noresume(dev);
> >
> > > + pm_runtime_use_autosuspend(dev);
> > > + pm_runtime_set_autosuspend_delay(dev, 500);
> > > + ret = devm_pm_runtime_enable(dev);
> >
> > This already deals with pm_runtime_disable() so you shouldn't need do it manually.
>
> I'm not disabling RPM manually, it was just used as temporary guard to be able
> to read pm_runtime_status_suspended() safely.
I'd indeed misunderstood that. I forgot the oddity that runtime pm is effectively
reference counting in only one direction for enable / disable and the opposite
one for get and put.
pm_runtime_disable()
pm_runtime_disable()
pm_runtime_enable()
pm_runtime_enable()
pm_runtime_enable()
is fine, but
pm_runtime_enable()
pm_runtime_enable()
pm_runtime_disable()
pm_runtime_disable()
pm_runtime_enable()
is not.
Which makes sense when you realise it's all about ensuring it is off, but
never ensuring that it is turned on.
>
> > Also you want to enable that before the devm_iio_device_register() to avoid
> > problems with it not being available as the userspace interfaces are used.
> >
> > So just move this up a few lines.
>
> Good idea, thanks.
>
> kind regards,
> o.
>
> >
> >
> > > + if (ret)
> > > + return ret;
> > > +
> > > + pm_runtime_put_autosuspend(dev);
> > > +
> > > + return 0;
> > > +}
> >
next prev parent reply other threads:[~2024-02-16 15:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-12 17:53 [PATCH v2 0/4] Add support for AF8133J magnetometer Ondřej Jirman
2024-02-12 17:53 ` [PATCH v2 1/4] dt-bindings: vendor-prefix: Add prefix for Voltafield Ondřej Jirman
2024-02-12 17:53 ` [PATCH v2 2/4] dt-bindings: iio: magnetometer: Add Voltafield AF8133J Ondřej Jirman
2024-02-13 19:23 ` Conor Dooley
2024-02-12 17:53 ` [PATCH v2 3/4] iio: magnetometer: add a driver for Voltafield AF8133J magnetometer Ondřej Jirman
2024-02-13 21:21 ` Andrey Skvortsov
2024-02-14 16:38 ` Jonathan Cameron
2024-02-14 20:04 ` Andrey Skvortsov
2024-02-14 17:01 ` Jonathan Cameron
2024-02-14 17:43 ` Ondřej Jirman
2024-02-16 15:39 ` Jonathan Cameron [this message]
2024-02-16 17:54 ` Ondřej Jirman
2024-02-12 17:53 ` [PATCH v2 4/4] MAINTAINERS: Add an entry for AF8133J driver Ondřej Jirman
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=20240216153925.291e65e7@jic23-huawei \
--to=jic23@kernel.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=andrej.skvortzov@gmail.com \
--cc=awaittrot@shjk.jp \
--cc=conor+dt@kernel.org \
--cc=dalton@ubports.com \
--cc=devicetree@vger.kernel.org \
--cc=icenowy@aosc.io \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=megi@xff.cz \
--cc=robh+dt@kernel.org \
/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.