linux-kernel - Re: GPIOLIB, GPIO_SYS and port-wide accesses

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] [day] [month] [year] [list]

Date:	Fri, 14 Aug 2009 18:11:52 +1000
From:	Ben Nizette <bn@...sdigital.com>
To:	John Williams <john.williams@...alogix.com>
Cc:	Linux Kernel list <linux-kernel@...r.kernel.org>,
	John Linn <John.Linn@...inx.com>,
	Stephen Neuendorffer <stephen.neuendorffer@...inx.com>,
	David DeBonis <david.debonis@...inx.com>,
	Michal Simek <michal.simek@...alogix.com>,
	Grant Likely <grant.likely@...retlab.ca>
Subject: Re: GPIOLIB, GPIO_SYS and port-wide accesses

On Fri, 2009-08-14 at 10:01 +1000, John Williams wrote:
> Did anything ever come of that?

Nothing ever did, though others keep half-heartedly implementing the
same thing every few months.  They seem to disappear before it's
accepted though.

> 
> Per-bit access is pretty inflexible if you are driving a 7-segment
> display or 8-LED bar display, holding lots of file descriptors open
> etc, and lots of syscall overhead.
> 
> sysfs syntax like
> 
> $ echo "240-247" > export
> $ echo 255 > gpio240-247/direction  (8-bit binary mask - output)
> $ echo 255 > gpio240-247/value (all ones)
> 

The first line, to some eyes, would violate the one-value-per-attribute
thing sysfs insists on, but sure there are ways to do this.

> would be reasonably friendly, obviously the underlying gpiolib would
> have to have some notion of coupled ports.

The main stumbling block is that implementers forget that gpiolib is
just one implementation of the gpio api - any solution should

1) define accessor functions for multiple bits in the gpio api
2) implement these in gpiolib and other gpio api implementations (I
think the other implementations at the moment are all just stubs anyway)
3) Get gpiolib to bunt requests to the gpiochip
4) Write support for each gpiochip which has this functionality

The other stumbling block is that this all depends on bitmasks of some
kind or other but there's no good reason to nail this to any particular
word size.  Sure most are 8- or 32-bit banks but we have to deal with
the weird ones too.  In particular, I've seen FPGA-implemented gpio
controllers with banks of many hundred GPIO.  Accommodating those will
take an amount of bit-fu.

Anyway, if anyone out there has the patience to stick around until a
solution is correct we'll get something useful for all I'm sure.

	--Ben.

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