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]
Message-ID: <BD79186B4FD85F4B8E60E381CAEE19090200E9C6@mi8nycmail19.Mi8.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ