Received: by 2002:a89:d88:0:b0:1fa:5c73:8e2d with SMTP id eb8csp249481lqb; Thu, 23 May 2024 17:50:56 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCU1kNQmq11Bxv5cUxqiWc9M1kchIiDSFWdSUK/IxT/CtVKlikMvzm5sWnHETJqfUTr6JssgubYoyOWxPU2X3dHFL7GdWaPy/Qqe0rJhdQ== X-Google-Smtp-Source: AGHT+IGmwxCP8UZlT0WsevZGOQBfOooNsT7VyM2Sqnh+4VEKgMnCns6+X3Cg350Py26fxbAbsQ3O X-Received: by 2002:a05:6218:2615:b0:183:86c4:75d0 with SMTP id e5c5f4694b2df-197e50d264cmr129168055d.8.1716511855910; Thu, 23 May 2024 17:50:55 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1716511855; cv=pass; d=google.com; s=arc-20160816; b=ePKSFJa9DdyW58nwbwTIHqzGGhFmPxyqTdGWMveKDJJl+sAf0QpijQK9Dxi9uJghLb N8zDs2mG37Vmg6Ms+feBt5pB8pVaPuRl28455n/S7wQS+AFsZJ0/DNWc9vC6zWZlywXT z3vUgTzvSTMEud85RmfDNYib4zP3+HYmBuChXJzNoWYtZ5Nw1wl2xCRO65di4E1TZVvb YBX0YYzoj6lKNIquPUWz833eRwuGy9IIDA+s6z8L1rtkD0aYV+V7BCm0ZZhxaVFM+jVQ yP4jF0utuOmIEfMc6APw1osLmoPLjTPyaOMlQO7XADqL4D/w1cy6gTVFyljGF74I7yrl H+4g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature:dkim-filter; bh=u4B9YjddLr81pehQ1ILKrSeeCQyF7ZNefY7xse0k1/c=; fh=rvzDUbqnxlh8sEHDGz6auxZWwqvJl/BHQSKrXBRes0w=; b=IlMXGLVjjJB0GqJu6btJK2GxgkqX/qGUeZjjKO+NaOHdvQjyZsHVVkL9GICj/FxCtx eAr8knSIIKuTcbTfHlEePaGzD4mHZ3zU4sJ+P6j8LWIA8DNwzx0tEyZ95wzzbnS5iyiN E2ATAqUhEdAkWqfscOmcJBXHil+C58vg3cJs4q2UC0LwT60WqpMM5kL7ktol5xYdyWqI mJGUGaK/KZ2SCEtUid8Rl9oeEg58EgXb/6hhgVUnY/0Pmfiw4yC4eU7XIScEz9gEIbIv HNHmmw8740nEHpfJIwh12yOYrwb/NsvSpnikirA0olFskyLw4w5P9SQ1wwvcvr3lS9iC /Dtw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@broadcom.com header.s=dkimrelay header.b=ddYW0zlQ; arc=pass (i=1 dkim=pass dkdomain=broadcom.com dmarc=pass fromdomain=broadcom.com); spf=pass (google.com: domain of linux-kernel+bounces-188052-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-188052-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=broadcom.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id 41be03b00d2f7-682287f2263si269213a12.431.2024.05.23.17.50.55 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 May 2024 17:50:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-188052-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@broadcom.com header.s=dkimrelay header.b=ddYW0zlQ; arc=pass (i=1 dkim=pass dkdomain=broadcom.com dmarc=pass fromdomain=broadcom.com); spf=pass (google.com: domain of linux-kernel+bounces-188052-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-188052-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=broadcom.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id A655A280E23 for ; Thu, 23 May 2024 21:45:50 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 7192112836A; Thu, 23 May 2024 21:45:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="ddYW0zlQ" Received: from relay.smtp-ext.broadcom.com (relay.smtp-ext.broadcom.com [192.19.144.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5C6D46E60F; Thu, 23 May 2024 21:45:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.19.144.205 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716500737; cv=none; b=D/WEkqx8Dy8zKt9gRNjHz1PEEUcFIN/WW+OK1ecPoEV4B/SsacgRu0ZRTGoEpvRoBs73+UvYKO+6/x03HCxaU0EY5dDwbgxA8ORMesjCe77D/Vnj+CJzwg9N5xOgD/qWZbgKUm3hlvAA8fFLwpdgey0GlZbJqcDBkNcsJabWB0I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716500737; c=relaxed/simple; bh=nxI9GUQI9xmjhS4VdsyojRjaDCElzOSfZ+Uo6mDYmqE=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=tFLHfjP9osHCj7+7Mrkdbx9E4dGHa7Tsm64kG9d79qr0rQYqh+6pPhLKVyPNb8kWzrbePp87vdc7lr8G40sZEW3mi/pn9j9N7DL0GQwW+g/BcyWP1siZjwvA3xv0Y88RCeRDS8pj0OQdluvCyt2YauYFhjUtb/u50BiKCimeSlo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=broadcom.com; spf=fail smtp.mailfrom=broadcom.com; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b=ddYW0zlQ; arc=none smtp.client-ip=192.19.144.205 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=broadcom.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=broadcom.com Received: from mail-lvn-it-01.lvn.broadcom.net (mail-lvn-it-01.lvn.broadcom.net [10.36.132.253]) by relay.smtp-ext.broadcom.com (Postfix) with ESMTP id 38296C0000F5; Thu, 23 May 2024 14:45:28 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 relay.smtp-ext.broadcom.com 38296C0000F5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=broadcom.com; s=dkimrelay; t=1716500728; bh=nxI9GUQI9xmjhS4VdsyojRjaDCElzOSfZ+Uo6mDYmqE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ddYW0zlQFF8lhdVDeVJqW2jvABOOHqnZfEX6VfYir6IS/z5bmfrZPmARGU8i0kV8l IFFaULD/D3yZBr52Kz4Nj1hawdKjbJTiH4psZf8BeP0GNdrD4MA3VE0WNAgapWJgsB P2EuakqEltATyRaiDPPVab51Uxl6ThQv22Vr9ubc= Received: from stbirv-lnx-1.igp.broadcom.net (stbirv-lnx-1.igp.broadcom.net [10.67.48.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail-lvn-it-01.lvn.broadcom.net (Postfix) with ESMTPSA id 3690118041CAC6; Thu, 23 May 2024 14:45:26 -0700 (PDT) From: Florian Fainelli To: stable@vger.kernel.org Cc: Jorge Ramirez-Ortiz , Avri Altman , Adrian Hunter , Ulf Hansson , Florian Fainelli , Greg Kroah-Hartman , Geert Uytterhoeven , linux-mmc@vger.kernel.org (open list:MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND...), linux-kernel@vger.kernel.org (open list) Subject: [PATCH stable 5.10] mmc: core: Do not force a retune before RPMB switch Date: Thu, 23 May 2024 14:45:21 -0700 Message-Id: <20240523214525.200347-2-florian.fainelli@broadcom.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240523214525.200347-1-florian.fainelli@broadcom.com> References: <20240523214525.200347-1-florian.fainelli@broadcom.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Jorge Ramirez-Ortiz commit 67380251e8bbd3302c64fea07f95c31971b91c22 upstream Requesting a retune before switching to the RPMB partition has been observed to cause CRC errors on the RPMB reads (-EILSEQ). Since RPMB reads can not be retried, the clients would be directly affected by the errors. This commit disables the retune request prior to switching to the RPMB partition: mmc_retune_pause() no longer triggers a retune before the pause period begins. This was verified with the sdhci-of-arasan driver (ZynqMP) configured for HS200 using two separate eMMC cards (DG4064 and 064GB2). In both cases, the error was easy to reproduce triggering every few tenths of reads. With this commit, systems that were utilizing OP-TEE to access RPMB variables will experience an enhanced performance. Specifically, when OP-TEE is configured to employ RPMB as a secure storage solution, it not only writes the data but also the secure filesystem within the partition. As a result, retrieving any variable involves multiple RPMB reads, typically around five. For context, on ZynqMP, each retune request consumed approximately 8ms. Consequently, reading any RPMB variable used to take at the very minimum 40ms. After droping the need to retune before switching to the RPMB partition, this is no longer the case. Signed-off-by: Jorge Ramirez-Ortiz Acked-by: Avri Altman Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20240103112911.2954632-1-jorge@foundries.io Signed-off-by: Ulf Hansson Signed-off-by: Florian Fainelli --- drivers/mmc/core/host.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c index b949a4468bf5..7ba1343ca5c1 100644 --- a/drivers/mmc/core/host.c +++ b/drivers/mmc/core/host.c @@ -114,13 +114,12 @@ void mmc_retune_enable(struct mmc_host *host) /* * Pause re-tuning for a small set of operations. The pause begins after the - * next command and after first doing re-tuning. + * next command. */ void mmc_retune_pause(struct mmc_host *host) { if (!host->retune_paused) { host->retune_paused = 1; - mmc_retune_needed(host); mmc_retune_hold(host); } } -- 2.34.1