linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Cristian Marussi <cristian.marussi@arm.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: Jyoti Bhayana <jbhayana@google.com>,
	Hartmut Knaack <knaack.h@gmx.de>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Rob Herring <robh@kernel.org>,
	Lukas Bulwahn <lukas.bulwahn@gmail.com>,
	linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
	sudeep.holla@arm.com, egranata@google.com,
	mikhail.golubev@opensynergy.com, Igor.Skalkin@opensynergy.com,
	Peter.hilber@opensynergy.com, ankitarora@google.com
Subject: Re: [RFC PATCH v4 1/1] iio/scmi: Adding support for IIO SCMI Based Sensors
Date: Sun, 31 Jan 2021 20:42:20 +0000	[thread overview]
Message-ID: <20210131204220.GB8355@e120937-lin> (raw)
In-Reply-To: <20210131131141.468f1cc2@archlinux>

Hi

a clarification down below regarding something I pointed out in the
other thread (just to be sure I have not pointed out something
plain wrong :D)

Thanks

Cristian

On Sun, Jan 31, 2021 at 01:11:41PM +0000, Jonathan Cameron wrote:
> On Fri, 29 Jan 2021 22:18:18 +0000
> Jyoti Bhayana <jbhayana@google.com> wrote:
> 
> > This change provides ARM SCMI Protocol based IIO device.
> > This driver provides support for Accelerometer and Gyroscope using
> > SCMI Sensor Protocol extensions added in the SCMIv3.0 ARM specification
> > 
> > Signed-off-by: Jyoti Bhayana <jbhayana@google.com>
> 
> A few minor things noticed on a fresh read through, but mostly I think
> we are down to figuring out how to deal with the range (as discussed
> in the thread continuing on v3).
> 
> On another note, probably time to drop the RFC or give a bit more detail
> on why you think this isn't ready to be applied.
> 
> Thanks,
> 
> Jonathan
> 
[snip]

> > +
> > +static int scmi_iio_dev_probe(struct scmi_device *sdev)
> > +{
> > +	const struct scmi_sensor_info *sensor_info;
> > +	struct scmi_handle *handle = sdev->handle;
> > +	struct device *dev = &sdev->dev;
> > +	struct iio_dev *scmi_iio_dev;
> > +	u16 nr_sensors;
> > +	int err, i;
> > +
> > +	if (!handle || !handle->sensor_ops) {
> > +		dev_err(dev, "SCMI device has no sensor interface\n");
> I'm going to guess we can't actually get here because the registration
> would't have happened if either of those are true?
> If so perhaps drop the error message.
> 
> > +		return -EINVAL;
> > +	}
> > +
> > +	nr_sensors = handle->sensor_ops->count_get(handle);
> > +	if (!nr_sensors) {
> > +		dev_dbg(dev, "0 sensors found via SCMI bus\n");
> -ENODEV maybe?
> > +		return -EINVAL;
> > +	}
> > +
> > +	dev_dbg(dev, "%d sensors found via SCMI bus\n", nr_sensors);
> 
> Clear out any debug prints out that don't provide info that can't be obtained
> farily easily from elsewhere.  In this case they will either be registered
> or not and we'll get error messages.
> These sort of prints bitrot over time so we want to limit them to the truely
> useful.
> 
> > +
> > +	for (i = 0; i < nr_sensors; i++) {
> > +		sensor_info = handle->sensor_ops->info_get(handle, i);
> > +		if (!sensor_info) {
> > +			dev_err(dev, "SCMI sensor %d has missing info\n", i);
> > +			return -EINVAL;
> > +		}
> > +
> > +		/* Skipping scalar sensor,as this driver only supports accel and gyro */
> > +		if (sensor_info->num_axis == 0)
> > +			continue;
> 
> So there is a situation where this driver never creates anything?  In that path I'd
> like to see an -ENODEV error return.
> 
You mean -ENODEV only if this driver does not find at least one
good/supported GYRO/ACCEL sensor right ?

I would expect a system to possibly expose a bunch of other SCMI sensors
maybe unsupported by this IIO driver but currently handled by other
drivers, as an example on JUNO a number of temps/volts/currents sensors
are exposed and handled by the SCMI hwmon driver.


> > +
> > +		err = scmi_alloc_iiodev(dev, handle, sensor_info,
> > +					&scmi_iio_dev);
> > +		if (err < 0) {
> > +			dev_err(dev,
> > +				"failed to allocate IIO device for sensor %s: %d\n",
> > +				sensor_info->name, err);
> > +			return err;
> > +		}
> > +
> > +		err = scmi_iio_buffers_setup(scmi_iio_dev);
> > +		if (err < 0) {
> > +			dev_err(dev,
> > +				"IIO buffer setup error at sensor %s: %d\n",
> > +				sensor_info->name, err);
> > +			return err;
> > +		}
> > +
> > +		err = devm_iio_device_register(dev, scmi_iio_dev);
> > +		if (err) {
> > +			dev_err(dev,
> > +				"IIO device registration failed at sensor %s: %d\n",
> > +				sensor_info->name, err);
> > +			return err;
> > +		}
> > +	}
> > +	return err;
> > +}
> > +
> > +static const struct scmi_device_id scmi_id_table[] = {
> > +	{ SCMI_PROTOCOL_SENSOR, "iiodev" },
> 
> I'm curious on this.  What actually causes a match on that
> iiodev?  From digging around the scmi core am I right in thinking
> that this iiodev id needs to be explicitly listed?
> 
> It would be good to include any changes needed there in this
> series.
> 
> > +	{},
> > +};
> > +
> > +MODULE_DEVICE_TABLE(scmi, scmi_id_table);
> > +
> > +static struct scmi_driver scmi_iiodev_driver = {
> > +	.name = "scmi-sensor-iiodev",
> > +	.probe = scmi_iio_dev_probe,
> > +	.id_table = scmi_id_table,
> > +};
> > +
> > +module_scmi_driver(scmi_iiodev_driver);
> > +
> > +MODULE_AUTHOR("Jyoti Bhayana <jbhayana@google.com>");
> > +MODULE_DESCRIPTION("SCMI IIO Driver");
> > +MODULE_LICENSE("GPL v2");
> 

  reply	other threads:[~2021-01-31 20:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-29 22:18 [RFC PATCH v4 0/1] Adding support for IIO SCMI based sensors Jyoti Bhayana
2021-01-29 22:18 ` [RFC PATCH v4 1/1] iio/scmi: Adding support for IIO SCMI Based Sensors Jyoti Bhayana
2021-01-31 13:11   ` Jonathan Cameron
2021-01-31 20:42     ` Cristian Marussi [this message]
2021-02-01 14:36       ` Jonathan Cameron
2021-02-02  6:53     ` Jyoti Bhayana
2021-02-04 16:59       ` Jonathan Cameron
     [not found]         ` <CA+=V6c0_km3o5gdftePfjoHZimZtOU041fbguNSyXN0wu-hd6A@mail.gmail.com>
2021-02-05 12:31           ` Jonathan Cameron
     [not found]             ` <CA+=V6c1NzkpM0vU8o_bM=Q5zEcYqweCQ+S8xsnQ_uF_Q2A=2_A@mail.gmail.com>
2021-02-06 14:35               ` Jonathan Cameron
2021-01-31 20:31   ` Cristian Marussi

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=20210131204220.GB8355@e120937-lin \
    --to=cristian.marussi@arm.com \
    --cc=Igor.Skalkin@opensynergy.com \
    --cc=Peter.hilber@opensynergy.com \
    --cc=ankitarora@google.com \
    --cc=davem@davemloft.net \
    --cc=egranata@google.com \
    --cc=jbhayana@google.com \
    --cc=jic23@kernel.org \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas.bulwahn@gmail.com \
    --cc=mchehab+huawei@kernel.org \
    --cc=mikhail.golubev@opensynergy.com \
    --cc=pmeerw@pmeerw.net \
    --cc=robh@kernel.org \
    --cc=sudeep.holla@arm.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;
as well as URLs for NNTP newsgroup(s).