linux-kernel - Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

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: <56969800.5010206@ti.com>
Date:	Wed, 13 Jan 2016 12:31:28 -0600
From:	Nishanth Menon <nm@...com>
To:	"H. Nikolaus Schaller" <hns@...delico.com>,
	Tony Lindgren <tony@...mide.com>
CC:	Grygorii Strashko <grygorii.strashko@...com>,
	Laxman Dewangan <ldewangan@...dia.com>,
	Benoît Cousson <bcousson@...libre.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Russell King <linux@....linux.org.uk>,
	linux-omap <linux-omap@...r.kernel.org>,
	<devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
	Marek Belisko <marek@...delico.com>,
	Gražvydas Ignotas <notasas@...il.com>,
	Keerthy <j-keerthy@...com>
Subject: Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging
 of backup battery

On 01/13/2016 12:08 PM, H. Nikolaus Schaller wrote:
[...]

>> OK. So are we sure the TWL driver will never have to toggle this pin?
> 
> After studying the Palmas TRM it appears that this pin just should be "high"
> to be able to write to RTC and some scratchpad register. If the Palmas OTP
> is programmed to use gpio7 as msecure input.

Thanks for digging it up. we dont use the scratchpad, but in some cases
where SoC cold reset is involved, those registers may store additional
information.

> 
> Since the scratchpad is not used we can permanently enable msecure. Which
> means that we must somehow get the driving output to be "1".
> 
> This can be either done by
> * a gpio with pull-up - switched to input mode as I proposed, or

I think you intended to suggest to do a mux to gpio with just pinmux
pull? The internal pull on padconf is very weak - for typical needs like
these, it is rather suggested to stick with real GPIO drive to prevent
conditions like noise interference(for example).


-- 
Regards,
Nishanth Menon