From patchwork Thu Oct 4 16:05:17 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?Q2zDqW1lbnQgUMOpcm9u?= X-Patchwork-Id: 10626391 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 4BBBD174A for ; Thu, 4 Oct 2018 16:05:31 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3B51B29344 for ; Thu, 4 Oct 2018 16:05:31 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2FA3329349; Thu, 4 Oct 2018 16:05:31 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9FB3229344 for ; Thu, 4 Oct 2018 16:05:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727809AbeJDW7Y (ORCPT ); Thu, 4 Oct 2018 18:59:24 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:35767 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727484AbeJDW7Y (ORCPT ); Thu, 4 Oct 2018 18:59:24 -0400 Received: by mail-wm1-f67.google.com with SMTP id e187-v6so2100456wmf.0 for ; Thu, 04 Oct 2018 09:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=kW702/MqWQGEcnorL7wEdTgXZa8+lgFYrqpNXeuNICA=; b=jicvGXW6rGqCEIY0TcGPy6fPVljQKDH8vCEZPSkF2NTJBA5yR/5b+LdsEU688LLy7l c1ml55L8VvI1IoqhVqtPez2cMpUk128R8DzQeEb+A/jkXoRy8ZQNIdIqlJH7dD484JUS wg8OJhlPDvjuvBkrIOFh8JMRgZRb7RynC+DW/rY5fuvabv0VaJctr8xR92NZLj3FGjyK sEuJqQQ1D8Ai/hw22wj5usCNKCWFrzgAe4qbotc/q75p8NKbcgxPw4asANkx/1zOTq30 wve6wim+kla1wLizOI/M8dAtm2120ndmozZnGC48znd+4+4piocj+0nNFJwWwA0+f5GF bd9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=kW702/MqWQGEcnorL7wEdTgXZa8+lgFYrqpNXeuNICA=; b=PLzSYZutY2sD9VNBhUbr4VXdNRn/lEtXVLpob28N5Kas8tBSF29m+4pQhx9NTejdpC Qy8B9GdjLTXAK6Utjv86ai3WBiv5iRyIzdeFt7nM1Cp1/iqnkVQRNTm+D5b7G2+OKnur DesWSzwNQLU30n9MKtZAnI68kCCuvoxIl2IPVIDXdcGoozao2h7zbPG12eIwwYohXmjS GP23rGyYXMQR6n1qSHl9+6FJaxsR3Ys+eXq783nK8UzwvcDbS0eTSLY49kRgSaR8fFCE iIUD0xFtUGS8otv4RrX1jg8LQdhE3v1i9W13vNfV1YVrmzIQpziV48tAIIh3AKYryaCI aepw== X-Gm-Message-State: ABuFfoil5fUNz7qQNdv5W6If0OU0Yx/qS2UKss3rYyDGARlRbU+GMJqj PhAH6KVf7cnD7Xk8yAP/ftE= X-Google-Smtp-Source: ACcGV61xXBjFURhrnXn4ii9N26AmEp0x4aDZk7TsODMMC+sGoJVX0NMD4yUvun42/O5wDN/kUT4ulg== X-Received: by 2002:a1c:3307:: with SMTP id z7-v6mr3807867wmz.115.1538669127409; Thu, 04 Oct 2018 09:05:27 -0700 (PDT) Received: from cperon-Latitude-7490.devialet.com (static-css-csd-151233.business.bouyguestelecom.com. [176.162.151.233]) by smtp.gmail.com with ESMTPSA id j66-v6sm5444083wrj.28.2018.10.04.09.05.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Oct 2018 09:05:26 -0700 (PDT) From: =?utf-8?b?Q2zDqW1lbnQgUMOpcm9u?= To: Adrian Hunter , Linus Walleij , Shawn Lin , Jan Luebbe , Bastian Stender , linux-mmc@vger.kernel.org Cc: Chris Boot , =?utf-8?b?Q2zDqW1lbnQgUMOpcm9u?= Subject: [PATCH] mmc: block: avoid multiblock reads for the last sector in SPI mode Date: Thu, 4 Oct 2018 18:05:17 +0200 Message-Id: <20181004160517.12491-1-peron.clem@gmail.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Chris Boot I was trying to get a Micro-SD card working over SPI today when I ran into an issue which made the card unusable. The card was probed correctly, and the msdos partition table was read, but then some command was sent that made the card go into a bad state and stay that way. Only a re-probe would get the card unstuck and only until just after the partition tables were read. After some digging I ran into a post [1] on the spi-devel-general mailing list where someone had exactly the same issue as me, but back in 2007. There was a patch attached which, after some cleanup, fixes the issue completely for me. I have tried this with 3 different Micro-SD cards, all of which suffered from the problem before the patch and none of which fail after the patch. The error shows up as lots of: mmcblk0: error -38 sending status comand, retrying mmcblk0: error -38 sending status comand, retrying mmcblk0: error -38 sending status comand, aborting 1 : http://permalink.gmane.org/gmane.linux.kernel.spi.devel/516 Signed-off-by: Chris Boot Signed-off-by: Clément Péron --- drivers/mmc/core/block.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c index a0b9102c4c6e..7bf94ed96506 100644 --- a/drivers/mmc/core/block.c +++ b/drivers/mmc/core/block.c @@ -1370,6 +1370,16 @@ static void mmc_blk_data_prep(struct mmc_queue *mq, struct mmc_queue_req *mqrq, brq->data.blocks = card->host->max_blk_count; if (brq->data.blocks > 1) { + /* + * Some SD cards in SPI mode return a CRC error or even lock up + * completely when trying to read the last block using a + * multiblock read command. + */ + if (mmc_host_is_spi(card->host) && (rq_data_dir(req) == READ) && + (blk_rq_pos(req) + blk_rq_sectors(req) == + get_capacity(md->disk))) + brq->data.blocks--; + /* * After a read error, we redo the request one sector * at a time in order to accurately determine which