linux-kernel - Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins

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:	Tue, 30 Dec 2008 00:20:23 +0000
From:	Jamie Lokier <jamie@...reable.org>
To:	David Brownell <david-b@...bell.net>
Cc:	Robin Getz <rgetz@...ckfin.uclinux.org>,
	Jaya Kumar <jayakumar.lkml@...il.com>,
	Eric Miao <eric.y.miao@...il.com>,
	Sam Ravnborg <sam@...nborg.org>,
	Eric Miao <eric.miao@...vell.com>,
	Haavard Skinnemoen <hskinnemoen@...el.com>,
	Philipp Zabel <philipp.zabel@...il.com>,
	Russell King <rmk@....linux.org.uk>,
	Ben Gardner <bgardner@...tec.com>, Greg KH <greg@...ah.com>,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	linux-fbdev-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, linux-embedded@...r.kernel.org
Subject: Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins

David Brownell wrote:
> The reason single-bit operations don't provide error paths is twofold.
> First, they started as wrappers for can't-fail register accessors.
> Second, it's extremely unrealisitic to expect much code to handle any
> kind of faults in the middle of bitbanging loops ... or even just in
> classic "set this bit and continue" configuration code.

That's interesting.  I'm not sure it's a good idea not to return an
error code.  The caller can just ignore it if they don't care, and
it's extremely cheap to "return 0" in GPIO drivers which can't error.

If I were bit-banging on GPIOs reached via some peripheral chip (such
a GPIO-fanout chip over I2C/SPI, where that chip is itself feeding a
secondary I2C or similar bit-banging bus), I probably would like to
check for errors and take emergency action if the peripheral chip
isn't responding, or just report to userspace.

This has actually happened on a board I worked with, where the primary
I2C failed due to a plugged in peripheral loading it too much, and a
secondary bit-banging bus was not then reachable.

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