Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp956997ybh; Tue, 10 Mar 2020 11:35:12 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtBoOC6JJklycDaR6SIfMBWgeaegKpHFfUMm5AGD3/RaT9nM2Ls5b7QhhdZ08w/gn3YpOVW X-Received: by 2002:a9d:463:: with SMTP id 90mr18708413otc.283.1583865312117; Tue, 10 Mar 2020 11:35:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583865312; cv=none; d=google.com; s=arc-20160816; b=LPZieDGedXgc4uuLpJXb281xBB6LSSUQl1G3YCcTs5+Phq6eetCVnPORB20cHfkVSu vMN564khS2sTUWAiuUGhNcWzNx+MSA2LXe88dcIkpMLUxJtGVz6EcqqBR3lnmnSf74Tx SsYQ7IoC2mK2kUwzaT4X7BCygnVGzLn4RmtPUOdGYNnZDtYSJAc2S7VgJ8cw4EGqtPuU 9FUqXT5K/nZckd8YZnpmcylHROPJpNnnTsXpLOpmTIHVeQS1aMrWY7YhXVLAldLC0nY0 +iGm9KWc9qCBP+ILhwmmMK11tV/tX6vI+/Sv0Y1iSObdpXkRwUAu7vBy8bhNmG3kPj88 in6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=PLmG6MJ06M+p80Wty1tW1Duh0AHEtsvATiJ/O/FIE1k=; b=KcbNACu99CBGf0ZAiLY44KpWKHWKg7MQEeDi0iq91w/c4MObw77sDLn8mWadAc0RbY g8iEiS5anw2kyjmxKOpUkwtv2ebJ3XrQSMVMcXIxIXvKYXgATDAWOb/4zVRuPCHvTkF+ vNAyO6yp5iG0/BUQ6c9b/BNl4csj9RQzCD7TcEVP13dET1AtkX4zAV2NwPaW311CfMra 6mIwashI05gUFjOoKwWNr8sX5vdJ2sWrLMUAuY5QIKDRO5Yhv1rlp3t/s7c3xAdqbrtr qVn6sfKCABpM1ttwZYE0nnCjbcst7BRbIlI/bSvBd6qO75o3Y/f3M8/67oNNNC8jn/fy tPuw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 83si6191797oie.242.2020.03.10.11.35.00; Tue, 10 Mar 2020 11:35:12 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727470AbgCJSdl (ORCPT + 99 others); Tue, 10 Mar 2020 14:33:41 -0400 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:58085 "EHLO relay7-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727451AbgCJSdl (ORCPT ); Tue, 10 Mar 2020 14:33:41 -0400 X-Originating-IP: 91.224.148.103 Received: from localhost.localdomain (unknown [91.224.148.103]) (Authenticated sender: miquel.raynal@bootlin.com) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 67E8D20008; Tue, 10 Mar 2020 18:33:39 +0000 (UTC) From: Miquel Raynal To: Chuanhong Guo , linux-mtd@lists.infradead.org, Miquel Raynal , Boris Brezillon Cc: Richard Weinberger , Vignesh Raghavendra , linux-kernel@vger.kernel.org Subject: Re: [PATCH v4] mtd: nand: spi: rework detect procedure for different read id op Date: Tue, 10 Mar 2020 19:33:38 +0100 Message-Id: <20200310183338.19961-1-miquel.raynal@bootlin.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200208074439.146296-1-gch981213@gmail.com> References: MIME-Version: 1.0 X-linux-mtd-patch-notification: thanks X-linux-mtd-patch-commit: f1541773af49ecd1edae29c8ac0775253a0b0760 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 2020-02-08 at 07:43:50 UTC, Chuanhong Guo wrote: > Currently there are 3 different variants of read_id implementation: > 1. opcode only. Found in GD5FxGQ4xF. > 2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E > 3. opcode + 1 dummy byte. Found in other currently supported chips. > > Original implementation was for variant 1 and let detect function > of chips with variant 2 and 3 to ignore the first byte. This isn't > robust: > > 1. For chips of variant 2, if SPI master doesn't keep MOSI low > during read, chip will get a random id offset, and the entire id > buffer will shift by that offset, causing detect failure. > > 2. For chips of variant 1, if it happens to get a devid that equals > to manufacture id of variant 2 or 3 chips, it'll get incorrectly > detected. > > This patch reworks detect procedure to address problems above. New > logic do detection for all variants separatedly, in 1-2-3 order. > Since all current detect methods do exactly the same id matching > procedure, unify them into core.c and remove detect method from > manufacture_ops. > > Tested on GD5F1GQ4UAYIG and W25N01GVZEIG. > > Signed-off-by: Chuanhong Guo Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next, thanks. Miquel