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=-6.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 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 3C750C18E5B for ; Mon, 16 Mar 2020 11:33:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 10DA220769 for ; Mon, 16 Mar 2020 11:33:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584358409; bh=b74DfLY2zpcJ87nNw65XfmqaEx03rJWo7xk1PaXlozk=; h=Subject:To:Cc:From:Date:List-ID:From; b=dfTsXfK46aodmJZsT+LmQH3MkHZz8cQU8hV6a7G4KN+pxOA/uk0KhUe/OZBh7uUXq ZlGN0wJ61oEsyb1mUu6ZtWbgsYKiMF8geD7iI0H+0zO0PJDzqhCnsMXTwC0j7CDLzN yFbmkTZk9+aavJbJlGijfDxXiqw6Zo/zFJLqmKHU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730836AbgCPLd2 (ORCPT ); Mon, 16 Mar 2020 07:33:28 -0400 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:46247 "EHLO wout1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730783AbgCPLd2 (ORCPT ); Mon, 16 Mar 2020 07:33:28 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 9FA875E8; Mon, 16 Mar 2020 07:33:27 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 16 Mar 2020 07:33:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=bp5EUG cJM9s/+uX30O9FU+0zZblhuYqA+auHvJrFw+8=; b=Tgr5q2s3wbxSanGqb+ZIek l+tpsrnsmwHyTtnK4ga0RGHwVlAMfbdRjbC3DXLGzYv794JQTQbZx8iDCDfihyny yFM3a3PEd90gcpoEPCG2ygFQONhFuxubW3tKhTEiSXlPrdz/g8GOiowd4zNbqY+8 zQtjNn64Hubmuj/+qvt+f+O7F06rp8d2MnaGubZj9oPz95axLCm81aTM01W1OOqj 4n4z9tH/KMR5unaCKZelC+0+l/o4wpP2+NdzBD/KUx3V+0dO9ayqhxgN0TgeTaiO nt+IK8dEhwDIUGRHSjw4kOWkx+YJEi9zh1RUMIUrYzTndaPtuoDbQxaspNzOwZ4Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudeffedgvdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvffhfffkgggtgfesthekredttd dtlfenucfhrhhomhepoehgrhgvghhkhheslhhinhhugihfohhunhgurghtihhonhdrohhr gheqnecukfhppeekfedrkeeirdekledruddtjeenucevlhhushhtvghrufhiiigvpedune curfgrrhgrmhepmhgrihhlfhhrohhmpehgrhgvgheskhhrohgrhhdrtghomh X-ME-Proxy: Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) by mail.messagingengine.com (Postfix) with ESMTPA id DF9533280059; Mon, 16 Mar 2020 07:33:26 -0400 (EDT) Subject: FAILED: patch "[PATCH] mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for" failed to apply to 5.5-stable tree To: ulf.hansson@linaro.org, anders.roxell@linaro.org, faiz_abbas@ti.com, pgwipeout@gmail.com, skomatineni@nvidia.com, stable@vger.kernel.org Cc: From: Date: Mon, 16 Mar 2020 12:33:22 +0100 Message-ID: <1584358402184154@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org The patch below does not apply to the 5.5-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 43cc64e5221cc6741252b64bc4531dd1eefb733d Mon Sep 17 00:00:00 2001 From: Ulf Hansson Date: Tue, 10 Mar 2020 14:43:00 +0100 Subject: [PATCH] mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for erase/trim/discard 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 diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index aa54d359dab7..a971c4bcc442 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 {