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: <56966558.1070608@ti.com>
Date:	Wed, 13 Jan 2016 08:55:20 -0600
From:	Nishanth Menon <nm@...com>
To:	"H. Nikolaus Schaller" <hns@...delico.com>,
	Tony Lindgren <tony@...mide.com>
CC:	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>
Subject: Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging
 of backup battery

On 01/13/2016 04:25 AM, H. Nikolaus Schaller wrote:
[...]

>>>>
>>>> Signed-off-by: Tony Lindgren <tony@...mide.com>
>>>>
>>>> --- a/arch/arm/boot/dts/omap5-board-common.dtsi
>>>> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
>>>> @@ -213,6 +213,12 @@
>>>> 		>;
>>>> 	};
>>>>
>>>> +	palmas_msecure_pins: palmas_msecure_pins {
>>>> +		pinctrl-single,pins = <
>>>> +			OMAP5_IOPAD(0x180, PIN_OUTPUT | MUX_MODE1) /* gpio8_234.sys_drm_msecure */
> 
> I wonder now what MODE1 is.
> 
> In my OMAP5 TRM (Version "Y" - may be too old) the MODE1 is tagged as "reserved".
> 
> Maybe "reserved" happens to output a "1" on OMAP5 and a "0" on the X15?
> 
> And as far as I am aware there is no "driver" for some MSECURE module (but I don't know the details of MSECURE control by software).

Good catch. This one is interesting. If my memory serves me right,
MSECURE signal from SoC is triggered in secure mode (trustzone) - the
requirement was that certain PMIC modifications should only be done in
secure mode for certain product applications. What this means is that
certain functions of the PMIC will be unavailable when the SoC is
running in "untrusted" mode.

Instead, the usual mode of operation is to set it up as GPIO (as Nikolas
pointed below) and either use GPIO HOG or default weak pull to keep it
in the required state.

I think it is better to set it as GPIO than as DRM_MSECURE.

This is probably also the reason why this mode is NOT in public TRM -
all security related topics are probably in the NDA only secure TRM
addendum.

I'd suggest setting up a GPIO hog and a mux to GPIO for board-common (we
are not doing any HS OMAP5 at least in public domain :) ).

> 
> This one
> 
>>>> 		OMAP5_IOPAD(0x180, PIN_INPUT _PULLUP | MUX_MODE6) /* gpio8_234 used for sys_drm_msecure */
> 
> 
> works for me on the OMAP5 EVM as well.
> 

[...]

-- 
Regards,
Nishanth Menon