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

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

Date:	Mon, 14 Dec 2009 13:12:30 -0500
From:	"H Hartley Sweeten" <hartleys@...ionengravers.com>
To:	"Daniel Walker" <dwalker@...eaurora.org>,
	"Pavel Machek" <pavel@....cz>
Cc:	"Ryan Mallon" <ryan@...ewatersys.com>,
	"Iliyan Malchev" <malchev@...gle.com>,
	"Brian Swetland" <swetland@...gle.com>,
	"kernel list" <linux-kernel@...r.kernel.org>,
	"Arve Hj?nnev?g" <arve@...roid.com>,
	"linux-arm-kernel" <linux-arm-kernel@...ts.infradead.org>
Subject: RE: GPIO support for HTC Dream

On Monday, December 14, 2009 10:55 AM, Daniel Walker wrote:
> On Mon, 2009-12-14 at 07:45 +0100, Pavel Machek wrote:
>> Hi!
>> 
>>> This looks MUCH better!
>> 
>> Thanks :-).
>> 
>>>> arch/arm/Kconfig                     |    1
>>>> arch/arm/mach-msm/board-dream-gpio.c |  327 +++++++++--------------------------
>> ...
>>> Please update (or remove) this diffstat.  It no longer matches the patch.
>> 
>> I was just showing differences to _previous_ version, not what I was sending.
>> 
>>> Ok.  The hardware still seems a bit strange. Is there any datasheet
>>> available?
>> 
>> I don't think there is one. Daniel, can you help here?
>
> I don't know if there is one or not (I'd guess not).. I can't release
> documents, but I could try to address specific questions or find people
> to answer specific questions.

Hello Daniel,

My specific question was about the gpio hardware registers.

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.

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.

One other thing.  Are the gpio's handled by Pavel's driver actually from the
MSM chip or from an external CPLD?  The registers are all defined as:

+		.reg = reg_num + DREAM_CPLD_BASE,

If they are external from the MSM chip this driver should probably be renamed
to something more appropriate since it is probably dream specific and not
generic to the msm architecture.

Thanks for the help,
Hartley