From patchwork Fri Jul 27 18:33:13 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brian Norris X-Patchwork-Id: 950299 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.infradead.org (client-ip=2607:7c80:54:e::133; helo=bombadil.infradead.org; envelope-from=linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="DojS4saI"; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="aAEZXgb6"; dkim-atps=neutral Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 41cd0P3p4Tz9ryn for ; Sat, 28 Jul 2018 04:34:13 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:To :From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=X4CoeSvqQvh5W4fLEatHiY8tGX0ndRi+UkBNDX4uWxs=; b=DojS4saIn9MSmQ 23wijKqnh7mNoEJS3dICYVNNwNmMFOaMvxZePQamQFAw9DqQ39R3Iihnfs0jWP9JhkcZaJqR0cfup EyEz33ntJ8GNIVNlY/NIQy1XMHTzvqp24/P42u5DR11r3nO48ki0Qy+WeNVuaz/TbZQQZDKEbBS39 kCijL/PNDnPHa31xwqZ+qMRTAKpmST3rQ+qZ70RRHxUwqZtaw0fauj9GIv4DjW1KGUxb+/DVUaYz5 0hwaDns2FNB094cDFYc9ISZDPnALRqdtdYg9BQMfbonioxsx91e5cpDi6/We6H9id8l81taVNzsWZ rGYi5Uhj+rh9gFO5Mkpg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1fj7Yq-0008PR-GE; Fri, 27 Jul 2018 18:33:56 +0000 Received: from mail-pg1-x541.google.com ([2607:f8b0:4864:20::541]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1fj7YX-0008Nw-8M for linux-mtd@lists.infradead.org; Fri, 27 Jul 2018 18:33:39 +0000 Received: by mail-pg1-x541.google.com with SMTP id a11-v6so3704017pgw.6 for ; Fri, 27 Jul 2018 11:33:26 -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=EsicLjuZnxZTq7qMTUT6pZLb7MPuQUNf75VZyHdhaqA=; b=aAEZXgb6NeYzf2THIr/cFdiTZ+QvXKQb8rQ0iRpCg0jvcOLdg05zM33M1UhU/cF75T z1Qn65s6soGEuwEwrtY5NeRLXXqDO9YOOuGDYnCDnEMhCjD4uXEXLl/qXJWbc0x2StlK GyDOu3P3dmqBBIVTn+B+rQHeOCBEmIDeofN/WaMDM6V7auB2R3eKgEgMDXJ3yJHY/PtA 10bkRVVTGY/Ow/cKeIjkn0fN0PduEqBAh+/ukIBQ7TeSHTJek+nedCq/hbgvm7jO6oQo gpfdA0vZ3C1lx3IWomragWUis+qvnvHjq+7i8BPEVUHa6AiezH5tvl6EF6Rjl9uYF1h2 3a8A== 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=EsicLjuZnxZTq7qMTUT6pZLb7MPuQUNf75VZyHdhaqA=; b=Lbny72bnMR8bPsBIX+3tDxzPo6YbgCRUq1elUAVoJzztF9WMu/uLx1Du5ylvBFdyzK 7NJX9tiCHzYap+THzFxFM3uM/sLLhYGW22aO0xLwPUUcs/niI6qsUJYgzlbH1YVOudWw xGThWv91jx9LXzCXysXoLHmiVARuewhHEQhd3CYSU2Wtvd+ipiEyio8hR49P2nhXMXdP jFQGwP4EPBAIMKFg/KMnCJbQua3TQIpUiyzWLR8sP0pwhelUdoZwI/I9mrZh5lsKbuRs tR1tubZvbMVoIFxpIVJzMkN/IVgqdsW8oo5oR8UVkEwszHFBa8Rg3agztwSm7mfZOIN0 ehMw== X-Gm-Message-State: AOUpUlFzrHoI/seiCbJR/Z0tVlP2ua0VA/CHj5DHVSRBl1eAKR6oAPmN hKU5jSSIs4hTfjNBAW98b+s= X-Google-Smtp-Source: AAOMgpfZkk9P6m4e/H7X3MuarAKNTGNBRPDq94+pIriV2r4C51IC+D9sr9zZFO0GWsyKBvpxsi4AvQ== X-Received: by 2002:a65:4849:: with SMTP id i9-v6mr7144234pgs.350.1532716405911; Fri, 27 Jul 2018 11:33:25 -0700 (PDT) Received: from ban.mtv.corp.google.com ([2620:0:1000:1501:bc2f:3082:9938:5d41]) by smtp.gmail.com with ESMTPSA id e132-v6sm4720627pfc.49.2018.07.27.11.33.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jul 2018 11:33:24 -0700 (PDT) From: Brian Norris To: Boris Brezillon , Marek Vasut , Richard Weinberger , Rob Herring Subject: [PATCH] mtd: spi-nor: only apply reset hacks to broken hardware Date: Fri, 27 Jul 2018 11:33:13 -0700 Message-Id: <20180727183313.137943-1-computersforpeace@gmail.com> X-Mailer: git-send-email 2.18.0.345.g5c9ce644c3-goog MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180727_113337_742975_A546B673 X-CRM114-Status: GOOD ( 24.97 ) X-Spam-Score: -0.1 (/) X-Spam-Report: SpamAssassin version 3.4.1 on bombadil.infradead.org summary: Content analysis details: (-0.1 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [2607:f8b0:4864:20:0:0:0:541 listed in] [list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (computersforpeace[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Zhiqiang Hou , Brian Norris , linux-mtd@lists.infradead.org, NeilBrown Sender: "linux-mtd" Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org Commit 59b356ffd0b0 ("mtd: m25p80: restore the status of SPI flash when exiting") is the latest from a long history of attempts to add reboot handling to handle stateful addressing modes on SPI flash. Some prior mostly-related discussions: http://lists.infradead.org/pipermail/linux-mtd/2013-March/046343.html [PATCH 1/3] mtd: m25p80: utilize dedicated 4-byte addressing commands http://lists.infradead.org/pipermail/barebox/2014-September/020682.html [RFC] MTD m25p80 3-byte addressing and boot problem http://lists.infradead.org/pipermail/linux-mtd/2015-February/057683.html [PATCH 2/2] m25p80: if supported put chip to deep power down if not used Previously, attempts to add reboot-time software reset handling were rejected, but the latest attempt was not. Quick summary of the problem: Some systems (e.g., boot ROM or bootloader) assume that they can read initial boot code from their SPI flash using 3-byte addressing. If the flash is left in 4-byte mode after reset, these systems won't boot. The above patch provided a shutdown/remove hook to attempt to reset the addressing mode before we reboot. Notably, this patch misses out on huge classes of unexpected reboots (e.g., crashes, watchdog resets). Unfortunately, it is essentially impossible to solve this problem 100%: if your system doesn't know how to reset the SPI flash to power-on defaults at initialization time, no amount of software can really rescue you -- there will always be a chance of some unexpected reset that leaves your flash in an addressing mode that your boot sequence didn't expect. While it is not directly harmful to perform hacks like the aforementioned commit on all 4-byte addressing flash, a properly-designed system should not need the hack -- and in fact, providing this hack may mask the fact that a given system is indeed broken. So this patch attempts to apply this unsound hack more narrowly, providing a strong suggestion to developers and system designers that this is truly a hack. With luck, system designers can catch their errors early on in their development cycle, rather than applying this hack long term. But apparently enough systems are out in the wild that we still have to provide this hack. Document a new device tree property to denote systems that do not have a proper hardware (or software) reset mechanism, and apply the hack (with a loud warning) only in this case. Signed-off-by: Brian Norris Reviewed-by: Guenter Roeck Acked-by: Rob Herring --- Note that I intentionall didn't split the documentation patch. It seems clearer to do these together IMO, but if it's *really* important to someone...I can resend --- .../devicetree/bindings/mtd/jedec,spi-nor.txt | 9 +++++++++ drivers/mtd/spi-nor/spi-nor.c | 18 ++++++++++++++++-- include/linux/mtd/spi-nor.h | 1 + 3 files changed, 26 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt index 956bb046e599..f03be904d3c2 100644 --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt @@ -69,6 +69,15 @@ Optional properties: all chips and support for it can not be detected at runtime. Refer to your chips' datasheet to check if this is supported by your chip. +- broken-flash-reset : Some flash devices utilize stateful addressing modes + (e.g., for 32-bit addressing) which need to be managed + carefully by a system. Because these sorts of flash don't + have a standardized software reset command, and because some + systems don't toggle the flash RESET# pin upon system reset + (if the pin even exists at all), there are systems which + cannot reboot properly if the flash is left in the "wrong" + state. This boolean flag can be used on such systems, to + denote the absence of a reliable reset mechanism. Example: diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index d9c368c44194..f028277fb1ce 100644 --- a/drivers/mtd/spi-nor/spi-nor.c +++ b/drivers/mtd/spi-nor/spi-nor.c @@ -2757,8 +2757,18 @@ static int spi_nor_init(struct spi_nor *nor) if ((nor->addr_width == 4) && (JEDEC_MFR(nor->info) != SNOR_MFR_SPANSION) && - !(nor->info->flags & SPI_NOR_4B_OPCODES)) + !(nor->info->flags & SPI_NOR_4B_OPCODES)) { + /* + * If the RESET# pin isn't hooked up properly, or the system + * otherwise doesn't perform a reset command in the boot + * sequence, it's impossible to 100% protect against unexpected + * reboots (e.g., crashes). Warn the user (or hopefully, system + * designer) that this is bad. + */ + WARN_ONCE(nor->flags & SNOR_F_BROKEN_RESET, + "enabling reset hack; may not recover from unexpected reboots\n"); set_4byte(nor, nor->info, 1); + } return 0; } @@ -2781,7 +2791,8 @@ void spi_nor_restore(struct spi_nor *nor) /* restore the addressing mode */ if ((nor->addr_width == 4) && (JEDEC_MFR(nor->info) != SNOR_MFR_SPANSION) && - !(nor->info->flags & SPI_NOR_4B_OPCODES)) + !(nor->info->flags & SPI_NOR_4B_OPCODES) && + (nor->flags & SNOR_F_BROKEN_RESET)) set_4byte(nor, nor->info, 0); } EXPORT_SYMBOL_GPL(spi_nor_restore); @@ -2911,6 +2922,9 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, params.hwcaps.mask |= SNOR_HWCAPS_READ_FAST; } + if (of_property_read_bool(np, "broken-flash-reset")) + nor->flags |= SNOR_F_BROKEN_RESET; + /* Some devices cannot do fast-read, no matter what DT tells us */ if (info->flags & SPI_NOR_NO_FR) params.hwcaps.mask &= ~SNOR_HWCAPS_READ_FAST; diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index e60da0d34cc1..c922e97f205a 100644 --- a/include/linux/mtd/spi-nor.h +++ b/include/linux/mtd/spi-nor.h @@ -235,6 +235,7 @@ enum spi_nor_option_flags { SNOR_F_S3AN_ADDR_DEFAULT = BIT(3), SNOR_F_READY_XSR_RDY = BIT(4), SNOR_F_USE_CLSR = BIT(5), + SNOR_F_BROKEN_RESET = BIT(6), }; /**