linux-kernel - Re: [PATCH] iio: adc: Add bindigs documentation for twl6030 GPADC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 20 Aug 2013 08:34:56 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Mark Rutland <mark.rutland@....com>
Cc:	Oleksandr Kozaruk <oleksandr.kozaruk@...com>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"rob@...dley.net" <rob@...dley.net>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jonathan Cameron <jic23@...nel.org>
Subject: Re: [PATCH] iio: adc: Add bindigs documentation for twl6030 GPADC

On Tue, Aug 20, 2013 at 10:12:28AM +0100, Mark Rutland wrote:
> Hi Oleksandr,
> 
> [Adding Jonathan Cameron and Guenter Roeck to Cc]
> 
> Apologies for the delay replying to this. In attempting to verify this
> made sense I went and read the IIO bindings documentation, and I'm
> somewhat confused by the model.
> 
> As far as I can see, the only consumer of IIO channels is the
> "iio-hwmon" binding, which seems to be a binding for Linux-specific
> infrastructure rather than any actual device. This runs counter to the

In respect to "iio-hwmon", I think you may actually be correct; we should
have found a better means to describe the system.
The intend was to describe that a set of adc inputs is connected
to a set of voltages or temperature sensors.

Is there a better way ? I am sure there is, but I have no idea what
it might be, nor do I have the time to find out.

However, I think that the "io-channels" property is well defined.

"gpios" describes a group of gpio pins which have a common purpose.
"io-channels" describes a group of io channels (or, ultimately, pins)
which have a common purpose. So this is not really linux specific,
unless other operating systems don't see the need of describing a group
of io channels as single entity. But then the same could be claimed
about groups of gpio pins.

> way DT is supposed to function (describing the hardware rather than how
> it's used). As far as I can see, this linkage is described because only
> a subset of the ADCs on the device are actually wired to something?
> 
Is that a problem ? I would think that the same is true for many chips
with multiple inputs and/or outputs.

> I also see a couple of IIO bindings ("adi,adf435x*, and "adi,ad7303")
> which don't describe any iio channel cells at all, so I'm somewhat
> confused by what the IIO channels actually represent, and why they must
> be consumed elsewhere. As far as I can see, an IIO channel represents a
> single ADC's registers in an IIO device, so I'm not sure why this must
> be exported via the channel concept -- it's not physically wired.
> 
I am sure there would be some other means to describe the same,
so I would agree that it does not _have_ to be the way it is.

Question is if there is a better way. Again, "io-channels" describes
a group of io channels with a common purpose. Sure, that does not _have_
to be described as a single property, but then I could argue that the same
is true for "gpios" and probably many other properties.

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/