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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 71F45C433F5 for ; Tue, 8 Mar 2022 10:18:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345796AbiCHKT2 (ORCPT ); Tue, 8 Mar 2022 05:19:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55474 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345794AbiCHKTZ (ORCPT ); Tue, 8 Mar 2022 05:19:25 -0500 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5F09021E17 for ; Tue, 8 Mar 2022 02:18:29 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id kt27so38197414ejb.0 for ; Tue, 08 Mar 2022 02:18:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nJRzJEaEiciL+Nan42l5Fbs3eLckPdHReRoJIMrSaeM=; b=cSn0n/IpRFUfcdpnyJ8hYV0UqfK2rGdYVl3t+GDWwQoB2iG5FHHYhb9yJb/CK9KXUj LG14tTWxRXl+gZP98W1BiHviVmCj1tr1Mv7yyLJ0WxGu6IoJ7R0sfB8rdzoljmM73tXZ +UvXfohmxeRu6Bjvk0kr74K+G1MKkaWK02+l55kiZ1kP/gDUeqxdbAxmuSq8CU5fkccx iQotqdnw+NvUjKg+DLOOM2INPtac0GCTcnPqDGbizhyyWJizk0cop3bVDV3ruXMm8Gxo r5547ZH+sr2133o1B8WiMpETiemGPyixP/qshju3Qws9dcSBcvvAZRpEOiZt3Ie3DoZf v85Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nJRzJEaEiciL+Nan42l5Fbs3eLckPdHReRoJIMrSaeM=; b=sns0u9zXgoy2PWkqlZGAr4m7I9QLE22dqwfZLqfWJiyqEQR89AWNl6K1cMvtYKJJv2 PWRvrhO3cMWgOaWU42ntKe9o0TR0JT1ctHYsISrHhZ+FW0YvQn4P/DOLEbPHM+qjNse/ zqxlLd8DOgEHeiOUtza8oHXc7NyRTXS4tgFHAvRDqr3D12js4/Ep/7XyCmk1FmSMNirt QZG1/qo9x0Vgu7wRTovLZQQzSVQC4r2Y673wHJbVv01uf8Z72ZueMBo829iRERBnXXEZ wrpCM3mQ8tDyuRMQYdXWJ5tJsFHkqreBNNjWe557SLMhS+vIUpFrnejAXGC72yNZfR5I Tk4w== X-Gm-Message-State: AOAM5319XWi2ygCRrwvyp6e2UrEeNawPEQdR4kNVEzcL26yc04sX5eCx NYcV2mGNZCoQReaqxQlmWB0yRGIoFhw3AQcL8gduiw== X-Google-Smtp-Source: ABdhPJx3EQL/icr/MX5fhItL/ji0+anuY7+ku8SlMkyxeZTkF8Vvr8t6wm0oIlFkujJGnmsMLrRgwxyHfsxeS4dg4PQ= X-Received: by 2002:a17:906:c1d6:b0:6d6:e0a3:bbc7 with SMTP id bw22-20020a170906c1d600b006d6e0a3bbc7mr12548180ejb.484.1646734707884; Tue, 08 Mar 2022 02:18:27 -0800 (PST) MIME-Version: 1.0 References: <20211028140009.23331-1-etienne.carriere@linaro.org> <58a0e791-9573-99c2-0cc5-3920a1048113@pengutronix.de> <2b4442d9-fb10-36ee-585d-4103b76abbbb@pengutronix.de> In-Reply-To: <2b4442d9-fb10-36ee-585d-4103b76abbbb@pengutronix.de> From: Etienne Carriere Date: Tue, 8 Mar 2022 11:18:16 +0100 Message-ID: Subject: Re: [PATCH v8 1/2] dt-bindings: arm: Add OP-TEE transport for SCMI To: Ahmad Fatoum Cc: Sudeep Holla , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Cristian Marussi , Vincent Guittot , devicetree@vger.kernel.org, Rob Herring , Pengutronix Kernel Team Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Ahmad, On Tue, 8 Mar 2022 at 10:51, Ahmad Fatoum wrote: > > Hello Sudeep, > > On 01.03.22 16:12, Sudeep Holla wrote: > > > > Hi Ahmad, > > > > On Mon, Feb 28, 2022 at 05:01:39PM +0100, Ahmad Fatoum wrote: > >> Hello Etienne, > >> > >> On 28.10.21 16:00, Etienne Carriere wrote: > >>> Introduce compatible "linaro,scmi-optee" for SCMI transport channel > >>> based on an OP-TEE service invocation. The compatible mandates a > >>> channel ID defined with property "linaro,optee-channel-id". > >> > > > > Not sure if Etienne's reply addressed your queries/concerns correctly. > > I thought I will add my view anyways. > > > >> I just found this thread via the compatible in the STM32MP131 patch set: > >> https://lore.kernel.org/all/20220225133137.813919-1-gabriel.fernandez@foss.st.com/ > >> > >> Linux doesn't care whether PSCI is provided by TF-A, OP-TEE or something > >> else, so there is just the arm,psci* compatible. > >> > > > > Correct, the interface to the kernel is fixed and hence we must be able > > to manage with the standard and fixed sole set of bindings for the same. > > > >> What's different about SCMI that this is not possible? Why couldn't the > >> existing binding and driver be used to communicate with OP-TEE as secure > >> monitor as well? > >> > > > > However with SCMI, the spec concentrates and standardises all the aspects > > of the protocol used for the communication while it allows the transport > > used for such a communication to be implementation specific. It does > > address some standard transports like mailbox and PCC(ACPI). However, > > because of the flexibility and also depending on the hardware(or VM), > > different transports have been added to the list. SMC/HVC was the one, > > followed by the virtio and OPTEE. While I agree SMC/HVC and OPTEE seem > > to have lot of common and may have avoided separate bindings. > > > > However the FIDs for SMC/HVC is vendor defined(the spec doesn't cover this > > and hence we utilised/exploited DT). Some vendors wanted interrupt support > > too which got added. OPTEE eliminates the need for FID and can also provide > > dynamic shared memory info. In short, it does differ in a way that the driver > > needs to understand the difference and act differently with each of the > > unique transports defined in the binding. > > > > Hope that explains and addresses your concern. > > Thanks for the elaborate answer. I see now why it's beneficial to have > an OP-TEE transport in general. I don't yet see the benefit to use it > in the STM32MP13x instead of SMCs like with STM32MP15x, but that a discussion > that I need to have in the aforementioned thread. Some SCMI operations in OP-TEE need to execute in a threaded context (preemptible, ...). There is no SMC function ID defined for an SCMI thread entry in OP-TEE. We rather use standard invocation of a TEE service: opening a session and invoking commands. Invoked commands are executed in an OP-TEE native threaded context. The service accessed is referred to as the OP-TEE SCMI PTA. As for STM32MP15x, one willing to extend resources assigned to secure world may also need to move mp15 SCMI from SMC transport to optee transport. Regards, Etienne > > Thanks again! > Ahmad > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id C0665C433EF for ; Tue, 8 Mar 2022 10:33:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=3lmxod4INrqHRLkXgdpz8cTQrnt/plBNXow4n0X4bsg=; b=FOFGFWE5RuOER+ LNwb6fRVwwYRhJwVSWpPWYvlK+Mu49fKJ2HsHXzdGXIvsEs8kybkVlnZkh6CB7BsyPRMduiplLE+C idKdsJLH9Wtih9RXHyrB5l8NVC8F65uyltUSzlAi88VBgsXWuT++etCj7SPj8Ctw1vBpyFGcNZjnv UscxuHVWLh7FxshspLuSwEtOOYqrxpyVwqsMMQN3YWXpuQ4EKAC6OTWdGUbfv6/vvFuitnQVSP+Dj Jb8gn24H82LzIxy3dtGBs2Yk4gqS3o912tPWdqafZEMdrdn5WP12gsEx8uPz93m+a5lCl4iJwHAiD ItyvBWxdJ1uo5mgoajzg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRX8I-003tF0-GI; Tue, 08 Mar 2022 10:31:58 +0000 Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRWvG-003nLH-5F for linux-arm-kernel@lists.infradead.org; Tue, 08 Mar 2022 10:18:32 +0000 Received: by mail-ej1-x635.google.com with SMTP id dr20so37995516ejc.6 for ; Tue, 08 Mar 2022 02:18:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nJRzJEaEiciL+Nan42l5Fbs3eLckPdHReRoJIMrSaeM=; b=cSn0n/IpRFUfcdpnyJ8hYV0UqfK2rGdYVl3t+GDWwQoB2iG5FHHYhb9yJb/CK9KXUj LG14tTWxRXl+gZP98W1BiHviVmCj1tr1Mv7yyLJ0WxGu6IoJ7R0sfB8rdzoljmM73tXZ +UvXfohmxeRu6Bjvk0kr74K+G1MKkaWK02+l55kiZ1kP/gDUeqxdbAxmuSq8CU5fkccx iQotqdnw+NvUjKg+DLOOM2INPtac0GCTcnPqDGbizhyyWJizk0cop3bVDV3ruXMm8Gxo r5547ZH+sr2133o1B8WiMpETiemGPyixP/qshju3Qws9dcSBcvvAZRpEOiZt3Ie3DoZf v85Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nJRzJEaEiciL+Nan42l5Fbs3eLckPdHReRoJIMrSaeM=; b=RM5WupINWoxBNP5orzcaEA9GyzA4YlVVyQeHohESUc406EEfQvKvJahLvRKg3B3VY/ RsZ5ZUxtuUSaQQIVa+sqotDsuL6+YymBRkyJxoWNsOa6ZTVmxZZCawBgKB6MN91Ngv9K r86rL+h7XRNK3CBTDMc7rzpFiw02D9HTYxmgrJEiHMl+dM5h+dBrzpx7kqgAb5oEh8wV 5ERE5yZp3DLo+bxtQGKKiksQHSJycH74A67xeReYBg1fFDJ1uDDn4aSVe0/BsolbzwY1 ukaJI2KCA2tQbfimJ8lW0s7LmGGMdSb2vSGmu+DAA3eCkpWkJmqJeGr/crwJfIGClqYf WAow== X-Gm-Message-State: AOAM533fb77eVRSlu1y+ei/zqd+4EyR/kNXBBG2hsWkOKl6YlEnJvPqG PZSoUY0Zhwwb7YXtTOuco70wSelHXGTPGB1GUtguciJBtzfYiwrj X-Google-Smtp-Source: ABdhPJx3EQL/icr/MX5fhItL/ji0+anuY7+ku8SlMkyxeZTkF8Vvr8t6wm0oIlFkujJGnmsMLrRgwxyHfsxeS4dg4PQ= X-Received: by 2002:a17:906:c1d6:b0:6d6:e0a3:bbc7 with SMTP id bw22-20020a170906c1d600b006d6e0a3bbc7mr12548180ejb.484.1646734707884; Tue, 08 Mar 2022 02:18:27 -0800 (PST) MIME-Version: 1.0 References: <20211028140009.23331-1-etienne.carriere@linaro.org> <58a0e791-9573-99c2-0cc5-3920a1048113@pengutronix.de> <2b4442d9-fb10-36ee-585d-4103b76abbbb@pengutronix.de> In-Reply-To: <2b4442d9-fb10-36ee-585d-4103b76abbbb@pengutronix.de> From: Etienne Carriere Date: Tue, 8 Mar 2022 11:18:16 +0100 Message-ID: Subject: Re: [PATCH v8 1/2] dt-bindings: arm: Add OP-TEE transport for SCMI To: Ahmad Fatoum Cc: Sudeep Holla , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Cristian Marussi , Vincent Guittot , devicetree@vger.kernel.org, Rob Herring , Pengutronix Kernel Team X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220308_021830_248108_343B4A1E X-CRM114-Status: GOOD ( 35.72 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Hello Ahmad, On Tue, 8 Mar 2022 at 10:51, Ahmad Fatoum wrote: > > Hello Sudeep, > > On 01.03.22 16:12, Sudeep Holla wrote: > > > > Hi Ahmad, > > > > On Mon, Feb 28, 2022 at 05:01:39PM +0100, Ahmad Fatoum wrote: > >> Hello Etienne, > >> > >> On 28.10.21 16:00, Etienne Carriere wrote: > >>> Introduce compatible "linaro,scmi-optee" for SCMI transport channel > >>> based on an OP-TEE service invocation. The compatible mandates a > >>> channel ID defined with property "linaro,optee-channel-id". > >> > > > > Not sure if Etienne's reply addressed your queries/concerns correctly. > > I thought I will add my view anyways. > > > >> I just found this thread via the compatible in the STM32MP131 patch set: > >> https://lore.kernel.org/all/20220225133137.813919-1-gabriel.fernandez@foss.st.com/ > >> > >> Linux doesn't care whether PSCI is provided by TF-A, OP-TEE or something > >> else, so there is just the arm,psci* compatible. > >> > > > > Correct, the interface to the kernel is fixed and hence we must be able > > to manage with the standard and fixed sole set of bindings for the same. > > > >> What's different about SCMI that this is not possible? Why couldn't the > >> existing binding and driver be used to communicate with OP-TEE as secure > >> monitor as well? > >> > > > > However with SCMI, the spec concentrates and standardises all the aspects > > of the protocol used for the communication while it allows the transport > > used for such a communication to be implementation specific. It does > > address some standard transports like mailbox and PCC(ACPI). However, > > because of the flexibility and also depending on the hardware(or VM), > > different transports have been added to the list. SMC/HVC was the one, > > followed by the virtio and OPTEE. While I agree SMC/HVC and OPTEE seem > > to have lot of common and may have avoided separate bindings. > > > > However the FIDs for SMC/HVC is vendor defined(the spec doesn't cover this > > and hence we utilised/exploited DT). Some vendors wanted interrupt support > > too which got added. OPTEE eliminates the need for FID and can also provide > > dynamic shared memory info. In short, it does differ in a way that the driver > > needs to understand the difference and act differently with each of the > > unique transports defined in the binding. > > > > Hope that explains and addresses your concern. > > Thanks for the elaborate answer. I see now why it's beneficial to have > an OP-TEE transport in general. I don't yet see the benefit to use it > in the STM32MP13x instead of SMCs like with STM32MP15x, but that a discussion > that I need to have in the aforementioned thread. Some SCMI operations in OP-TEE need to execute in a threaded context (preemptible, ...). There is no SMC function ID defined for an SCMI thread entry in OP-TEE. We rather use standard invocation of a TEE service: opening a session and invoking commands. Invoked commands are executed in an OP-TEE native threaded context. The service accessed is referred to as the OP-TEE SCMI PTA. As for STM32MP15x, one willing to extend resources assigned to secure world may also need to move mp15 SCMI from SMC transport to optee transport. Regards, Etienne > > Thanks again! > Ahmad > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel