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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 BC343C43603 for ; Tue, 10 Dec 2019 15:38:52 +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 8E9C0206D5 for ; Tue, 10 Dec 2019 15:38:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="HZgddjsp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8E9C0206D5 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=atomide.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:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=2dxX1tYv9QcWpTCp5UGajgfrd67o7QwIfSBhqS4OfQw=; b=HZgddjsptXBNBt hxIVq3YhkoEQY7/+oPZiOP2n0qGyOQzlR8Ng/wiWR4hDPofwvqKqiK1+o1x2qQ4Vji/wTUPSEdq2v /sJkDcln5ohfm+W2lndN5bh29F+F8NtXM8d+kcnf1KheAwEf/fST34EvQ2oVivJSvY4PFP6yFa9MX Q388OkmP+Ak9RLSGbTYWwqfGa0jLlvZDqEF5Db1ywgPtH2gKKI66W86mHFnzJa1f/aiWMo7AuxHlt Aft0TZrXQsLbYYMUB/BL+x46/yD29lxPaWmA5K2LnewShYNcRYSJMtMrTDeVRSjQpt+oDEvtgREId J0Mtueja3MUmxPKCSuMA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iehb8-0004LC-ID; Tue, 10 Dec 2019 15:38:50 +0000 Received: from muru.com ([72.249.23.125]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iehb5-0004Kd-Jd for linux-arm-kernel@lists.infradead.org; Tue, 10 Dec 2019 15:38:49 +0000 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 04E6280E1; Tue, 10 Dec 2019 15:39:21 +0000 (UTC) Date: Tue, 10 Dec 2019 07:38:40 -0800 From: Tony Lindgren To: Jens Wiklander Subject: Re: arm_smccc_smc as generic smc interface? Message-ID: <20191210153840.GL35479@atomide.com> References: <20191209180752.GJ35479@atomide.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191210_073847_685673_CC25408E X-CRM114-Status: GOOD ( 22.39 ) 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: Mark Rutland , Sumit Garg , Arnd Bergmann , Volodymyr Babchuk , Catalin Marinas , "Andrew F. Davis" , Olof Johansson , Russell King , Marc Zyngier , Andy Gross , Colin Ian King , Will Deacon , Linux ARM 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 * Jens Wiklander [191210 08:10]: > Hi Tony, > > On Mon, Dec 9, 2019 at 7:07 PM Tony Lindgren wrote: > > > > Hi all, > > > > So it seems that we could make arm_smccc_smc() into a generic kernel > > smc interface instead of being limited to optee usage. That is > > assuming optee and legacy calls are never be enabled the same time > > on a booted system :) > > arm_smccc_smc() is not limited to OP-TEE only. A quick grep gives > quite a few places of which OP-TEE is just one. OK good to hear. > > I know arm_smccc_smc() currently assumes a specific register usage > > for the optee case, but AFAIK those limitations do not exist for > > non-optee cases. > > arm_smccc_smc() is for SMCs following SMC calling convention, see > http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html Hmm yes that's the part I'm wondering about. For older TI SoCs, in the non-optee cases, the TI smc calls do not follow the newer convention at least for r12 usage. For optee cases, TI SoCs follow the convention AFAIK. But assuming optee and non-optee are never active the same time, handling the TI r12 quirk for non-optee cases should not cause issues that I can think of. However, if we wanted to have arm_smccc_smc() bail out for non-optee cases for example, then it probably makes sense to move most of the arm_smccc_smc() into a more generic function like arm_smc(), and then have arm_smccc_smc() call arm_smc(). But AFAIK this should not be needed as the optee code would not be active in the non-optee case at all. > > Does anybody see some other issues with making arm_smccc_smc() into > > a generic smc call interface? > > I suppose that depends on what you mean with a generic smc call > interface. arm_smccc_smc() is quite generic already as I see it. :-) Yes it already has nice quirk handling and should work nicely to replace most of the SoC specific smc calls eventually :) > > If there are some more optee specific considerations with making > > arm_smccc_smc() into a generic interface, we could just set up > > something generic that also arm_smccc_smc() can then call. > > OP-TEE is relying on SMC calling convention > http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html Yes and the earlier non-optee smc cases may or may not follow it. > > The use case I'm familiar with are the old TI smc calls that need > > register specific quirks enabled only for the non-optee case, > > while with optee enabled, quirks are not needed. There are > > probably similar issues with other SoCs too. > > I'm not too familiar with those. There's a few of them in the OP-TEE > code base too, so at least some of them can be handled via the SMC > calling convention. > > In there's already been made room for some Qualcomm > quirks, perhaps it's possible to use or extend it to cover the TI > cases you have in mind. Yeah that's my thinking too as long as there are no issues using arm_smccc_smc() for non-optee cases. Regards, Tony _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel