From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Cristian Marussi <cristian.marussi@arm.com>
Cc: <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>, <sudeep.holla@arm.com>,
<lukasz.luba@arm.com>, <james.quinlan@broadcom.com>,
<f.fainelli@gmail.com>, <etienne.carriere@linaro.org>,
<thara.gopinath@linaro.org>, <vincent.guittot@linaro.org>,
<souvik.chakravarty@arm.com>, Jyoti Bhayana <jbhayana@google.com>,
"Jonathan Cameron" <jic23@kernel.org>,
<linux-iio@vger.kernel.org>
Subject: Re: [PATCH v7 25/38] iio/scmi: port driver to the new scmi_sensor_proto_ops interface
Date: Tue, 30 Mar 2021 18:34:04 +0100 [thread overview]
Message-ID: <20210330183404.00001909@Huawei.com> (raw)
In-Reply-To: <20210330125113.GD43717@e120937-lin>
On Tue, 30 Mar 2021 13:51:13 +0100
Cristian Marussi <cristian.marussi@arm.com> wrote:
> Hi Jonathan,
>
> On Tue, Mar 30, 2021 at 12:33:25PM +0100, Jonathan Cameron wrote:
> > On Tue, 16 Mar 2021 12:48:50 +0000
> > Cristian Marussi <cristian.marussi@arm.com> wrote:
> >
> > > Port driver to the new SCMI Sensor interface based on protocol handles
> > > and common devm_get_ops().
> > >
> > > Cc: Jyoti Bhayana <jbhayana@google.com>
> > > Cc: Jonathan Cameron <jic23@kernel.org>
> > > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> >
> > +CC linux-iio@vger.kernel.org
> >
> > Rule of thumb if it doesn't go there it ends up in randomly location based
> > on other lists and I might not see it for a few weeks :(
> >
>
> Ah sorry, I thought the direct CC was enough.
No problem. Too much email :)
>
> > > ---
> > > drivers/iio/common/scmi_sensors/scmi_iio.c | 91 ++++++++++------------
> > > 1 file changed, 41 insertions(+), 50 deletions(-)
> > >
> > > diff --git a/drivers/iio/common/scmi_sensors/scmi_iio.c b/drivers/iio/common/scmi_sensors/scmi_iio.c
> > > index 872d87ca6256..b4bdc3f3a946 100644
> > > --- a/drivers/iio/common/scmi_sensors/scmi_iio.c
> > > +++ b/drivers/iio/common/scmi_sensors/scmi_iio.c
> > > @@ -21,8 +21,10 @@
> > >
> > > #define SCMI_IIO_NUM_OF_AXIS 3
> > >
> > > +static const struct scmi_sensor_proto_ops *sensor_ops;
> >
> > Hmm. I'm not keen on globals when they really should not be necessary.
> > They just result in lifetimes being out of sync. Here you are fine because
> > you set it to an appropriate value as the first thing you do in probe, and
> > I assume the function only ever returns on answer on repeated calls.
> >
> > Why not put a copy of that pointer inside the struct scmi_iio_priv structures?
> >
>
> The reason for this, as I said to Jyoyi who made the same comment indeed,
> from my point of view (maybe wrong..) was that while the protocol_handle,
> and previously the handle, are 'per-instance data' (so that you get a
> different one each time this driver is possibly probed against a different
> platform-handle) and as such are stored in scmi_iio_priv, the _ops are
> just plain code pointers and are returned always the same for the same
> protocol no matter how many times you probe this driver:
As that's the case, I'm a little confused to why you have added the complexity
of a query interface in the first place? Why not just export the ops and
have the various drivers access them directly? If there is only
one set of scmi_sensor_ops etc, then let drivers at it directly, or
indeed export the functions that make up the ops structure directly.
This sounds like a bit of abstraction that only serves to make the
code harder to read.
> you just end up
> calling them against the proper different saved protocol_handle; so it
> seemed to me an unneeded duplication to stick a copy of the same _ops
> inside each per-instance scmi_iio_priv, and at the same time it seemed
> also more straigthforward to access them without too many indirections
> from inside the scmi_iio_priv struct).
>
> But if these are not valid points I can change this in IIO now, and in
> the future also in all the other SCMI drivers that currently use this
> same API and pattern of usage with global ops. (..at least because I'd
> have to collect again all the other ACks agains and it's a bit later for
> that now)
I'm fine with leaving it as is. There's no fundamental issue, it's just
a little bit ugly and I'm fussy :)
>
> Thanks
>
> Cristian
>
> > Otherwise this all looks like straight forward refactoring so given the
> > above is more a 'bad smell' than a bug and I'm rather late to the game.
> >
> > Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >
> >
> > > +
> > > struct scmi_iio_priv {
> > > - struct scmi_handle *handle;
> > > + struct scmi_protocol_handle *ph;
> > > const struct scmi_sensor_info *sensor_info;
> > > struct iio_dev *indio_dev;
> > > /* adding one additional channel for timestamp */
> > > @@ -82,7 +84,6 @@ static int scmi_iio_sensor_update_cb(struct notifier_block *nb,
> > > static int scmi_iio_buffer_preenable(struct iio_dev *iio_dev)
> > > {
> > > struct scmi_iio_priv *sensor = iio_priv(iio_dev);
> > > - u32 sensor_id = sensor->sensor_info->id;
> > > u32 sensor_config = 0;
> > > int err;
> > >
> > > @@ -92,27 +93,11 @@ static int scmi_iio_buffer_preenable(struct iio_dev *iio_dev)
> > >
> > > sensor_config |= FIELD_PREP(SCMI_SENS_CFG_SENSOR_ENABLED_MASK,
> > > SCMI_SENS_CFG_SENSOR_ENABLE);
> > > -
> > > - err = sensor->handle->notify_ops->register_event_notifier(sensor->handle,
> > > - SCMI_PROTOCOL_SENSOR, SCMI_EVENT_SENSOR_UPDATE,
> > > - &sensor_id, &sensor->sensor_update_nb);
> > > - if (err) {
> > > - dev_err(&iio_dev->dev,
> > > - "Error in registering sensor update notifier for sensor %s err %d",
> > > - sensor->sensor_info->name, err);
> > > - return err;
> > > - }
> > > -
> > > - err = sensor->handle->sensor_ops->config_set(sensor->handle,
> > > - sensor->sensor_info->id, sensor_config);
> > > - if (err) {
> > > - sensor->handle->notify_ops->unregister_event_notifier(sensor->handle,
> > > - SCMI_PROTOCOL_SENSOR,
> > > - SCMI_EVENT_SENSOR_UPDATE, &sensor_id,
> > > - &sensor->sensor_update_nb);
> > > + err = sensor_ops->config_set(sensor->ph, sensor->sensor_info->id,
> > > + sensor_config);
> > > + if (err)
> > > dev_err(&iio_dev->dev, "Error in enabling sensor %s err %d",
> > > sensor->sensor_info->name, err);
> > > - }
> > >
> > > return err;
> > > }
> > > @@ -120,25 +105,13 @@ static int scmi_iio_buffer_preenable(struct iio_dev *iio_dev)
> > > static int scmi_iio_buffer_postdisable(struct iio_dev *iio_dev)
> > > {
> > > struct scmi_iio_priv *sensor = iio_priv(iio_dev);
> > > - u32 sensor_id = sensor->sensor_info->id;
> > > u32 sensor_config = 0;
> > > int err;
> > >
> > > sensor_config |= FIELD_PREP(SCMI_SENS_CFG_SENSOR_ENABLED_MASK,
> > > SCMI_SENS_CFG_SENSOR_DISABLE);
> > > -
> > > - err = sensor->handle->notify_ops->unregister_event_notifier(sensor->handle,
> > > - SCMI_PROTOCOL_SENSOR, SCMI_EVENT_SENSOR_UPDATE,
> > > - &sensor_id, &sensor->sensor_update_nb);
> > > - if (err) {
> > > - dev_err(&iio_dev->dev,
> > > - "Error in unregistering sensor update notifier for sensor %s err %d",
> > > - sensor->sensor_info->name, err);
> > > - return err;
> > > - }
> > > -
> > > - err = sensor->handle->sensor_ops->config_set(sensor->handle, sensor_id,
> > > - sensor_config);
> > > + err = sensor_ops->config_set(sensor->ph, sensor->sensor_info->id,
> > > + sensor_config);
> > > if (err) {
> > > dev_err(&iio_dev->dev,
> > > "Error in disabling sensor %s with err %d",
> > > @@ -161,8 +134,8 @@ static int scmi_iio_set_odr_val(struct iio_dev *iio_dev, int val, int val2)
> > > u32 sensor_config;
> > > char buf[32];
> > >
> > > - int err = sensor->handle->sensor_ops->config_get(sensor->handle,
> > > - sensor->sensor_info->id, &sensor_config);
> > > + int err = sensor_ops->config_get(sensor->ph, sensor->sensor_info->id,
> > > + &sensor_config);
> > > if (err) {
> > > dev_err(&iio_dev->dev,
> > > "Error in getting sensor config for sensor %s err %d",
> > > @@ -208,8 +181,8 @@ static int scmi_iio_set_odr_val(struct iio_dev *iio_dev, int val, int val2)
> > > sensor_config |=
> > > FIELD_PREP(SCMI_SENS_CFG_ROUND_MASK, SCMI_SENS_CFG_ROUND_AUTO);
> > >
> > > - err = sensor->handle->sensor_ops->config_set(sensor->handle,
> > > - sensor->sensor_info->id, sensor_config);
> > > + err = sensor_ops->config_set(sensor->ph, sensor->sensor_info->id,
> > > + sensor_config);
> > > if (err)
> > > dev_err(&iio_dev->dev,
> > > "Error in setting sensor update interval for sensor %s value %u err %d",
> > > @@ -274,8 +247,8 @@ static int scmi_iio_get_odr_val(struct iio_dev *iio_dev, int *val, int *val2)
> > > u32 sensor_config;
> > > int mult;
> > >
> > > - int err = sensor->handle->sensor_ops->config_get(sensor->handle,
> > > - sensor->sensor_info->id, &sensor_config);
> > > + int err = sensor_ops->config_get(sensor->ph, sensor->sensor_info->id,
> > > + &sensor_config);
> > > if (err) {
> > > dev_err(&iio_dev->dev,
> > > "Error in getting sensor config for sensor %s err %d",
> > > @@ -542,15 +515,17 @@ static int scmi_iio_buffers_setup(struct iio_dev *scmi_iiodev)
> > > return 0;
> > > }
> > >
> > > -static struct iio_dev *scmi_alloc_iiodev(struct device *dev,
> > > - struct scmi_handle *handle,
> > > - const struct scmi_sensor_info *sensor_info)
> > > +static struct iio_dev *
> > > +scmi_alloc_iiodev(struct scmi_device *sdev, struct scmi_protocol_handle *ph,
> > > + const struct scmi_sensor_info *sensor_info)
> > > {
> > > struct iio_chan_spec *iio_channels;
> > > struct scmi_iio_priv *sensor;
> > > enum iio_modifier modifier;
> > > enum iio_chan_type type;
> > > struct iio_dev *iiodev;
> > > + struct device *dev = &sdev->dev;
> > > + const struct scmi_handle *handle = sdev->handle;
> > > int i, ret;
> > >
> > > iiodev = devm_iio_device_alloc(dev, sizeof(*sensor));
> > > @@ -560,7 +535,7 @@ static struct iio_dev *scmi_alloc_iiodev(struct device *dev,
> > > iiodev->modes = INDIO_DIRECT_MODE;
> > > iiodev->dev.parent = dev;
> > > sensor = iio_priv(iiodev);
> > > - sensor->handle = handle;
> > > + sensor->ph = ph;
> > > sensor->sensor_info = sensor_info;
> > > sensor->sensor_update_nb.notifier_call = scmi_iio_sensor_update_cb;
> > > sensor->indio_dev = iiodev;
> > > @@ -595,6 +570,17 @@ static struct iio_dev *scmi_alloc_iiodev(struct device *dev,
> > > sensor_info->axis[i].id);
> > > }
> > >
> > > + ret = handle->notify_ops->devm_event_notifier_register(sdev,
> > > + SCMI_PROTOCOL_SENSOR, SCMI_EVENT_SENSOR_UPDATE,
> > > + &sensor->sensor_info->id,
> > > + &sensor->sensor_update_nb);
> > > + if (ret) {
> > > + dev_err(&iiodev->dev,
> > > + "Error in registering sensor update notifier for sensor %s err %d",
> > > + sensor->sensor_info->name, ret);
> > > + return ERR_PTR(ret);
> > > + }
> > > +
> > > scmi_iio_set_timestamp_channel(&iio_channels[i], i);
> > > iiodev->channels = iio_channels;
> > > return iiodev;
> > > @@ -604,24 +590,29 @@ static int scmi_iio_dev_probe(struct scmi_device *sdev)
> > > {
> > > const struct scmi_sensor_info *sensor_info;
> > > struct scmi_handle *handle = sdev->handle;
> > > + struct scmi_protocol_handle *ph;
> > > struct device *dev = &sdev->dev;
> > > struct iio_dev *scmi_iio_dev;
> > > u16 nr_sensors;
> > > int err = -ENODEV, i;
> > >
> > > - if (!handle || !handle->sensor_ops) {
> > > + if (!handle)
> > > + return -ENODEV;
> > > +
> > > + sensor_ops = handle->devm_protocol_get(sdev, SCMI_PROTOCOL_SENSOR, &ph);
> > > + if (IS_ERR(sensor_ops)) {
> > > dev_err(dev, "SCMI device has no sensor interface\n");
> > > - return -EINVAL;
> > > + return PTR_ERR(sensor_ops);
> > > }
> > >
> > > - nr_sensors = handle->sensor_ops->count_get(handle);
> > > + nr_sensors = sensor_ops->count_get(ph);
> > > if (!nr_sensors) {
> > > dev_dbg(dev, "0 sensors found via SCMI bus\n");
> > > return -ENODEV;
> > > }
> > >
> > > for (i = 0; i < nr_sensors; i++) {
> > > - sensor_info = handle->sensor_ops->info_get(handle, i);
> > > + sensor_info = sensor_ops->info_get(ph, i);
> > > if (!sensor_info) {
> > > dev_err(dev, "SCMI sensor %d has missing info\n", i);
> > > return -EINVAL;
> > > @@ -636,7 +627,7 @@ static int scmi_iio_dev_probe(struct scmi_device *sdev)
> > > sensor_info->axis[0].type != RADIANS_SEC)
> > > continue;
> > >
> > > - scmi_iio_dev = scmi_alloc_iiodev(dev, handle, sensor_info);
> > > + scmi_iio_dev = scmi_alloc_iiodev(sdev, ph, sensor_info);
> > > if (IS_ERR(scmi_iio_dev)) {
> > > dev_err(dev,
> > > "failed to allocate IIO device for sensor %s: %ld\n",
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-03-30 17:37 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-16 12:48 [PATCH v7 00/38] SCMI vendor protocols and modularization Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 01/38] firmware: arm_scmi: review protocol registration interface Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 02/38] firmware: arm_scmi: introduce protocol handle definitions Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 03/38] firmware: arm_scmi: introduce devres get/put protocols operations Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 04/38] firmware: arm_scmi: make notifications aware of protocols users Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 05/38] firmware: arm_scmi: introduce new devres notification ops Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 06/38] firmware: arm_scmi: refactor events registration Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 07/38] firmware: arm_scmi: convert events registration to protocol handles Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 08/38] firmware: arm_scmi: add new protocol handle core xfer ops Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 09/38] firmware: arm_scmi: add helper to access revision area memory Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 10/38] firmware: arm_scmi: port Base protocol to new interface Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 11/38] firmware: arm_scmi: port Perf protocol to new protocols interface Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 12/38] cpufreq: scmi: port driver to the new scmi_perf_proto_ops interface Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 13/38] firmware: arm_scmi: remove legacy scmi_perf_ops protocol interface Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 14/38] firmware: arm_scmi: port Power protocol to new protocols interface Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 15/38] firmware: arm_scmi: port GenPD driver to the new scmi_power_proto_ops interface Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 16/38] firmware: arm_scmi: remove legacy scmi_power_ops protocol interface Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 17/38] firmware: arm_scmi: port Clock protocol to new protocols interface Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 18/38] clk: scmi: port driver to the new scmi_clk_proto_ops interface Cristian Marussi
2021-03-23 9:46 ` Sudeep Holla
2021-03-26 0:08 ` Stephen Boyd
2021-03-26 11:02 ` Cristian Marussi
2021-03-26 13:28 ` [PATCH v8 " Cristian Marussi
2021-03-26 18:15 ` Stephen Boyd
2021-03-16 12:48 ` [PATCH v7 19/38] firmware: arm_scmi: remove legacy scmi_clk_ops protocol interface Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 20/38] firmware: arm_scmi: port Reset protocol to new protocols interface Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 21/38] reset: reset-scmi: port driver to the new scmi_reset_proto_ops interface Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 22/38] firmware: arm_scmi: remove legacy scmi_reset_ops protocol interface Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 23/38] firmware: arm_scmi: port Sensor protocol to new protocols interface Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 24/38] hwmon: (scmi) port driver to the new scmi_sensor_proto_ops interface Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 25/38] iio/scmi: " Cristian Marussi
2021-03-16 17:51 ` Jyoti Bhayana
2021-03-16 22:22 ` Cristian Marussi
2021-03-17 5:38 ` Jyoti Bhayana
2021-03-18 12:12 ` Sudeep Holla
2021-03-19 17:00 ` Jyoti Bhayana
2021-03-23 9:48 ` Sudeep Holla
2021-03-30 11:22 ` Jonathan Cameron
2021-03-30 11:33 ` Jonathan Cameron
2021-03-30 12:51 ` Cristian Marussi
2021-03-30 17:34 ` Jonathan Cameron [this message]
2021-03-31 8:32 ` Cristian Marussi
2021-03-31 12:28 ` Jonathan Cameron
2021-03-30 13:47 ` [PATCH v8 25/38] iio/scmi: Port " Cristian Marussi
2021-03-30 17:40 ` Jonathan Cameron
2021-03-16 12:48 ` [PATCH v7 26/38] firmware: arm_scmi: remove legacy scmi_sensor_ops protocol interface Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 27/38] firmware: arm_scmi: port SystemPower protocol to new protocols interface Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 28/38] firmware: arm_scmi: port Voltage " Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 29/38] regulator: scmi: port driver to the new scmi_voltage_proto_ops interface Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 30/38] firmware: arm_scmi: remove legacy scmi_voltage_ops protocol interface Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 31/38] firmware: arm_scmi: make references to handle const Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 32/38] firmware: arm_scmi: cleanup legacy protocol init code Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 33/38] firmware: arm_scmi: cleanup unused core xfer wrappers Cristian Marussi
2021-03-16 12:48 ` [PATCH v7 34/38] firmware: arm_scmi: cleanup events registration transient code Cristian Marussi
2021-03-16 12:49 ` [PATCH v7 35/38] firmware: arm_scmi: make notify_priv really private Cristian Marussi
2021-03-16 12:49 ` [PATCH v7 36/38] firmware: arm_scmi: rename non devres notify_ops Cristian Marussi
2021-03-16 12:49 ` [PATCH v7 37/38] firmware: arm_scmi: add protocol modularization support Cristian Marussi
2021-03-16 12:49 ` [PATCH v7 38/38] firmware: arm_scmi: add dynamic scmi devices creation Cristian Marussi
2021-03-26 4:09 ` [PATCH v7 00/38] SCMI vendor protocols and modularization Florian Fainelli
2021-03-26 11:04 ` Cristian Marussi
2021-03-31 8:22 ` Sudeep Holla
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=20210330183404.00001909@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=cristian.marussi@arm.com \
--cc=etienne.carriere@linaro.org \
--cc=f.fainelli@gmail.com \
--cc=james.quinlan@broadcom.com \
--cc=jbhayana@google.com \
--cc=jic23@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=souvik.chakravarty@arm.com \
--cc=sudeep.holla@arm.com \
--cc=thara.gopinath@linaro.org \
--cc=vincent.guittot@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).