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]

Date:	Wed, 13 Jan 2016 17:14:13 +0200
From:	Grygorii Strashko <grygorii.strashko@...com>
To:	Nishanth Menon <nm@...com>,
	"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:55 PM, Nishanth Menon wrote:
> 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 :) ).

Yeah. As I remember the same issue was with OMAP4 (twl6030_omap4.dtsi)
and, again if i remember correctly, someone reported that sys_drm_msecure might have different values
on different SoCs. Also I'd like to note that on Old non-DT kernel such functionality
was always modeled using GPIO.
 

-- 
regards,
-grygorii