linux-kernel - Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 30 Nov 2011 14:28:36 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Greg KH <gregkh@...e.de>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	NeilBrown <neilb@...e.de>, Arnd Bergmann <arnd@...db.de>,
	myungjoo.ham@...il.com, linux-kernel@...r.kernel.org,
	Mike Lockwood <lockwood@...roid.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Donggeun Kim <dg77.kim@...sung.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Kalle Komierowski <karl.komierowski@...ricsson.com>,
	Johan PALSSON <johan.palsson@...ricsson.com>,
	Daniel WILLERUD <daniel.willerud@...ricsson.com>
Subject: Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

On Wed, Nov 30, 2011 at 7:35 AM, Greg KH <gregkh@...e.de> wrote:

> So, how do you want this type of interface to look like, uevents only?
>
> Or something like gpio?
>
> Actually, why can't we just use gpio as-is here and just treat these
> devices as "generic" i/o "pins"?

For device drivers we have the issue that the management of
the GPIO pin-space give me the creeps. It is simple when things
are simple and then ugly things have start to happen, such
as dynamically bumping the GPIO pin range and associated
IRQ range at compile time using unreadable nested macros.
You roof the space at some arbitrary number at compile-time
in ARCH_NR_GPIOS and if you don't define it,
<asm-generic/gpio.h> will helpfully define that your system
has 256 GPIO pins.

The effect of the above on unified cross-ARM-arch kernels is
confusing as the meaning of the GPIO pinspace will
shift at runtime depending on what system it's running on.

A new subsystem could allocate switch/pin/line assignments
dynamically which is way more viable. (And how we chose to
do in in pinctrl.)

For userspace several people, notably the GPIOlib subsystem
maintainer Grant, expressed concerns about the sysfs interface
to GPIO. So I would not shoehorn new stuff in there, solidifying
it even more.

So I would recommend doing this as a new subsystem to save
us from trouble. There is more to be gained from splitting things
apart than keeping them together in this case IMO.

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/