From patchwork Mon Jul 8 15:43:58 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sudeep Holla X-Patchwork-Id: 168672 Delivered-To: patch@linaro.org Received: by 2002:a92:4782:0:0:0:0:0 with SMTP id e2csp7327272ilk; Mon, 8 Jul 2019 08:44:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqxgT72oary1IlvzbYAp12T37X2e/cqN+rkHEtAH7iMSMc9wRSeJTf1IuEKtYdxeSGp73pdb X-Received: by 2002:a17:90a:9905:: with SMTP id b5mr27171601pjp.70.1562600669162; Mon, 08 Jul 2019 08:44:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562600669; cv=none; d=google.com; s=arc-20160816; b=pxdlob6SpBvhSXgP7NRhoUFKSebQ1wP5oqXnpUqLlTM5CovgTMuhnfIoq7HmT1Y2Hh NVH8rsVRjMawXtvghLk2tAvCMlMgagrniXhtG6wj1gIHBeeAAD1zri74SSagHtQYW91E S/ihKvdyxE6eLFk7x2FBCEu36Pu3pTFaT9ZCaZ2la9UnybYwuj/u99Egb1EsB1yth3fF 6whjMFK1O+PUBfBjzxZ6subC8OrCwIm/GlMHKJ+w7cNDV8zJ1JIG1Vm1ABSPBW4/bujh yhUHB05eXeVZc8t+n0H++UhcBfZNoxtJV7bFvec0r/pImIf1bntqQSF3ecr7I1XTFmOi xpRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=X1ffVu6Vb8FU1aen0pD8PW3t8MRrTZq2juCamyoHnXM=; b=dwVo/szBndYyw9bo2FAK2imv34uMmfKQZPl2B77QNL/ElfyNUggfXvf55KhVqpG58i 04b5AwphE6k6yCYNWy2laWacenanuEEFXcHRNyZrORnw0m3joYJZkPNbMdGa3J7v0Nd9 XuN76t3NsNgkj7wqfq+CTA5GIv7hE6I7nRDku8B3zpdT0zv5mClvXEQNsArV4pQ3eR/u v+DvxrO19ccLzMu/fdzOy4X9JwKcEZAKVR75t1o79/bfFVx9rsKsw7Jqgf4OwK8Drluo 39HzKXOL4/Wcr9iYGgx+2jK85cNYhJBZ2aHT67JzaEN0iRu0ziQ8f3BKWFbjU+own0ZB 0frQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m5si17362557plt.167.2019.07.08.08.44.28; Mon, 08 Jul 2019 08:44:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391234AbfGHPo2 (ORCPT + 30 others); Mon, 8 Jul 2019 11:44:28 -0400 Received: from foss.arm.com ([217.140.110.172]:52064 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2403861AbfGHPoO (ORCPT ); Mon, 8 Jul 2019 11:44:14 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 50670360; Mon, 8 Jul 2019 08:44:14 -0700 (PDT) Received: from usa.arm.com (e107155-lin.cambridge.arm.com [10.1.196.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 4D5A23F59C; Mon, 8 Jul 2019 08:44:13 -0700 (PDT) From: Sudeep Holla To: linux-arm-kernel@lists.infradead.org Cc: Sudeep Holla , linux-kernel@vger.kernel.org, Peng Fan , Jim Quinlan , Bo Zhang , Volodymyr Babchuk Subject: [PATCH 6/6] firmware: arm_scmi: Check if platform has released shmem before using Date: Mon, 8 Jul 2019 16:43:58 +0100 Message-Id: <20190708154358.16227-7-sudeep.holla@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20190708154358.16227-1-sudeep.holla@arm.com> References: <20190708154358.16227-1-sudeep.holla@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sometimes platfom may take too long to respond to the command and OS might timeout before platform transfer the ownership of the shared memory region to the OS with the response. Since the mailbox channel associated with the channel is freed and new commands are dispatch on the same channel, OS needs to wait until it gets back the ownership. If not, either OS may end up overwriting the platform response for the last command(which is fine as OS timed out that command) or platform might overwrite the payload for the next command with the response for the old. The latter is problematic as platform may end up interpretting the response as the payload. In order to avoid such race, let's wait until the OS gets back the ownership before we prepare the shared memory with the payload for the next command. Reported-by: Jim Quinlan Signed-off-by: Sudeep Holla --- drivers/firmware/arm_scmi/driver.c | 8 ++++++++ 1 file changed, 8 insertions(+) -- 2.17.1 diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c index 69bf85fea967..765573756987 100644 --- a/drivers/firmware/arm_scmi/driver.c +++ b/drivers/firmware/arm_scmi/driver.c @@ -265,6 +265,14 @@ static void scmi_tx_prepare(struct mbox_client *cl, void *m) struct scmi_chan_info *cinfo = client_to_scmi_chan_info(cl); struct scmi_shared_mem __iomem *mem = cinfo->payload; + /* + * Ideally channel must be free by now unless OS timeout last + * request and platform continued to process the same, wait + * until it releases the shared memory, otherwise we may endup + * overwriting it's response with new command payload or vice-versa + */ + spin_until_cond(ioread32(&mem->channel_status) & + SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE); /* Mark channel busy + clear error */ iowrite32(0x0, &mem->channel_status); iowrite32(t->hdr.poll_completion ? 0 : SCMI_SHMEM_FLAG_INTR_ENABLED,