linux-kernel - Re: [PATCH] staging:iio:proof of concept in kernel interface.

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:	Mon, 17 Oct 2011 15:55:05 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Jonathan Cameron <jic23@....ac.uk>
Cc:	Linus Walleij <linus.ml.walleij@...il.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org,
	zdevai@...il.com
Subject: Re: [PATCH] staging:iio:proof of concept in kernel interface.

On Mon, Oct 17, 2011 at 11:43 AM, Jonathan Cameron <jic23@....ac.uk> wrote:

> Thanks for this Linus. It is more or less where I was heading with one
> exception.  I was going to link whole physical devices whereas I think
> you are proposing linking individual channels.

That's for the usecases I have at hand, I don't know which is more
common: grab the entire device and pick a few channels or grab
a single channel. I was thinking the latter would be most common
for in-kernel use.

If you need some inspiring code for how to handle registration of
mapping tables etc you can look at the API I'm pushing for the
pin control subsystem:
http://marc.info/?l=linux-kernel&m=131850357826490&w=2

> For the adc channel I'm not particularly keen on insisting every device
> have a unique name for every channel.  That breaks the effort we went to
> in IIO to enforce consistent naming (for userspace interfaces) in the first
> place.  To my mind it should never be anything other than a number.

Doesn't feel like a big issue, plain numbers are fine for me.

I was more thinking along the line that in an embedded system an
on-system-in-chip GPADC sure has specific set-in-stone uses for
each channel, i.e. the pin it connects to is hardwired somewhere,
like channel 0 is "battery-voltage", pin 1 is "battery-temperature"
etc, which makes string descriptions make sense.

It doesn't make sense for an ADC card with 100 ADC:s for random
measurements, of course.

> struct adc_map {
> /* Input / output side */
>        struct device *adc_dev;
>        const char *adc_dev_name;
>        int channel_number;
> /* User side */
>        const char *channel;
>        struct device *dev;
>        const char *dev_name;
> };

OK that makes sense.

> Anyhow, I'll have a go at implementing this over the next few days.  Before I
> do that I am going to push out the proposal to move the core IIO infrastructure
> out of staging.

Good, my gut feeling is that right now it hurts the kernel more to
have IIO in staging than it could ever hurt it to have it in drivers/,
it is getting badly needed.

Yours,
Linus Walleij
--
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/