Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp261425ybh; Wed, 11 Mar 2020 00:20:26 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsOC2RFmodQIckZHCs2k5O5cAvVTMF6GsMdMVZ024kZEVk6x7EVG0BAihlok1/9FY+UCAAY X-Received: by 2002:a9d:7d89:: with SMTP id j9mr1189128otn.47.1583911226721; Wed, 11 Mar 2020 00:20:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583911226; cv=none; d=google.com; s=arc-20160816; b=K595msoIb6Y7M9oFku0fbKM31lxaCkuivr0zjkWoLO0lw9qfPVrO4CI6MJNIAoSkVC FgPwDWV+YOLDZ2goCD7GFkBz1TGieuC18Wsss6BOFHGJRdI4h7MGGz0mNYU68Dgb/bpm s9sFgj16V/RwBB+y9cyPbt9afyDQVQdyLwwguBxm1JlIecoQP1sJLtj0cmgD2UUo2Y+/ tY08lbZO80qxhU4unSRXNO4xTWs5TM4OIFF0X+Oeq01JdRYEkIZ+enbdhNEKNSgF8+T8 cEdTSzOMNrCnq/FnzRTqLtO3sQ6CuN2jaGEIzKDHODFRaSdbraAxDhLuCy0LK5i/u7b7 yt/g== 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 :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=Q/63JNHmaO14/U3BjYmCzgEWcJQTH2DaVPr4gPR6EwE=; b=gD1Gl3nqiLEQmfds/l76njbz8O04CVfN1NsoKr/GWkYxHhGooY6BCHT0Nk4oiFASQS ODOtPRiXEuS0d22/BlskUVoE1s+V+JWyju2pgZbmpCP1BFBFEhfLghzHeDusnoN1PfJb ozWdGzt299bCkN5zVoINhkAdXEHQcEJE3HbqzwftS8CyeAKyoqfplgJ7RE4KAjuHm99r zIRFg85v9yd6kbI6knuRKqPUus9CdMk+KJ38s+cyuR7WNRkKB+fG4bt1n+6NjUaIBsXx KUEv/yyuJEQxYk022p5pI05QOnY42qqJLIC2xFbEzz5nfZB8LINkVPAXnJ3JKkbUg7Zk /F0A== 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 e19si695187otp.40.2020.03.11.00.20.15; Wed, 11 Mar 2020 00:20:26 -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 S1728512AbgCKHTb convert rfc822-to-8bit (ORCPT + 99 others); Wed, 11 Mar 2020 03:19:31 -0400 Received: from relay8-d.mail.gandi.net ([217.70.183.201]:46907 "EHLO relay8-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726672AbgCKHTb (ORCPT ); Wed, 11 Mar 2020 03:19:31 -0400 X-Originating-IP: 90.89.41.158 Received: from xps13 (lfbn-tou-1-1473-158.w90-89.abo.wanadoo.fr [90.89.41.158]) (Authenticated sender: miquel.raynal@bootlin.com) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id F2B9E1BF209; Wed, 11 Mar 2020 07:19:18 +0000 (UTC) Date: Wed, 11 Mar 2020 08:19:18 +0100 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 Message-ID: <20200311081918.0f2c64c2@xps13> In-Reply-To: <20200310183338.19961-1-miquel.raynal@bootlin.com> References: <20200208074439.146296-1-gch981213@gmail.com> <20200310183338.19961-1-miquel.raynal@bootlin.com> Organization: Bootlin X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Chuanhong, Miquel Raynal wrote on Tue, 10 Mar 2020 19:33:38 +0100: > 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. I also changed the prefix to "mtd: spinand:". Thanks, Miquèl