From patchwork Thu Mar 19 13:03:47 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 229061 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=-9.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham 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 577EBC4332E for ; Thu, 19 Mar 2020 13:22:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2C581206D7 for ; Thu, 19 Mar 2020 13:22:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584624154; bh=pedXLTfJpQVGrJP7cjM0hvFmyCL6sf5H6VR6PRA7Ru4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=EMaay5SDbPMv+aNkS9fnQ4w+qKVocxvnzqjQLmkLR+s9xiAS/+oYplqhvL2DvW4lQ 49o5SeErah5fcOUhCiW5Le30xHVbkyNVrxDSDjWh9GPXS5xR4Dgqj50NF5/WlqBm1p 1Uz5VKkviL+y+x4sNbiE56Dn7FP9Im0rve8j5TJY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730209AbgCSNWd (ORCPT ); Thu, 19 Mar 2020 09:22:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:47948 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728266AbgCSNWc (ORCPT ); Thu, 19 Mar 2020 09:22:32 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7A867206D7; Thu, 19 Mar 2020 13:22:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584624152; bh=pedXLTfJpQVGrJP7cjM0hvFmyCL6sf5H6VR6PRA7Ru4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=zLl+vbm/d7CYWVHUOHOmhPQton5rzDMZDy/6Rizm6MRVu8PENE4hbY57KIad1ubcs r5hxyR2jIgS3s3sErbdvLz+all9JUNfBlh38Kqv+yTC4GgellHmJ1cNI15PTdbzovE JFh5CrzlNTyHwqU/y/VhF+qV3NB2sxLdTq6guhnI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sowjanya Komatineni , Anders Roxell , Faiz Abbas , Peter Geis , Ulf Hansson , Sasha Levin Subject: [PATCH 5.4 09/60] mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for erase/trim/discard Date: Thu, 19 Mar 2020 14:03:47 +0100 Message-Id: <20200319123922.147166477@linuxfoundation.org> X-Mailer: git-send-email 2.25.2 In-Reply-To: <20200319123919.441695203@linuxfoundation.org> References: <20200319123919.441695203@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Ulf Hansson [ Upstream commit 43cc64e5221cc6741252b64bc4531dd1eefb733d ] The busy timeout that is computed for each erase/trim/discard operation, can become quite long and may thus exceed the host->max_busy_timeout. If that becomes the case, mmc_do_erase() converts from using an R1B response to an R1 response, as to prevent the host from doing HW busy detection. However, it has turned out that some hosts requires an R1B response no matter what, so let's respect that via checking MMC_CAP_NEED_RSP_BUSY. Note that, if the R1B gets enforced, the host becomes fully responsible of managing the needed busy timeout, in one way or the other. Suggested-by: Sowjanya Komatineni Cc: Tested-by: Anders Roxell Tested-by: Sowjanya Komatineni Tested-by: Faiz Abbas Tested-By: Peter Geis Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin --- drivers/mmc/core/core.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index abf8f5eb0a1c8..26644b7ec13e3 100644 --- a/drivers/mmc/core/core.c +++ b/drivers/mmc/core/core.c @@ -1732,8 +1732,11 @@ static int mmc_do_erase(struct mmc_card *card, unsigned int from, * the erase operation does not exceed the max_busy_timeout, we should * use R1B response. Or we need to prevent the host from doing hw busy * detection, which is done by converting to a R1 response instead. + * Note, some hosts requires R1B, which also means they are on their own + * when it comes to deal with the busy timeout. */ - if (card->host->max_busy_timeout && + if (!(card->host->caps & MMC_CAP_NEED_RSP_BUSY) && + card->host->max_busy_timeout && busy_timeout > card->host->max_busy_timeout) { cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_AC; } else {