linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@cam.ac.uk>
To: Peter Meerwald <pmeerw@pmeerw.net>
Cc: Jonathan Cameron <jic23@kernel.org>, linux-iio@vger.kernel.org
Subject: Re: iio: vcnl4000 ALS/proximity driver
Date: Tue, 12 Jun 2012 12:01:33 +0100	[thread overview]
Message-ID: <4FD7218D.3080506@cam.ac.uk> (raw)
In-Reply-To: <alpine.DEB.2.01.1206121022210.23868@pmeerw.net>

On 6/12/2012 10:48 AM, Peter Meerwald wrote:
> Hello,
>
>>>> Am I missing documentation somewhere?
>>>>
>>> Documentation/ABI/testing/sysfs-bus-iio.
>> + drivers/staging/iio/documentation/sysfs-* for other bits and bobs. Mostly it
>> should be fairly obvious how stuff lines up.
>
> well, the last statement should be up to the user of the documentation,
> not the creator ;)
True enough.
>
>>>> some comments in iio/types.h iio/iio.h would avoid guesswork...
>> ah, there were.  That comment is out of date.  This sort of thing is why
>> we try to keep minimal commenting in there unless absolutely necessary.
>
> is the What: line in sysfs-bus-iio supposed to be comprehensive?
Yes.  All sysfs entries should be documented.
If a specific varient of a general element should be in sysfs-bus-iio
If class specific (e.g. only make sense for light sensors) should be
in sysfs-bus-iio-light etc. If device specific (and these take a fair
bit of persuation to be let in) should be in sysfs-bus-iio-light-tsl2563 
etc.
>
> I am worried because concepts are explained redundantly in sysfs-bus-iio
> for particular channel types; one such concept is that a raw
> value can/shall be modified by userspace by offset and scale
Good to clean those up, but they must be documented in those file.  It's
pretty much a kernel rule. Those docs are for writers of userspace code
as well. They shouldn't have to go dig in headers to find this stuff out.
>
> this could be easily (?) done near the iio_chan_info_enum definition in
> iio.h

it would be nice to do it there, but the abi docs are the definitive source.
>
> sysfs-bus-iio documents what you might see in the wild but not how to
> get there
true.
>
>> I suppose we could put a reference to say see the docs files...
>
> I have seen the doc, but I find it hard to deduce the concepts from a
> collection of sysfs file names
>
> it is not clear/obvious how to arrive at
> /sys/.../iio:deviceX/in_capacitanceY-in_capacitanceZ_raw or
Nice complex case...
> /sys/bus/iio/devices/iio:deviceX/out_voltageY&Z_raw
err. that's curious. You can't set that...  Goes to show I should review
changes to this file more carefully. I just shouted down adding the 
stuff that would provide that precisely because it made no sense.
>
> in iio.h:
>   * @channel:		What number or name do we wish to assign the channel.
>
> what is meant by 'name' here?
Oops. Comment has rotted.  Drop the name bit if you fancy doing a patch.
>
> so channel is a numerical identifier that is appended to the channel name
> if indexed is 1?
yes.
>
> * @indexed:		Specify the channel has a numerical index. If not,
>   *			the value in channel will be suppressed for attribute
>   *			but not for event codes. Typically set it to 0 when
>   *			the index is false.
>
> I am not sure what an 'attribute code' is (sysfs name?)
attribute name  (which is just a sysfs name as you call it) Again,
could do with fixing.
> I am not sure what 'index is false' means
index  == 0; Oops, more good points. Thanks!

Given you are doing an excellent job, feel free to send patches.
>
>
> regards, p.
>

  reply	other threads:[~2012-06-12 11:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-10 22:39 iio: vcnl4000 ALS/proximity driver Peter Meerwald
2012-06-10 22:39 ` [PATCH] iio: add vcnl4000 combined ALS and proximity sensor Peter Meerwald
2012-06-11 11:13   ` Lars-Peter Clausen
2012-06-11 18:13   ` Jonathan Cameron
2012-06-11 18:14 ` iio: vcnl4000 ALS/proximity driver Jonathan Cameron
2012-06-11 21:35   ` Peter Meerwald
2012-06-12  5:49     ` Jonathan Cameron
2012-06-12  7:49       ` Jonathan Cameron
2012-06-12  9:48         ` Peter Meerwald
2012-06-12 11:01           ` Jonathan Cameron [this message]
2012-06-12 11:04             ` Jonathan Cameron
2012-06-12 12:12             ` Peter Meerwald
2012-06-12 12:20               ` Jonathan Cameron

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=4FD7218D.3080506@cam.ac.uk \
    --to=jic23@cam.ac.uk \
    --cc=jic23@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=pmeerw@pmeerw.net \
    /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).