linux-kernel - [PATCH RFC] 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-next>] [day] [month] [year] [list]

Date:	Tue, 11 Oct 2011 12:43:02 +0100
From:	Jonathan Cameron <jic23@....ac.uk>
To:	linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org
Cc:	broonie@...nsource.wolfsonmicro.com, zdevai@...il.com,
	linus.walleij@...aro.org, Jonathan Cameron <jic23@....ac.uk>
Subject: [PATCH RFC] IIO: Proof of concept in kernel interface.

Hi All,

Given I keep blithely stating it would be easy to add an in kernel
interface to IIO, I thought I'd better actually prove it.

There are numerous holes / questions raised by this example.

1) We need a foolproof way of getting the right instance of
a given device.  This PoC does it by part name (unique on my
test board but far from it in general).
The snag as ever is the complexity of getting a reliable reference
to an i2c or spi part.  Basically it's the same problem fudged
over in the regulator framework.

2) Callbacks for triggered read.  Not done here and given the flexibility
of IIO triggers it's not obvious how to do it.  Most other subsystems
pretty much assume they will get a stream of data and do not control
what causes it to appear.  With IIO I we'll either need in kernel control
of this (fiddly as it really isn't that generalizable), assume
sane default settings or have a userspace daemon to set it up.

3) How much hand holding to do.  Right now it gives raw access to the device,
equivalent to what the IIO core has.  Is it worth doing error checking utility
functions such as

int iio_consumer_read_data(struct iio_dev *indio_dev, int channel, enum iio_type type);
which would do stuff like verify the channel exists and that it
is the right sort of channel. Can also use this to 'hide' the
struct iio_dev etc from the consumer drivers.

If people are happy with the general form and we nail the
association problem, I'll write a general hwmon interface
to do simple hardware monitoring from an adc channel.
For now I'd keep it completely trivial and avoid events etc.

So comments welcome,

This sits on a couple of patches that haven't gone upstream yet, so
best bet is probably

https://github.com/jic23/linux-iio/tree/inkern

which also has the dummy driver for anyone who wants to play
and doesn't have hardware.

Jonathan Cameron (1):
  staging:iio:proof of concept in kernel interface.

 drivers/staging/iio/Kconfig             |    5 ++++
 drivers/staging/iio/Makefile            |    3 ++
 drivers/staging/iio/iio.h               |    5 ++++
 drivers/staging/iio/industrialio-core.c |   38 ++++++++++++++++++++++++++++
 drivers/staging/iio/inkern.c            |   41 +++++++++++++++++++++++++++++++
 5 files changed, 92 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/iio/inkern.c

-- 
1.7.3.4

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