From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932406AbcAMPOr (ORCPT ); Wed, 13 Jan 2016 10:14:47 -0500 Received: from comal.ext.ti.com ([198.47.26.152]:60263 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750955AbcAMPOo (ORCPT ); Wed, 13 Jan 2016 10:14:44 -0500 Subject: Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery To: Nishanth Menon , "H. Nikolaus Schaller" , Tony Lindgren References: <8FE6954B-6411-4593-9CE5-717A469A6AA8@goldelico.com> <20160106164136.GI12777@atomide.com> <2AC46952-3758-458A-B0A5-1794C207BD4C@goldelico.com> <20160106170925.GK12777@atomide.com> <66F37918-EA7F-4D83-8B5F-A6B5C0CD7623@goldelico.com> <20160108181551.GX12777@atomide.com> <832803EE-E4CB-46B1-BF39-2DC0BB695A5D@goldelico.com> <20160108190457.GY12777@atomide.com> <20160111202421.GA12777@atomide.com> <20160112000917.GC12777@atomide.com> <417BBA32-A7DC-40CD-8A6B-EA910B1C9C13@goldelico.com> <001346CD-CF31-4FEF-B406-B89EEBDFA063@goldelico.com> <56966558.1070608@ti.com> CC: Laxman Dewangan , =?UTF-8?Q?Beno=c3=aet_Cousson?= , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Russell King , linux-omap , , LKML , Marek Belisko , =?UTF-8?Q?Gra=c5=bevydas_Ignotas?= From: Grygorii Strashko Message-ID: <569669C5.2070200@ti.com> Date: Wed, 13 Jan 2016 17:14:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <56966558.1070608@ti.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >>>>> >>>>> --- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grygorii Strashko Subject: Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery Date: Wed, 13 Jan 2016 17:14:13 +0200 Message-ID: <569669C5.2070200@ti.com> References: <8FE6954B-6411-4593-9CE5-717A469A6AA8@goldelico.com> <20160106164136.GI12777@atomide.com> <2AC46952-3758-458A-B0A5-1794C207BD4C@goldelico.com> <20160106170925.GK12777@atomide.com> <66F37918-EA7F-4D83-8B5F-A6B5C0CD7623@goldelico.com> <20160108181551.GX12777@atomide.com> <832803EE-E4CB-46B1-BF39-2DC0BB695A5D@goldelico.com> <20160108190457.GY12777@atomide.com> <20160111202421.GA12777@atomide.com> <20160112000917.GC12777@atomide.com> <417BBA32-A7DC-40CD-8A6B-EA910B1C9C13@goldelico.com> <001346CD-CF31-4FEF-B406-B89EEBDFA063@goldelico.com> <56966558.1070608@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56966558.1070608-l0cyMroinI0@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Nishanth Menon , "H. Nikolaus Schaller" , Tony Lindgren Cc: Laxman Dewangan , =?UTF-8?Q?Beno=c3=aet_Cousson?= , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Russell King , linux-omap , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, LKML , Marek Belisko , =?UTF-8?Q?Gra=c5=bevydas_Ignotas?= List-Id: devicetree@vger.kernel.org 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 >>>>> >>>>> --- 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html