linux-kernel - Re: IIO comments

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]

Message-Id: <201103181718.08502.arnd@arndb.de>
Date:	Fri, 18 Mar 2011 17:18:08 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Jonathan Cameron <jic23@....ac.uk>
Cc:	Kay Sievers <kay.sievers@...y.org>, linux-iio@...r.kernel.org,
	linux-kernel@...r.kernel.org, Greg KH <greg@...ah.com>,
	Jean Delvare <khali@...ux-fr.org>,
	Guenter Roeck <guenter.roeck@...csson.com>
Subject: Re: IIO comments

On Friday 18 March 2011, Jonathan Cameron wrote:
> On 03/18/11 12:47, Arnd Bergmann wrote:
> > On Thursday 17 March 2011, Jonathan Cameron wrote:
> >> On 03/17/11 17:51, Arnd Bergmann wrote:
> >>> I don't completely understand the notation. Regarding the various
> >>> {in0, in1, in2, ...} inputs, is there a fundamental difference between
> >>> them? In the code example I gave, a driver would simply list
> >>> a set of inputs of the same type (IIO_CHAN_IN) and let the core
> >>> enumerate them. What does "in0-in1" mean?
> >>
> >> in0-in1 is a differential adc channel. Literally outputs value on
> >> physical pin 1 subtracted from physical pin 2.
> > 
> > Ok, I see. So these would be fairly hard to enumerate, right?
> > Would it be possible to have one attribute with named "diff%d"
> > and another attribute associated with it that describes which
> > channels are compared?
>
> Could do, but what would it gain us?  If the information is available
> to the core, then it can use it give us the explicit naming? As shown
> below we have to handle holes in the enumeration anyway so this isn't
> to much of a problem.

Maybe I was seeing problems that don't exist here. Wouldn't
you need to numeric identifiers to describe a differential
channel?

I guess if it's always in${i}-in${i+1}, it's still not too hard.

> >>> Ok. I truely hope that most hardware has something like this, but
> >>> we can probably work around it as explained above if not.
> >>
> >> Yes. Though do beware. spi and i2c buses for some of these things
> >> can be 'very' slow and often congested on the actual boards. Hence
> >> we sometimes spend a lot of effort to avoid transactions.
> > 
> > Do the transactions require spinning on the CPU, or do they
> > always  work in the background when they are slow?
> If you have a proper controller it's often DMA based. So the issue
> is more congestion on the bus limiting possible sampling rates than
> cpu load. To a certain extent we can just ignore this issue as long
> as we are open to changes to a driver to minimise bus usage if someone
> has a use case that actually requires it for a given device.

Ok.

	Arnd
--
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/