From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, T_TVD_FUZZY_SECURITIES autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED185C282DA for ; Wed, 17 Apr 2019 12:40:34 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B6C8120835 for ; Wed, 17 Apr 2019 12:40:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="bbm96NvI"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=nxp.com header.i=@nxp.com header.b="f31K7PkI" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B6C8120835 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nxp.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:Message-ID:Date :Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: List-Owner; bh=qm90pJk+FYxrGV8Gxmwipr4bUnbM1kHYMBkUIunYVZ4=; b=bbm96NvIS5n6vH xC25x4PsNMTOjRklEL6mjXBsh9M7PZtq1WwxDlVyBoy183oKqd4hR6GqySgAhxh8gjbdHndVXVtQ9 Z0Vt7vYncHyY2DRwWQ9d4odAuTYMRIV7QgZ0hy7YSIEMeQV5AzqiOVYttk1vTnT7fO+6+aAZWHF+v NH4PEssVsZg0itzWEdK9Ja4L82jb3vcVmaN5qaCx0VOIFN92hGcCKYJLdVfgeg2EVPpOd4ZGIcKGc 3tJoF2RwDGsND/20XcQwYooUR0pwjrCxVv6wXh9dZ5QfXQVlgZr4Tyr8pBShZJkZR5DniOvg4xuND clcu/SKnP8NYPHKH7EoQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hGjrZ-0000CY-3u; Wed, 17 Apr 2019 12:40:29 +0000 Received: from mail-eopbgr130074.outbound.protection.outlook.com ([40.107.13.74] helo=EUR01-HE1-obe.outbound.protection.outlook.com) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hGjrW-0000Bj-2Q for linux-arm-kernel@lists.infradead.org; Wed, 17 Apr 2019 12:40:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i8hpeWOexM8IuYdwDcoEijgD7Fnr5hwewgib0OEl29g=; b=f31K7PkIz8uLSdzs+ULO80LBGZ+uMjsb4VK1TBAS1hOk1lxDqtWsh8Yza1wEE8bChg332pL02p1MmTvAij8IWhirla9p98bKtKi4uj4wwzT3SAd+3I9Pf4rUsIJXT4S6rQeGCWBfuIF7MxIh6FT1XDzNhWhsAMNXKFIYxQoyStc= Received: from VI1PR04MB5533.eurprd04.prod.outlook.com (20.178.122.159) by VI1PR04MB4751.eurprd04.prod.outlook.com (20.177.48.208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.11; Wed, 17 Apr 2019 12:40:20 +0000 Received: from VI1PR04MB5533.eurprd04.prod.outlook.com ([fe80::cca7:43cf:dc13:a822]) by VI1PR04MB5533.eurprd04.prod.outlook.com ([fe80::cca7:43cf:dc13:a822%4]) with mapi id 15.20.1813.011; Wed, 17 Apr 2019 12:40:19 +0000 From: Leonard Crestez To: Lucas Stach , Jacky Bai , Peng Fan , Sudeep Holla Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family Thread-Topic: [PATCH 0/3] Add power domain driver support for i.mx8m family Thread-Index: AQHU9Rq3FN3rYS47x0yUoc0MIijDRw== Date: Wed, 17 Apr 2019 12:40:19 +0000 Message-ID: References: <20190417053211.2195-1-ping.bai@nxp.com> <1555503195.2317.19.camel@pengutronix.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=leonard.crestez@nxp.com; x-originating-ip: [192.88.166.1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 52c628a0-e7f9-4e0a-c4d3-08d6c331da1b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1PR04MB4751; x-ms-traffictypediagnostic: VI1PR04MB4751: x-microsoft-antispam-prvs: x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(136003)(376002)(346002)(39860400002)(199004)(189003)(8676002)(4326008)(102836004)(55016002)(68736007)(229853002)(6436002)(5660300002)(6246003)(81156014)(486006)(9686003)(8936002)(71200400001)(33656002)(2906002)(6116002)(7416002)(25786009)(81166006)(44832011)(53936002)(3846002)(52536014)(316002)(99286004)(186003)(97736004)(478600001)(71190400001)(7696005)(86362001)(7736002)(26005)(6506007)(105586002)(54906003)(74316002)(305945005)(53546011)(476003)(446003)(256004)(110136005)(14444005)(66066001)(14454004)(76176011)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR04MB4751; H:VI1PR04MB5533.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: F9h9MCUN3BPupTAMP3bajnzENgKiAtb0XT78rtpWnef4/4lOh3P64EZ+1nppi/tmLQPjSpufsa5us3pyvl9PRQacufEJPzPBkwqfMQ8ZQnRDWmvbhjIMqmBGKq53NpieuEavSwYZ3ut8B7CIh6Im1DJEy/YdQnkekBO6GyF8O+4mC79xtsm5bqXVe9F2KJFMzW2mB+Wke0wy4cSwr8Zy1+J0MlGJc8cLKW9qo3ZATtB7bFyfAJ2CN0vysBcCgFC0hXdoxQnOOlNMONWLZ2SkLr2aRY2cPsSVrJhMJrS6Nu1VlsWnHmNX4Z37tj2m1aN3vunl2mTSXcE6JZLyAA4YrG99tc6aXZlLQjxPs02A5s8qSNvACPwMDjOEb32Z1fyxmRnqjmG+ovpO2jlVZ+2xwLd1QsRZZUQRlhM6WnvjvmA= MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 52c628a0-e7f9-4e0a-c4d3-08d6c331da1b X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2019 12:40:19.8500 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB4751 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190417_054026_111776_B33DA2AD X-CRM114-Status: GOOD ( 16.29 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Aisheng Dong , "mark.rutland@arm.com" , "devicetree@vger.kernel.org" , "festevam@gmail.com" , "s.hauer@pengutronix.de" , =?iso-8859-1?Q?Cl=E9ment_Faure?= , "robh+dt@kernel.org" , dl-linux-imx , "kernel@pengutronix.de" , Silvano Di Ninno , "shawnguo@kernel.org" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 4/17/2019 3:13 PM, Lucas Stach wrote: > Am Mittwoch, den 17.04.2019, 11:16 +0000 schrieb Aisheng Dong: >>> From: Jacky Bai >>> Sent: Wednesday, April 17, 2019 1:27 PM >>> >>> The i.MX8M family is a set of NXP product focus on delivering the latest and >>> greatest video and audio experience combining state-of-the-art media-specific >>> features with high-performance processing while optimized for lowest power >>> consumption. >>> i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong to >>> this family. >>> >>> The GPC module is used to manage the PU power domains' power on/off. For >>> the whole i.MX8M family, different SoC has differnt power domain design. the >>> power up sequence has significant difference. >>> all the power sequence must be guaranteed by SW. Some domains' power up >>> sequence need to access the SRC module or sub-system specific GPR. >>> the SRC register & SS's register are not in in the GPC's memory range. >>> >>> it makes us hard to use the GPCv2 driver to cover all the different power up >>> requirement. Each time, a new SoC is added, we must modify the GPCv2 driver >>> to make it resuable for it. a lot of code need to be added in GPCv2 to support it. >>> we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT be >>> self-contained. Accessing the non-driver specific module's register is a bad >>> practice. Although, the GPC module provided the similar function for PU power >>> domain, but it is not 100% compatible with GPCv2. >>> >>> The most important thing is that the GPC & SRC module is a security critical >>> resource that security permission must be considered when building the >>> security system. The GPC module is not only used by PU power domain power >>> on/off. It is also used by the TF-A PSCI code to do the CPU core power >>> management. the SRC module control the CPU CORE reset and the CPU reset >>> vector address. if we give the non-secure world write permission to SRC. >>> System can be easily induced to malicious code. >> >> Considering the security issue, it looks to me a right direction to move GPC >> power handling into ATF. >> It also helps build a more generic driver and ease other OS integration >> needed by customers (e.g. QNX, Win10). >> >> Lucas, >> How do you think of it? > > I don't yet buy the security argument. There are many more shared parts > on the SoC, like the clock controller, that would need to be taken away > from the non-secure world if one would want to run an untrusted OS > kernel on a i.MX8M system. > > To properly implement security on any i.MX8M based system the firmware > would need to grow something like a full ARM SCPI implementation, so > all shared critical peripherals are solely under firmware control. It might be possible to rework this to use some form of SCMI-over-SMC instead of vendor-specific SMCCC SIP calls +SCMI maintainer > I agree that it might make sense to move some parts into the firmware > and have much simpler OS level drivers, but I don't agree on the > implementation direction taken here. Growing custom PSCI extension > interfaces will only get us so far, without solving the system security > issue in a holistic way. It is my strong believe that only a complete > rearchitecture of the OS support on top of a ARM SCPI firmware > interface can solve this properly. Hiding everything critical for security (especially CCM) behind a SCMI interface would be a large amount of work but introducing SCMI incrementally (starting with imx8mm power) would be useful by itself because it simplifies OS implementation. Many at NXP have attempted to evaluate SCMI and their conclusion has always been that "many extensions are required". -- Regards, Leonard _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel