Message ID | dd632a86fb924b019d1a009b17eb3cbc@hyperstone.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp2930390wrr; Wed, 23 Nov 2022 09:43:58 -0800 (PST) X-Google-Smtp-Source: AA0mqf7r0ankrUTc/LEmfeoQaW1xd1B3V+877YbXYDtfulr4ORN3AAKjBqjQDa5IB8v9NXZR9Xnk X-Received: by 2002:a05:6402:1aca:b0:469:701b:588d with SMTP id ba10-20020a0564021aca00b00469701b588dmr8855983edb.384.1669225438727; Wed, 23 Nov 2022 09:43:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669225438; cv=none; d=google.com; s=arc-20160816; b=Q3BIa8Z1AxBfEEvGc7D7EYIsM+okhkiqPovk2XQt76kCuKrFDkt/45X4Qr/XwXGkb5 oLYGrY4j2LtQjfb+3P4b2U+yXY5iol4VmmeawWugRMXQkjRA2dEC5W7PvktonGS25TVA UO3Bk1jfvvRV0JJdmDFOVtSoq5aMPNWNUk6sdCDMngViDbz85HL6dM4YynV0ktrizDIP fiNUzFqUKQsqMCDcV+W0bm9HWUc8PkWj986LPB5RsoWYX/aMoN7i1q45lPRvlPZVEOTX 6SWA/Tn9/nJyC9fBpdH0r5q1LKrSJsqdLxPvAkVr3X/yuCGPdIieTLgs4i1M3lWCW11Y RX6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :content-language:accept-language:message-id:date:thread-index :thread-topic:subject:cc:to:from; bh=Ai+XyQpYrBx5Rb/NdY67LhgmmlfDOshacuNJcqdfnw0=; b=qFLPiRblbu/8w3GQmbnFO5lD2Or1zWYrAOXkSDvb7REeZRmebQDxtvXrGgfaoLUhI/ yBNG5Am7T9llFQa1xqyNwViW6Re1h0UaEdYadwau+cQqeNKRlxkeJ2IXtNX6syxvYXnD IMNsXoksxZl2/dWuvY6wRJXJWX20kw/+VgiufbpMyRDYFGtpcPSU+ZHhFEaMbXYPqzS9 b1KIQOXMkR1zZScLO63anIYCvmQjTF3fGqosyvHDJt3HuZcCrSTwgBWBpwZ7ikm42SBo V8w806VWqFEFet1QQyL8swJhnabvbBv2ChUDrpv4WCFxgRLWEPLZqKPhJJmOHYsS1H8y tEag== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hyperstone.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s6-20020a170906bc4600b007add164bc81si8664364ejv.222.2022.11.23.09.43.31; Wed, 23 Nov 2022 09:43:58 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hyperstone.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238891AbiKWRjF convert rfc822-to-8bit (ORCPT <rfc822;fengqi706@gmail.com> + 99 others); Wed, 23 Nov 2022 12:39:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58520 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237549AbiKWRjD (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 23 Nov 2022 12:39:03 -0500 Received: from mail4.swissbit.com (mail4.swissbit.com [176.95.1.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C52D55657A; Wed, 23 Nov 2022 09:38:59 -0800 (PST) Received: from mail4.swissbit.com (localhost [127.0.0.1]) by DDEI (Postfix) with ESMTP id 78D211234CB; Wed, 23 Nov 2022 18:38:57 +0100 (CET) Received: from mail4.swissbit.com (localhost [127.0.0.1]) by DDEI (Postfix) with ESMTP id 623A8121C79; Wed, 23 Nov 2022 18:38:57 +0100 (CET) X-TM-AS-ERS: 10.149.2.42-127.5.254.253 X-TM-AS-SMTP: 1.0 ZXguc3dpc3NiaXQuY29t Y2xvZWhsZUBoeXBlcnN0b25lLmNvbQ== X-DDEI-TLS-USAGE: Used Received: from ex.swissbit.com (unknown [10.149.2.42]) by mail4.swissbit.com (Postfix) with ESMTPS; Wed, 23 Nov 2022 18:38:57 +0100 (CET) Received: from sbdeex04.sbitdom.lan (10.149.2.42) by sbdeex04.sbitdom.lan (10.149.2.42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.9; Wed, 23 Nov 2022 18:38:56 +0100 Received: from sbdeex04.sbitdom.lan ([fe80::2047:4968:b5a0:1818]) by sbdeex04.sbitdom.lan ([fe80::2047:4968:b5a0:1818%9]) with mapi id 15.02.1118.009; Wed, 23 Nov 2022 18:38:56 +0100 From: =?iso-8859-1?q?Christian_L=F6hle?= <CLoehle@hyperstone.com> To: "adrian.hunter@intel.com" <adrian.hunter@intel.com>, "ulf.hansson@linaro.org" <ulf.hansson@linaro.org>, "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> CC: Avri Altman <Avri.Altman@wdc.com> Subject: [PATCH] mmc: block: remove non-data R1B ioctl workaround Thread-Topic: [PATCH] mmc: block: remove non-data R1B ioctl workaround Thread-Index: Adj/YjUrXkzlUmHATlmcTHF+6XwQXw== Date: Wed, 23 Nov 2022 17:38:56 +0000 Message-ID: <dd632a86fb924b019d1a009b17eb3cbc@hyperstone.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.153.4.23] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-TMASE-Version: DDEI-5.1-9.0.1002-27282.001 X-TMASE-Result: 10-4.657200-10.000000 X-TMASE-MatchedRID: ge9e+QLSeayzwwnlAhUjjJAk4Vz6rKorI64EUz6lBagHMdltgqikB9AY WUo4HSIkhw5E/ZidsH8ep5R/z/M+R+ztpCSqSkXKSHCU59h5KrHVBDonH99+Vtm24hViZXUPKJp KpGmR8G37pkcZlMac521ZdkOX+yj7BXY0oXpqJ14ReM8i8p3vgEyQ5fRSh265855M88ee2L/ovF l9K5XN2X69Y7ea2kurrCdjRFVGO+toMCLywE0ygQtuKBGekqUpI/NGWt0UYPDKS2C7UIL4TmvpM +0rLfKmp6aDqxA3fahFehRbIllwo+0DVTpPbBPr X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 X-TMASE-INERTIA: 0-0;;;; X-TMASE-XGENCLOUD: 4509e344-abd3-486d-bfc7-c1c6ea2d3b2a-0-0-200-0 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750309733611657422?= X-GMAIL-MSGID: =?utf-8?q?1750309733611657422?= |
Series |
mmc: block: remove non-data R1B ioctl workaround
|
|
Commit Message
Christian Loehle
Nov. 23, 2022, 5:38 p.m. UTC
The workaround of pretending R1B non-data transfers are
data transfers in order for the busy timeout to be respected
by the host controller driver is removed. It wasn't useful
in a long time.
Initially the workaround ensured that R1B commands did not
time out by setting the data timeout to be the command timeout
in commit cb87ea28ed9e ("mmc: core: Add mmc CMD+ACMD passthrough ioctl").
This was moved inside of an if clause with idata->buf_bytes being set
in commit 4d6144de8ba2 ("mmc: core: check for zero length ioctl data").
This patch intends to fix the issuing of R1B data command CMD24.
Its data timeout was being overwritten with 0 because cmd_timeout
wasn't set at the point the workaround applied, but data_timeout was.
But since the workaround was now inside of the idata->buf_bytes clause
and intended to fix R1B non-data transfers that do not have buf_bytes
set we can also remove the workaround altogether.
Fixes: cb87ea28ed9e ("mmc: core: Add mmc CMD+ACMD passthrough ioctl")
Signed-off-by: Christian Loehle <cloehle@hyperstone.com>
---
drivers/mmc/core/block.c | 13 -------------
1 file changed, 13 deletions(-)
Comments
> The workaround of pretending R1B non-data transfers are data transfers in > order for the busy timeout to be respected by the host controller driver is > removed. It wasn't useful in a long time. > > Initially the workaround ensured that R1B commands did not time out by > setting the data timeout to be the command timeout in commit > cb87ea28ed9e ("mmc: core: Add mmc CMD+ACMD passthrough ioctl"). > This was moved inside of an if clause with idata->buf_bytes being set in > commit 4d6144de8ba2 ("mmc: core: check for zero length ioctl data"). > This patch intends to fix the issuing of R1B data command CMD24. CMD24 response is R1? > Its data timeout was being overwritten with 0 because cmd_timeout wasn't > set at the point the workaround applied, but data_timeout was. > But since the workaround was now inside of the idata->buf_bytes clause and > intended to fix R1B non-data transfers that do not have buf_bytes set we can > also remove the workaround altogether. I find the above explanation a bit confusing. Maybe just explain in 1 or 2 sentences why this workaround is no longer needed? Thanks, Avri > > Fixes: cb87ea28ed9e ("mmc: core: Add mmc CMD+ACMD passthrough ioctl") > Signed-off-by: Christian Loehle <cloehle@hyperstone.com> > --- > drivers/mmc/core/block.c | 13 ------------- > 1 file changed, 13 deletions(-) > > diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c index > db6d8a099910..20da7ed43e6d 100644 > --- a/drivers/mmc/core/block.c > +++ b/drivers/mmc/core/block.c > @@ -514,19 +514,6 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card > *card, struct mmc_blk_data *md, > if (idata->ic.data_timeout_ns) > data.timeout_ns = idata->ic.data_timeout_ns; > > - if ((cmd.flags & MMC_RSP_R1B) == MMC_RSP_R1B) { > - /* > - * Pretend this is a data transfer and rely on the > - * host driver to compute timeout. When all host > - * drivers support cmd.cmd_timeout for R1B, this > - * can be changed to: > - * > - * mrq.data = NULL; > - * cmd.cmd_timeout = idata->ic.cmd_timeout_ms; > - */ > - data.timeout_ns = idata->ic.cmd_timeout_ms * 1000000; > - } > - > mrq.data = &data; > } > > -- > 2.37.3 > > Hyperstone GmbH | Reichenaustr. 39a | 78467 Konstanz Managing Director: > Dr. Jan Peter Berns. > Commercial register of local courts: Freiburg HRB381782
-----Original Message----- From: Avri Altman <Avri.Altman@wdc.com> Sent: Samstag, 26. November 2022 21:18 To: Christian Löhle <CLoehle@hyperstone.com>; adrian.hunter@intel.com; ulf.hansson@linaro.org; linux-mmc@vger.kernel.org; linux-kernel@vger.kernel.org Subject: RE: [PATCH] mmc: block: remove non-data R1B ioctl workaround >> The workaround of pretending R1B non-data transfers are data transfers >> in order for the busy timeout to be respected by the host controller >> driver is removed. It wasn't useful in a long time. >> >> Initially the workaround ensured that R1B commands did not time out by >> setting the data timeout to be the command timeout in commit >> cb87ea28ed9e ("mmc: core: Add mmc CMD+ACMD passthrough ioctl"). >> This was moved inside of an if clause with idata->buf_bytes being set >> in commit 4d6144de8ba2 ("mmc: core: check for zero length ioctl data"). >> This patch intends to fix the issuing of R1B data command CMD24. > CMD24 response is R1? Yes my bad, that was a relic of my userspace program to poll for busy. In that case see below. > >> Its data timeout was being overwritten with 0 because cmd_timeout >> wasn't set at the point the workaround applied, but data_timeout was. >> But since the workaround was now inside of the idata->buf_bytes clause >> and intended to fix R1B non-data transfers that do not have buf_bytes >> set we can also remove the workaround altogether. > I find the above explanation a bit confusing. > Maybe just explain in 1 or 2 sentences why this workaround is no longer needed? My explanation could have been clearer if I understood why the original author chose this way. Maybe some host controller drivers did not call mmc_request_done until busy is no longer asserted if MMC_RSP_BUSY was set? Maybe also the workaround was never necessary at all (my guess). Why I think it can be removed: The workaround has been moved inside of the if (idata->buf_bytes) clause and is for R1B type command responses. There are no commands with R1B responses that invoke data transfer in either direction. The workaround is just dead code since commit 4d6144de8ba2 ("mmc: core: check for zero length ioctl data"). I will fix the commit message up a bit. > > Thanks, > Avri > >> >> Fixes: cb87ea28ed9e ("mmc: core: Add mmc CMD+ACMD passthrough ioctl") >> Signed-off-by: Christian Loehle <cloehle@hyperstone.com> >> --- >> drivers/mmc/core/block.c | 13 ------------- >> 1 file changed, 13 deletions(-) >> >> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c index >> db6d8a099910..20da7ed43e6d 100644 >> --- a/drivers/mmc/core/block.c >> +++ b/drivers/mmc/core/block.c >> @@ -514,19 +514,6 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card >> *card, struct mmc_blk_data *md, >> if (idata->ic.data_timeout_ns) >> data.timeout_ns = idata->ic.data_timeout_ns; >> >> - if ((cmd.flags & MMC_RSP_R1B) == MMC_RSP_R1B) { >> - /* >> - * Pretend this is a data transfer and rely on the >> - * host driver to compute timeout. When all host >> - * drivers support cmd.cmd_timeout for R1B, this >> - * can be changed to: >> - * >> - * mrq.data = NULL; >> - * cmd.cmd_timeout = idata->ic.cmd_timeout_ms; >> - */ >> - data.timeout_ns = idata->ic.cmd_timeout_ms * 1000000; >> - } >> - >> mrq.data = &data; >> } >> >> -- >> 2.37.3 >> >> Hyperstone GmbH | Reichenaustr. 39a | 78467 Konstanz Managing Director: >> Dr. Jan Peter Berns. >> Commercial register of local courts: Freiburg HRB381782 > > Hyperstone GmbH | Reichenaustr. 39a | 78467 Konstanz Managing Director: Dr. Jan Peter Berns. Commercial register of local courts: Freiburg HRB381782
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c index db6d8a099910..20da7ed43e6d 100644 --- a/drivers/mmc/core/block.c +++ b/drivers/mmc/core/block.c @@ -514,19 +514,6 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card *card, struct mmc_blk_data *md, if (idata->ic.data_timeout_ns) data.timeout_ns = idata->ic.data_timeout_ns; - if ((cmd.flags & MMC_RSP_R1B) == MMC_RSP_R1B) { - /* - * Pretend this is a data transfer and rely on the - * host driver to compute timeout. When all host - * drivers support cmd.cmd_timeout for R1B, this - * can be changed to: - * - * mrq.data = NULL; - * cmd.cmd_timeout = idata->ic.cmd_timeout_ms; - */ - data.timeout_ns = idata->ic.cmd_timeout_ms * 1000000; - } - mrq.data = &data; }