linux-kernel - Re: [PATCH] drivers: create a pin control subsystem v8

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: <CACRpkdZ6DCeELLhiXF=oOMKB-DxeMuvbd_c6n4H1UDMhpHKZbA@mail.gmail.com>
Date:	Mon, 24 Oct 2011 09:48:19 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Mike Frysinger <vapier.adi@...il.com>,
	Linus Walleij <linus.ml.walleij@...il.com>,
	Stephen Warren <swarren@...dia.com>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Barry Song <21cnbao@...il.com>, linux-kernel@...r.kernel.org,
	Joe Perches <joe@...ches.com>,
	Russell King <linux@....linux.org.uk>,
	Linaro Dev <linaro-dev@...ts.linaro.org>,
	Lee Jones <lee.jones@...aro.org>,
	David Brown <davidb@...eaurora.org>,
	linux-arm-kernel@...ts.infradead.org,
	Stijn Devriendt <highguy@...il.com>
Subject: Re: [PATCH] drivers: create a pin control subsystem v8

On Mon, Oct 24, 2011 at 9:36 AM, Grant Likely <grant.likely@...retlab.ca> wrote:
> On Mon, Oct 24, 2011 at 09:26:38AM +0200, Linus Walleij wrote:
(...)
>> I was more thinking along the lines of one device per GPIO controller,
>> then you ioctl() to ask /dev/gpio0 how many pins it has or so.
>
> And there is also the question of whether it is even a good idea to
> export pinctrl manipulation to userspace.

The application I've seen is in automatic control.

I think people do things like connect they GPIO pins to electrical
relays, plus on top of that they use all the stuff in drivers/staging/iio.

All that from userspace. Controlling entire factories and industrial
robots, weapon systems too, I'm afraid.

The control of these dangerous things runs on a realtime-patched
kernel, in a single userspace app with a few threads and they have
done some realtime-tetris scheduling the beast more or less
manually with SCHED_FIFO. Basically that app is all that runs on
the board, and its threads take precedence over everything else
on the system.

That is the typical beast that is poking around on the GPIO sysfs
interfaces...

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/