From patchwork Fri Apr 18 02:30:14 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Elder X-Patchwork-Id: 4012921 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 76D1EBFF02 for ; Fri, 18 Apr 2014 02:33:50 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 9374020328 for ; Fri, 18 Apr 2014 02:33:49 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C49CB202EC for ; Fri, 18 Apr 2014 02:33:48 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Wayae-0005Vf-FO; Fri, 18 Apr 2014 02:31:44 +0000 Received: from mail-ig0-f169.google.com ([209.85.213.169]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WayZh-0004SV-Nz for linux-arm-kernel@lists.infradead.org; Fri, 18 Apr 2014 02:30:46 +0000 Received: by mail-ig0-f169.google.com with SMTP id h18so586880igc.2 for ; Thu, 17 Apr 2014 19:30:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=n4Q+DgprJwKG7z27/hKCtUACIRu0tBWadugsp9cc9kM=; b=CFcWMABCwy8PjD58H5k6pymIEtdYJ7gwf0z6O3IkMnigvFvdGYKE1LU/nG1DGd478k S8Q0yke7jgRA2ovwuN2yP22gJIWC5qXGi/EDH972+GTHEpjxi2yiU2y8A7UzDqdcW1fW YAj74SovWofKOKTw9fj6cO7WPH9Vo/8dqi/om0v5cNNXDXQz6Sj/8cLU1XULyGOOA90M HUfbmbpXyW4g/BTtVyo72yA2Ui86xcfED+H3Tu/IpHfloISlmw58dKaG8CDpymM0haB4 Uqa/sDTx0gux2+Mfm4lNGGbk/l3FNfmM9WHaJ0zzRsAWXKJSBGq1mG2bgVlTtwpC17Uu IWPg== X-Gm-Message-State: ALoCoQkM5OJtrkL9mqnBe8vQI5HHcRxDbQZcCkE1sJPOmq4c8CYlKGlqoc1YKqcXCgHnv+0jDZV/ X-Received: by 10.50.109.130 with SMTP id hs2mr782074igb.29.1397788226792; Thu, 17 Apr 2014 19:30:26 -0700 (PDT) Received: from localhost.localdomain (c-71-195-31-37.hsd1.mn.comcast.net. [71.195.31.37]) by mx.google.com with ESMTPSA id m8sm673967igx.9.2014.04.17.19.30.25 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 19:30:26 -0700 (PDT) From: Alex Elder To: bcm@fixthebug.org, mporter@linaro.org Subject: [PATCH 09/10] ARM: bcm: rewrite commentary for bcm_kona_do_smc() Date: Thu, 17 Apr 2014 21:30:14 -0500 Message-Id: <1397788215-20279-10-git-send-email-elder@linaro.org> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <1397788215-20279-1-git-send-email-elder@linaro.org> References: <1397788215-20279-1-git-send-email-elder@linaro.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140417_193045_842541_A07512D2 X-CRM114-Status: GOOD ( 16.68 ) X-Spam-Score: -0.7 (/) Cc: bcm-kernel-feedback-list@broadcom.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The block of comments in bcm_kona_do_smc() are somewhat confusing. This patch attempts to clarify what's going on. Signed-off-by: Alex Elder Reviewed-by: Tim Kryger Reviewed-by: Markus Mayer Reviewed-by: Matt Porter --- arch/arm/mach-bcm/bcm_kona_smc.c | 38 ++++++++++++++++++++++++++++---------- 1 file changed, 28 insertions(+), 10 deletions(-) diff --git a/arch/arm/mach-bcm/bcm_kona_smc.c b/arch/arm/mach-bcm/bcm_kona_smc.c index cc81c86..a55a7ec 100644 --- a/arch/arm/mach-bcm/bcm_kona_smc.c +++ b/arch/arm/mach-bcm/bcm_kona_smc.c @@ -77,16 +77,34 @@ int __init bcm_kona_smc_init(void) } /* - * Since interrupts are disabled in the open mode, we must keep - * interrupts disabled in secure mode by setting R5=0x3. If interrupts - * are enabled in open mode, we can set R5=0x0 to allow interrupts in - * secure mode. If we did this, the secure monitor would return back - * control to the open mode to handle the interrupt prior to completing - * the secure service. If this happened, R12 would not be - * SEC_EXIT_NORMAL and we would need to call SMC again after resetting - * R5 (it gets clobbered by the secure monitor) and setting R4 to - * SSAPI_RET_FROM_INT_SERV to indicate that we want the secure monitor - * to finish up the previous uncompleted secure service. + * int bcm_kona_do_smc(u32 service_id, u32 buffer_addr) + * + * Only core 0 can run the secure monitor code. If an "smc" request + * is initiated on a different core it must be redirected to core 0 + * for execution. We rely on the caller to handle this. + * + * Each "smc" request supplies a service id and the address of a + * buffer containing parameters related to the service to be + * performed. A flags value defines the behavior of the level 2 + * cache and interrupt handling while the secure monitor executes. + * + * Parameters to the "smc" request are passed in r4-r6 as follows: + * r4 service id + * r5 flags (SEC_ROM_*) + * r6 physical address of buffer with other parameters + * + * Execution of an "smc" request produces two distinct results. + * + * First, the secure monitor call itself (regardless of the specific + * service request) can succeed, or can produce an error. When an + * "smc" request completes this value is found in r12; it should + * always be SEC_EXIT_NORMAL. + * + * In addition, the particular service performed produces a result. + * The values that should be expected depend on the service. We + * therefore return this value to the caller, so it can handle the + * request result appropriately. This result value is found in r0 + * when the "smc" request completes. */ static int bcm_kona_do_smc(u32 service_id, u32 buffer_phys) {