Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp3813056ybl; Tue, 21 Jan 2020 07:29:48 -0800 (PST) X-Google-Smtp-Source: APXvYqyyedma/dSy2Fcjn/Z7AV4ehYGUkQ+DdsTYamOExQ9oiXKHGY0Tds9PK2hWGgSEg8WMJXcp X-Received: by 2002:a9d:68d3:: with SMTP id i19mr3780488oto.71.1579620588282; Tue, 21 Jan 2020 07:29:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579620588; cv=none; d=google.com; s=arc-20160816; b=H8eiwIkJnQ6foWl17Q61oS8upIea94jsrSw7T2dLdWjhnPD306TiBWtTKwIJjNCC0o u95HOgSleuRzLFMkrSHsEu6ITx2oAdb8HI36lYhS5PNTztx1et2PJD+xR4342G19redO FVc1XxCUdkTuuEtWTANhutQTJqMxNTzLf7EvJYh/iE5MIXsZMouzRpOMCAQJlZGR7UwQ fyHT79Htv9szrFE6gf0LMGrbtXdSgUvDTRVZU2sCBB0oTGurHuOHOGW/flXaR21dstbC hGsPmKJ/58H1moX34wu4tUn2MX0WxNRuIfdUZXrbWK5jwozdtPMuLRCs/DNWb/22XVFU npEg== 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=0OVMgUzjAkBOu1M4iZ+VaHKKaJbvPQtslHU+KG1jadU=; b=V04lJ50WgvOg56r+ieuRo8JMmgaUOsPaM4tbYO+y/puB+d6j2ZvXpisPrgiIRSndF8 LZjYF+UHH+FDc+MVtLYwM5lpEEUjLctcx7vtmD+wJYBMrxGjFZ9HoqGNd06rZMX5ajBU p0KOpLst9Sy+zuVG1SHInfAKquvAnfpWeqRQpLh+PdP+VZ0MHEI8kZFFtu0eae0fYIjx YOK+knKiK5sc4KGe1au6ruu3nPgPl/mWkVD6nzzzlu7QtZepYQI6AwjzlBbeNxLaT9sz 5Ajgpa9OON15cQoP2aokI8dXRiClIqvJw2Z2CCjskro3HCEYA1CaWNK7+Db5ygKA0+Mx uqNA== 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 m17si22420281otr.17.2020.01.21.07.29.34; Tue, 21 Jan 2020 07:29:48 -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; 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 S1729061AbgAUP1k convert rfc822-to-8bit (ORCPT + 99 others); Tue, 21 Jan 2020 10:27:40 -0500 Received: from relay11.mail.gandi.net ([217.70.178.231]:56163 "EHLO relay11.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727508AbgAUP1j (ORCPT ); Tue, 21 Jan 2020 10:27:39 -0500 Received: from xps13 (lfbn-tou-1-1151-102.w90-76.abo.wanadoo.fr [90.76.211.102]) (Authenticated sender: miquel.raynal@bootlin.com) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 3B12A10000F; Tue, 21 Jan 2020 15:27:36 +0000 (UTC) Date: Tue, 21 Jan 2020 16:27:34 +0100 From: Miquel Raynal To: "Shivamurthy Shastri (sshivamurthy)" Cc: Richard Weinberger , Vignesh Raghavendra , Boris Brezillon , Frieder Schrempf , "linux-mtd@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Shivamurthy Shastri Subject: Re: [EXT] Re: [PATCH 3/4] mtd: spinand: Add M70A series Micron SPI NAND devices Message-ID: <20200121162734.464123fd@xps13> In-Reply-To: References: <20200119145432.10405-1-sshivamurthy@micron.com> <20200119145432.10405-4-sshivamurthy@micron.com> <20200120111626.7cb2f6c5@xps13> <20200121144034.05a8f49d@xps13> 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 Shivamurthy, "Shivamurthy Shastri (sshivamurthy)" wrote on Tue, 21 Jan 2020 14:59:11 +0000: > Hi Miquel, > > > > > Hi Shivamurthy, > > > > "Shivamurthy Shastri (sshivamurthy)" wrote > > on > > Tue, 21 Jan 2020 12:23:20 +0000: > > > > > Hi Miquel, > > > > > > > > > > > Hi Shiva, > > > > > > > > This is remark common to the four patches: you miss the 'v2' prefix in > > > > the object. > > > > > > > > > > Sorry for this mistake. > > > I recognized this after sending out the patches. > > > > > > > shiva.linuxworks@gmail.com wrote on Sun, 19 Jan 2020 15:54:31 +0100: > > > > > > > > > From: Shivamurthy Shastri > > > > > > > > > > Add device table for M70A series Micron SPI NAND devices. > > > > > > > > > > While at it, disable the Continuous Read feature which is enabled by > > > > > default. > > > > > > > > Can you please give us more detail on why this is an issue? > > > > > > "Continuous Read" is the new feature added by the Micron for > > > M70A series devices. If this feature is enabled, the READ command > > > doesn't output the OOB area. The following short description > > > describes this feature. > > > > > > Description: > > > If the Continuous Read feature is enabled, the device provides > > > the capability to read the whole block with a single command. > > > However, the read command doesn't output the OOB area. > > > > > > Read command behavior (if Continuous Read enabled): > > > The READ CACHE command doesn't require the starting column address. > > > The device always output the data starting from the first column of the > > > cache register, and once the end of the cache register reached, the data > > > output continues through the next page. With the continuous read mode, > > > it is possible to read out the entire block using a single READ command, and > > > once the end of the block reached, the output pins become High-Z state. > > > > Ok I understand better. In this case there is no need to split this > > commit, instead just reword the commit log to something like: > > > > --->8--- > > Add device table for M70A series Micron SPI-NAND devices. > > > > As opposed to the M60A series already supported, M70A parts have the > > "Continuous Read" feature enabled by default which does not fit the > > subsystem needs. > > > > . > > > > Hence, we disable the feature at probe time. > > ---8<--- > > > > Sure, I will change as per your suggestion. > > > However, below, you disable this bit for all the parts. Is this really > > ok? Souldn't we make it more specific to this series? > > It is ok because this bit is unused in other series. I would rather prefer to avoid this kind of arrangement. Please change this bit only for the series which has it. Thanks, Miquèl