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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 C1B88C4363A for ; Thu, 22 Oct 2020 08:24:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 76C65223C7 for ; Thu, 22 Oct 2020 08:24:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2443783AbgJVIYf (ORCPT ); Thu, 22 Oct 2020 04:24:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33358 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726045AbgJVIYe (ORCPT ); Thu, 22 Oct 2020 04:24:34 -0400 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 03ADCC0613CE for ; Thu, 22 Oct 2020 01:24:34 -0700 (PDT) Received: from [2a0a:edc0:0:900:6245:cbff:fea0:1793] (helo=kresse.office.stw.pengutronix.de) by metis.ext.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1kVVtY-0003nF-FK; Thu, 22 Oct 2020 10:24:25 +0200 Message-ID: <4985eb0d018d488d93e427db27be9418057d9440.camel@pengutronix.de> From: Lucas Stach To: Peng Fan , Jacky Bai , Shawn Guo , Rob Herring Cc: dl-linux-imx , Fabio Estevam , Frieder Schrempf , Marek Vasut , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "kernel@pengutronix.de" , "patchwork-lst@pengutronix.de" Date: Thu, 22 Oct 2020 10:24:23 +0200 In-Reply-To: References: <20200930155006.535712-1-l.stach@pengutronix.de> <5287bbc0ede98dd3fc0022f2062148275dafa05c.camel@pengutronix.de> <18c98a86aaac86a5742d6f8c4c671ae522751dda.camel@pengutronix.de> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2a0a:edc0:0:900:6245:cbff:fea0:1793 X-SA-Exim-Mail-From: l.stach@pengutronix.de Subject: Re: [PATCH 00/11] i.MX8MM power domain support X-SA-Exim-Version: 4.2.1 (built Wed, 08 May 2019 21:11:16 +0000) X-SA-Exim-Scanned: Yes (on metis.ext.pengutronix.de) X-PTX-Original-Recipient: devicetree@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hi Peng, On Mi, 2020-10-14 at 01:23 +0000, Peng Fan wrote: [...] > > > > > 3. either 8MM, 8MN, or 8MP, the power domain design is different, > > > > > I am not > > > > sure if it is the good to add hundreds line of code in GPCv2 each > > > > time > > > > > a new SOC is added. > > > > > > > > I don't buy into this argument. We have lots of drivers in the Linux > > > > kernel that require some changes for new SoC generations, that's > > > > what Linux drivers are for. The complexity of the hardware doesn't > > > > disappear just because you push some of the driver bits into TF-A, > > > > you just handle the complexity at a different palce and IMHO that > > > > the wrong place. The power domains have complex interactions with > > > > other drivers in the Linux system, so debugging and deplyong fixes > > > > is much easier when the power domain handling is fully done by a kernel > > driver. > > > Actually, due to the security requirement from other system solution > > > provider, for example, Microsoft Azure Sphere, it has strict > > > requirement for power domain to be controlled by secure subsystem(either > > TF-A, TEE or dedicated secure domain controller). > > > Same requirement for reset control, and system critical clock control. > > > > Yes, I'm aware of those requirements, but to satisfy those you need a full > > implementation of all those parts in the secure subsystem. Doing it just for the > > power domains adds complexity for no gain, as you still won't be able to meet > > all the requirements and frankly I don't think this is a realistic goal to achieve > > with the current i.MX8M family of SoCs. > > At least we are moving to that direction. To me it seems like the current way (custom TF-A interface and implementation) is one step in the right direction, but two steps backwards in terms of complexity. > > Meeting those requirements needs a fully system approach where the secure > > subsystem parts are made sufficiently independent from the non- secure > > parts on a hardware level, which I don't see on the i.MX8M SoC and hardware > > design guide. > > CSU could restrict the access permission. While this is true, my argument is much broader and not only focused on on-SoC peripherals. For example some of the power domains need different voltages for specific performance states, which means you need to communicate with a external PMIC or other voltage regulator, which in turn means you need to set aside the necessary i2c bus and/or GPIO banks required for this communication at system design time, so it isn't shared between TF-A and the rich OS. I don't see this in any of the i.MX8M designs. > > > For NXP i.MX8M family, it is ok to implement in linux kernel, just a > > > tradeoff to find out a place to hide the complexity ^_^. > > > > > > BTW, for virtualization support, it is better to put the power domain > > > in a central place to simplify the VM implementation. > > > > Same as above. If you can make all the relevant bits (clock, reset, > > power-domain, regulator) available via a virtualization friendly API, then I > > would see a point in adding complexity for this abstraction. As long as this > > added abstraction only solves a very tiny bit of the overall picture, I just don't > > see the point in the added complexity and (from a Linux PoV) obfuscation. > > Could we use SCMI for power domain, system critical clocks, smc watchdog > and etc? If you could demonstrate a working solution with all those pieces hidden behind a standard SCMI interface, this would make for a much more compelling story supporting the secure subsystem argument. > Or we support two approaches, one is let Linux control everything, the other > is using SCMI. > > Thoughts? I wouldn't be opposed to such a solution. If you can put all this behind a standard SCMI interface, I guess we wouldn't need two different SoC specific drivers for the same purpose, so we could easily have a Linux full-control solution (i.e. this patchset) coexist with a SCMI based implementation, possibly with just a slightly different base SoC DT with all the power domains, clocks and other system level control stuff behind SCMI. What I'm strongly opposed to is having a custom TF-A interface and all the added complexity for little to no gain in actual system security. Regards, Lucas 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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 5A472C4363A for ; Thu, 22 Oct 2020 08:26:10 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 BCD632065D for ; Thu, 22 Oct 2020 08:26:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="fWn0pzGr" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BCD632065D 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+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=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Subject:MIME-Version:References:In-Reply-To:Date:To: From:Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=BVQVPUgqQ8hc7ksLAEPznRyUvokwcjxsadT3bJ7W7cc=; b=fWn0pzGr5T+nRo7lZFN0Ob1ha XQ+1/D7oxmEfbeLZQsnO2xHHai3FqgPZetlvpGoyec+h81sW99v2A4I09z80T2LX1Vi0aXTWSA3K9 U/1+QKZC/eMuEzd05myO5mXdgRMxtEfZirQVtb42/qOlPMqiSnl+dFPMs/TbTaGvoKt9UxPH944Qm EowgXC0bidpSMgIpEO51KSgke8cfvPG7HQGhL9EAs283JzozAExO53l8sy8DonXItJ6odw1Hztx62 s8fFjiNLahVKof3lvsIcSP+ZliXS42OSAP+21/DvhSiReNpaxZ0w+dxDTJtfiDB86b7jQrlvBAoKF dnMor98ng==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVVtk-0001vb-IZ; Thu, 22 Oct 2020 08:24:36 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVVth-0001v1-Nm for linux-arm-kernel@lists.infradead.org; Thu, 22 Oct 2020 08:24:34 +0000 Received: from [2a0a:edc0:0:900:6245:cbff:fea0:1793] (helo=kresse.office.stw.pengutronix.de) by metis.ext.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1kVVtY-0003nF-FK; Thu, 22 Oct 2020 10:24:25 +0200 Message-ID: <4985eb0d018d488d93e427db27be9418057d9440.camel@pengutronix.de> From: Lucas Stach To: Peng Fan , Jacky Bai , Shawn Guo , Rob Herring Date: Thu, 22 Oct 2020 10:24:23 +0200 In-Reply-To: References: <20200930155006.535712-1-l.stach@pengutronix.de> <5287bbc0ede98dd3fc0022f2062148275dafa05c.camel@pengutronix.de> <18c98a86aaac86a5742d6f8c4c671ae522751dda.camel@pengutronix.de> User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 X-SA-Exim-Connect-IP: 2a0a:edc0:0:900:6245:cbff:fea0:1793 X-SA-Exim-Mail-From: l.stach@pengutronix.de Subject: Re: [PATCH 00/11] i.MX8MM power domain support X-SA-Exim-Version: 4.2.1 (built Wed, 08 May 2019 21:11:16 +0000) X-SA-Exim-Scanned: Yes (on metis.ext.pengutronix.de) 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-20201022_042433_780376_42DEA4CC X-CRM114-Status: GOOD ( 37.12 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marek Vasut , "devicetree@vger.kernel.org" , Frieder Schrempf , "patchwork-lst@pengutronix.de" , dl-linux-imx , "kernel@pengutronix.de" , Fabio Estevam , "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+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Peng, On Mi, 2020-10-14 at 01:23 +0000, Peng Fan wrote: [...] > > > > > 3. either 8MM, 8MN, or 8MP, the power domain design is different, > > > > > I am not > > > > sure if it is the good to add hundreds line of code in GPCv2 each > > > > time > > > > > a new SOC is added. > > > > > > > > I don't buy into this argument. We have lots of drivers in the Linux > > > > kernel that require some changes for new SoC generations, that's > > > > what Linux drivers are for. The complexity of the hardware doesn't > > > > disappear just because you push some of the driver bits into TF-A, > > > > you just handle the complexity at a different palce and IMHO that > > > > the wrong place. The power domains have complex interactions with > > > > other drivers in the Linux system, so debugging and deplyong fixes > > > > is much easier when the power domain handling is fully done by a kernel > > driver. > > > Actually, due to the security requirement from other system solution > > > provider, for example, Microsoft Azure Sphere, it has strict > > > requirement for power domain to be controlled by secure subsystem(either > > TF-A, TEE or dedicated secure domain controller). > > > Same requirement for reset control, and system critical clock control. > > > > Yes, I'm aware of those requirements, but to satisfy those you need a full > > implementation of all those parts in the secure subsystem. Doing it just for the > > power domains adds complexity for no gain, as you still won't be able to meet > > all the requirements and frankly I don't think this is a realistic goal to achieve > > with the current i.MX8M family of SoCs. > > At least we are moving to that direction. To me it seems like the current way (custom TF-A interface and implementation) is one step in the right direction, but two steps backwards in terms of complexity. > > Meeting those requirements needs a fully system approach where the secure > > subsystem parts are made sufficiently independent from the non- secure > > parts on a hardware level, which I don't see on the i.MX8M SoC and hardware > > design guide. > > CSU could restrict the access permission. While this is true, my argument is much broader and not only focused on on-SoC peripherals. For example some of the power domains need different voltages for specific performance states, which means you need to communicate with a external PMIC or other voltage regulator, which in turn means you need to set aside the necessary i2c bus and/or GPIO banks required for this communication at system design time, so it isn't shared between TF-A and the rich OS. I don't see this in any of the i.MX8M designs. > > > For NXP i.MX8M family, it is ok to implement in linux kernel, just a > > > tradeoff to find out a place to hide the complexity ^_^. > > > > > > BTW, for virtualization support, it is better to put the power domain > > > in a central place to simplify the VM implementation. > > > > Same as above. If you can make all the relevant bits (clock, reset, > > power-domain, regulator) available via a virtualization friendly API, then I > > would see a point in adding complexity for this abstraction. As long as this > > added abstraction only solves a very tiny bit of the overall picture, I just don't > > see the point in the added complexity and (from a Linux PoV) obfuscation. > > Could we use SCMI for power domain, system critical clocks, smc watchdog > and etc? If you could demonstrate a working solution with all those pieces hidden behind a standard SCMI interface, this would make for a much more compelling story supporting the secure subsystem argument. > Or we support two approaches, one is let Linux control everything, the other > is using SCMI. > > Thoughts? I wouldn't be opposed to such a solution. If you can put all this behind a standard SCMI interface, I guess we wouldn't need two different SoC specific drivers for the same purpose, so we could easily have a Linux full-control solution (i.e. this patchset) coexist with a SCMI based implementation, possibly with just a slightly different base SoC DT with all the power domains, clocks and other system level control stuff behind SCMI. What I'm strongly opposed to is having a custom TF-A interface and all the added complexity for little to no gain in actual system security. Regards, Lucas _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel