All of lore.kernel.org
 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 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.