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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 29 Dec 2008 16:43:03 -0800
From:	David Brownell <david-b@...bell.net>
To:	Jamie Lokier <jamie@...reable.org>
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

On Monday 29 December 2008, Jamie Lokier wrote:
> 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.

I'm not sure either; at this point I *might* consider doing
it differently -- but primarily for the case of external GPIO
chips, e.g. over I2C or SPI -- where errors are realistic.  But
it's been this way for a few years now, and changing stuff
that hasn't been observed to be a problem isn't on my list.

But as I noted:  patches for $SUBJECT don't seem to have any
reason not to report whatever faults they encounter.

Also worth remembering:  when reading a GPIO value, it's not
so easy to "ignore" a tristate (0, 1, error) return value.

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

If I had to do that, I'd *certainly* want to bang the hardware
designer over the head with some sort of cluebat or cluebrick.  :(

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

It should now be realistic for I2C device drivers to have
fault recovery logic...

But for a long time, I2c only returned -EPERM so it was
completely hopeless trying to figure out how to "handle"
any problem beyond logging the problem and hoping someone
is watching syslog output.  That's a big part of why most
current I2C drivers have such unfriendly fault handling.

- Dave

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