linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
To: Fabien Lahoudere <fabien.lahoudere@collabora.com>
Cc: linux-iio@vger.kernel.org
Subject: Re: [RFC 0/1] Add new sysfs ABI for chromebook devices
Date: Sun, 5 May 2019 16:32:55 +0100	[thread overview]
Message-ID: <20190505163255.41c25c67@archlinux> (raw)
In-Reply-To: <cover.1556873525.git.fabien.lahoudere@collabora.com>

On Fri,  3 May 2019 12:54:45 +0200
Fabien Lahoudere <fabien.lahoudere@collabora.com> wrote:

> Chromebooks embedded controller (EC) provides new field in the 3rd version of 
> its protocol. Those values need to be exposed as sysfs entries.
> 
> Minimum and maximum frequencies may probably be a standard iio ABI.
> There is an existing ABI (sampling_frequency_available) but only for discrete 
> set of values.
> We have different possible solution and I want to ask interested people for the 
> best one:
> 1. we keep the ABI proposed in this RFC (in the chromebook specific code)
> 2. we move min and max freq as 2 different standard ABI
> 3. we add a new standard iio ABI to set a range (sampling_frequency_range)
> 4. we change the 'sampling_frequency_available' ABI to return discrete values 
> like '2 4 6 8' or a range like '[2 - 8]'
> 5. the solution I didn't think about
Gah, it's been on my todo list for far too long to put out proper docs for
it but we do have a way of doing this in IIO.

Best bet is too look at the code in
industrialio-core.c for iio_read_channel_info_avail, and specifically
iio_format_avail_range

That produces strings of the format [MIN STEP MAX] so more or less your
option 4, with the [] syntax indicating to userspace that it's a range
version.

We did this a while back to provide a single interface for consumer drivers
and for userspace.  If you poke around in the period around when that
patch was merged you'll find a discussion which was pretty much the
options you have above.

Note if anyone else wants to have a go at docs for this feature I would
definitely welcome it!

Jonathan

> 
> Thanks
> 
> Gwendal Grignou (1):
>   iio: common: cros_ec_sensors: add extra sensor API
> 
>  .../ABI/testing/sysfs-bus-iio-cros-ec         |  24 ++++
>  .../cros_ec_sensors/cros_ec_sensors_core.c    | 126 +++++++++++++++++-
>  .../linux/iio/common/cros_ec_sensors_core.h   |   7 +
>  include/linux/mfd/cros_ec_commands.h          |  21 +++
>  4 files changed, 177 insertions(+), 1 deletion(-)
> 


      parent reply	other threads:[~2019-05-05 15:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-03 10:54 [RFC 0/1] Add new sysfs ABI for chromebook devices Fabien Lahoudere
2019-05-03 10:54 ` [RFC 1/1] iio: common: cros_ec_sensors: add extra sensor API Fabien Lahoudere
2019-05-05 15:36   ` Jonathan Cameron
2019-05-25  0:28     ` Gwendal Grignou
2019-05-27  9:18       ` Jonathan Cameron
2019-05-30  4:28         ` Gwendal Grignou
2019-05-05 15:32 ` Jonathan Cameron [this message]

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=20190505163255.41c25c67@archlinux \
    --to=jic23@jic23.retrosnub.co.uk \
    --cc=fabien.lahoudere@collabora.com \
    --cc=linux-iio@vger.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 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).