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, URIBL_BLOCKED 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 CC9C1C282DA for ; Wed, 17 Apr 2019 12:13: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 997372173C for ; Wed, 17 Apr 2019 12:13: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="FP9Qil0r" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 997372173C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de 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:In-Reply-To: Date:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=p/avreTISwtmunDgUrD7/sNVcb7530TYAjCT/3Lu6kE=; b=FP9Qil0rs+6fDU LFQV7nqe+tAdhaqEdxa57ZYRK9saGEta6KnMU07eSGyHXttXLW6wpKKc4nyr5YS0UiBO3pwJPM5Af xP+3TnOmUSp1MknYb0tIilP29Jq7WaaOw3v/de+6Fq0YsBxulf2bg7OpduSrdwhmuRil/P+VjEsjQ hNUXZfJ3lsrmbY1JzLHxT21KVQ22ojJKRmQJYl3tapneeE+i5a+WGSNjRAMV4MXPgIL7pG+6UY91p B/Vvt5Dp4efD7HEeP9PjNrt3AYxCnqHFs1FZJr0kO6Ejo5hLTyXGSBzN58xRZI9axFEDP1XVmGsvy SiGjNjv9DYn2U85RMpew==; 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 1hGjRS-0002Bi-AC; Wed, 17 Apr 2019 12:13:30 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hGjRP-00029M-98 for linux-arm-kernel@lists.infradead.org; Wed, 17 Apr 2019 12:13:29 +0000 Received: from kresse.hi.pengutronix.de ([2001:67c:670:100:1d::2a]) by metis.ext.pengutronix.de with esmtp (Exim 4.89) (envelope-from ) id 1hGjRE-0003X9-Uj; Wed, 17 Apr 2019 14:13:16 +0200 Message-ID: <1555503195.2317.19.camel@pengutronix.de> Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family From: Lucas Stach To: Aisheng Dong , Jacky Bai , "robh+dt@kernel.org" , "mark.rutland@arm.com" , "shawnguo@kernel.org" , "s.hauer@pengutronix.de" , "kernel@pengutronix.de" Date: Wed, 17 Apr 2019 14:13:15 +0200 In-Reply-To: References: <20190417053211.2195-1-ping.bai@nxp.com> X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::2a X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190417_051327_478925_AD64D597 X-CRM114-Status: GOOD ( 21.19 ) 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: "devicetree@vger.kernel.org" , "festevam@gmail.com" , dl-linux-imx , "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 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. 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. Regards, Lucas _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel