linux-kernel - Re: GPIO support for HTC Dream

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]

Message-ID: <20091215204803.GA26319@shareable.org>
Date:	Tue, 15 Dec 2009 20:48:03 +0000
From:	Jamie Lokier <jamie@...reable.org>
To:	H Hartley Sweeten <hartleys@...ionengravers.com>
Cc:	Daniel Walker <dwalker@...eaurora.org>,
	Pavel Machek <pavel@....cz>,
	Iliyan Malchev <malchev@...gle.com>,
	Brian Swetland <swetland@...gle.com>,
	Arve Hj?nnev?g <arve@...roid.com>,
	kernel list <linux-kernel@...r.kernel.org>,
	Ryan Mallon <ryan@...ewatersys.com>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: GPIO support for HTC Dream

H Hartley Sweeten wrote:
> From Pavel's implementation it appears that the gpio's are organized
> as a number of 8-bit ports.  Each of these ports only have one 8-bit
> register.  Writing a '1' to a bit in the register makes the
> associated pin a high-level output.  Writing a '0' makes the pin a
> low-level output or an input pin.  Reading the port at this point
> will return the actual 'input' level of the pin.
> 
> The hardware seems a bit strange and I just wanted to verify that this is
> correct.  If it is, this would explain the need to keep the 'shadow' contents
> of the port in order to set the 'direction' of a pin.

It sounds similar to the PCF8575 (except polarity is reversed), which
is an I2C-driven GPIO chip with "quasi-bidirectional I/O pins", so not
completely weird.

The PCF8575 is more or less an open collector output - it drives a pin
low when 0 is written, and lets it be pulled high by an external
resistor when 1 is written, and reads return the current measured
level.  So by writing 1, you can use the pin as an input, or you can
use it as an output by using a pull-up resistor.

However, to complicate matters, when transitioning from 0 to 1, the
PCF8575 briefly drives the output high, to ensure that a pulled up
output has a rapid transition.

Because of that, you *must not* write 0->1 transitions to the PCF8575
for a GPIO that is driven low by something else, unless you want a
current spike.  So you can't use it as an open collector bus, for
example, and it's important to maintain a shadow variable so that you
don't write back bit values read from the chip.

(I don't know why they don't just use separate enable and value bits
like everything else, but there you go).

Perhaps the Dream's GPIOs are similar, but with opposite polarity.
If it also has the same transition driving spike, writing a 1->0
transition would be bad for the hardware making the shadow variable
even more important.

> I was also wondering if the initial 'shadow' value needs to be written to the
> port at init in order to correctly establish the output value for specific
> pins.

If it's like the PCF8575, after hard reset the bits will all be
configured in the input state, and rely on external pull-downs to set
bootup values.

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