Received: by 10.223.185.116 with SMTP id b49csp6369763wrg; Wed, 28 Feb 2018 08:17:46 -0800 (PST) X-Google-Smtp-Source: AH8x226vPw2jilcoj8qpK43S9O2NBcOXvTc2Imd+d+/agRQ0IyvtrD+XwiXBOCHK8plZjWJVSbhw X-Received: by 10.99.95.81 with SMTP id t78mr14940680pgb.380.1519834666236; Wed, 28 Feb 2018 08:17:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519834666; cv=none; d=google.com; s=arc-20160816; b=lO7eVXtt9sXAjnFqq1hmLDT3Yfx0CrLWdceCfLqdMMdnryd8xXFhbuk3IHAn4ZeVPc Ql5v4t/J4to2pLHE4bxchZJQLhgLaxit+pmjLteY38638hR94YUcrtaBHvu5wG8gIQr4 jUU0hdRmX7hcCmtCnvhdNN+mA89LXUUBlBqrwBR95dvTzCcLgTdBuRbHrGGPc+X2zcGH g8sri4eZuTSvGEEs0GYpXHiFi9WjcOIKSQOElhXKyinWnQuNlKvvsvBToscG1azi9NGN lQIkiL8FVX7zPjH6MHwKIaRsOLErMQXvD3g0ZjrbZQFxKXB6JSPIwHFiVcehvRsIv+wU MdQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=zvBpIHRie1nVwvtmg7+iJyh689MPjBSDBOThb6nOkq0=; b=Y5rOjoNbO9w1a37tVA5D4uwa2kfa9ojtjLZ/6iJRWyphbd0LtCaqGFtL80OTR2UZPB IDy8ITEtLZRpaJcR5K60nUvIP5jhLvk6H0AMMWV1bCVYNodYJGvvuoG4pPTatOFyGgk1 olHgGsL+ta9LNWZjTaNeCPEAGrQARaqk8O7bjDMqhOaEvdvyPNZfjdtFW/xoi2H0oIj9 9i4QkF/2xbdTZlBhnEEIZjnWcZOuHx3VKplSlm07w7gfN1twH3oDIE5tkbaZic61CfgW ASpO2a9prL+33tIT5+xcuIDXTx3/RtTb6SRmE+k6DWlvWBIf76pM5J0v/KgCRFByHg8i kxOA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=JjHymLiM; dkim=fail header.i=@chromium.org header.s=google header.b=ZPJFwyHl; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d15-v6si1471486pln.186.2018.02.28.08.17.31; Wed, 28 Feb 2018 08:17:46 -0800 (PST) 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; dkim=fail header.i=@google.com header.s=20161025 header.b=JjHymLiM; dkim=fail header.i=@chromium.org header.s=google header.b=ZPJFwyHl; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934962AbeB1QQ0 (ORCPT + 99 others); Wed, 28 Feb 2018 11:16:26 -0500 Received: from mail-vk0-f65.google.com ([209.85.213.65]:43766 "EHLO mail-vk0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934735AbeB1QQW (ORCPT ); Wed, 28 Feb 2018 11:16:22 -0500 Received: by mail-vk0-f65.google.com with SMTP id p189so1791579vkd.10 for ; Wed, 28 Feb 2018 08:16:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zvBpIHRie1nVwvtmg7+iJyh689MPjBSDBOThb6nOkq0=; b=JjHymLiMA8BuU6JXmf1uLDhg429n0sGS1UARfhWW5oj39nd0FSEErEegISAEStv4F7 vNOYei+mAluuaC55pfapPrZ89d1ixznVMdgeqERz5vkBEfCd50YN8BTJp/gnWFQIEAWs wWpowakSYzmppRqtjD+jTog7VhXcUUwCaMHb/tM7gBdWK5Y9x2cQVcUiEM+PQ3TcUhPu 8BVRAxCFk18GkTyekSyDVuaHZuOnFtVnVCk+xfJNZQOnrYkF39Zgnpl/xCSBr7MM/xeC kLtXjXSp5iPe/gvrISYrE0Sn/RdDOFUFDEHlupat6zK4a6dclqR5SK4yUSyTajcukr9G otEA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zvBpIHRie1nVwvtmg7+iJyh689MPjBSDBOThb6nOkq0=; b=ZPJFwyHlf8w//9ZYo1+zm8f1VNom2fSpxWe/7LrO0GdkuFtCkTobrdtyFz2L67j8ZB oaMCfOhMBGaboRM8r8Xg6qpfSdXOl92nLsFuj6hdtFhAhe3iXk6ueE6lJPr6Ak/RUTsv QhOH064r07plBDIn/3dvoW3EU8esz5P72axlk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=zvBpIHRie1nVwvtmg7+iJyh689MPjBSDBOThb6nOkq0=; b=aCYnJp/f+xnIexia6Hjv6tkYw9uRaOkRadXrB//VccJkyENYGLg8/sa1j8mMHyJmwy tTWoWXkH1Q7VLUC3WUZS5t5YPW/rc2h+ECnnV0nv1/6/nMk/qm/4koifOuiLU/LA7TZD 6RPRpP3GimWgmbTpSej4zbzleT/R3BWWQuk4dhNC1nSo/3/rUTKPuCUrXEWTFPNkbrOE B2dOUJd6TVO7AojAgklD0KWUq3zSNiMtsfBw08b0jHp6Mk4GAVtvgalcJqAcCW5rbCXj vv0ZRcwCIiNFRmvPFWf8qBzvE4uD2PIA/4fziRCmRuoMbnl2glwvQIjqICHPz3BT1jz1 hByA== X-Gm-Message-State: APf1xPCFPy0NDOTifuLFzYslE250vLCP6sv1j46Kb4/8feoVmn2ZlA5m 2ZTK7/1vHeXluZKv761i/glaUmslDi9RrtAHAf5/5w== X-Received: by 10.31.140.5 with SMTP id o5mr13624004vkd.157.1519834580893; Wed, 28 Feb 2018 08:16:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.151.1 with HTTP; Wed, 28 Feb 2018 08:16:20 -0800 (PST) In-Reply-To: <20180228115318.20154-1-Evgeniy.Didin@synopsys.com> References: <20180228115318.20154-1-Evgeniy.Didin@synopsys.com> From: Doug Anderson Date: Wed, 28 Feb 2018 08:16:20 -0800 X-Google-Sender-Auth: 1Bx8Ty4Xy18_j8--We5KaOOqx5k Message-ID: Subject: Re: [PATCH v4] mmc: dw_mmc: Fix the DTO/CTO timeout overflow calculation for 32-bit systems To: Evgeniy Didin , Jaehoon Chung Cc: linux-mmc@vger.kernel.org, Alexey Brodkin , Eugeniy Paltsev , Ulf Hansson , Andy Shevchenko , Jisheng Zhang , Shawn Lin , Vineet Gupta , LKML , linux-snps-arc@lists.infradead.org, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Wed, Feb 28, 2018 at 3:53 AM, Evgeniy Didin wrote: > In commit 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation") and > commit 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout calculation") > have been made changes which cause multiply overflow for 32-bit systems. > The broken timeout calculations leads to unexpected ETIMEDOUT errors and > causes stacktrace splat (such as below) during normal data exchange > with SD-card. > > | Running : 4M-check-reassembly-tcp-cmykw2-rotatew2.out -v0 -w1 > | - Info: Finished target initialization. > | mmcblk0: error -110 transferring data, sector 320544, nr 2048, cmd response > | 0x900, card status 0x0 > > DIV_ROUND_UP_ULL helps to escape usage of __udivdi3() from libgcc and so > code gets compiled on all 32-bit platforms as opposed to usage > of DIV_ROUND_UP when we may only compile stuff on a very few arches. > > Lets cast this multiply to u64 type which prevents overflow. > > Tested-by: Vineet Gupta > Reported-by: Vineet Gupta # ARC STAR 9001306872 HSDK, sdio: board crashes when copying big files > Fixes: 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation") > Fixes: 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout calculation") > > Signed-off-by: Evgeniy Didin > > CC: Alexey Brodkin > CC: Eugeniy Paltsev > CC: Douglas Anderson > CC: Ulf Hansson > CC: Andy Shevchenko > CC: Jisheng Zhang > CC: Shawn Lin > CC: Vineet Gupta > CC: linux-kernel@vger.kernel.org > CC: linux-snps-arc@lists.infradead.org > Cc: > --- > Changes since v3: > -Switch DIV_ROUND_UP macro to DIV_ROUND_UP_ULL > -Make one patch from two patches > -Modify commit message > > Changes sinve v2: > -add fix for cto_ms > > Changes since v1: > -uint64_t switched to u64 > > drivers/mmc/host/dw_mmc.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) FYI that your messages keep ending up in my spam folder and I just see other people's replies. Not exactly sure why... Note also that your patch really doesn't have all the tags in the right places. All the Tags including the Signed-off-by and Cc are supposed to be squashed in one paragraph ...and I believe "CC" is canonically supposed to be "Cc". Presumably the maintainer can fix this up when applying, but please try to do better in the future. Speaking of which, you didn't include the dw_mmc maintainer (Jaehoon Chung) in your post? That seems not so great unless you know something that get_maintainers doesn't know about who will apply this patch. $ ./scripts/get_maintainer.pl -f drivers/mmc/host/dw_mmc.c Jaehoon Chung (maintainer:SYNOPSYS DESIGNWARE MMC/SD/SDIO DRIVER) As far as the actual patch, at first I thought maybe we could avoid the 64-bit math and just pre-divide bus_hz by MSEC_PER_SEC (just like used to happen before my change), but I think there's still a chance of overflow, right? Because, for instance: drto_clks can be a full 24 bits drto_div can be effectively 9 bits ...we could do further tricks (further rounding up the result), but it seems like just doing the 64-bit math is fine too unless someone has any strong objections... Reviewed-by: Douglas Anderson