Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753260AbcDBNsG (ORCPT ); Sat, 2 Apr 2016 09:48:06 -0400 Received: from down.free-electrons.com ([37.187.137.238]:40763 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751029AbcDBNsD (ORCPT ); Sat, 2 Apr 2016 09:48:03 -0400 Date: Sat, 2 Apr 2016 15:47:58 +0200 From: Boris Brezillon To: Brian Norris Cc: David Woodhouse , linux-mtd@lists.infradead.org, Richard Weinberger , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Harvey Hunt , Jorge Ramirez-Ortiz Subject: Re: [PATCH v2] mtd: nand: document the NAND controller/NAND chip DT representation Message-ID: <20160402154758.706f6f0f@bbrezillon> In-Reply-To: <20160401205722.GA10227@localhost> References: <1459513595-14308-1-git-send-email-boris.brezillon@free-electrons.com> <20160401205722.GA10227@localhost> X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2508 Lines: 71 Hi Brian, On Fri, 1 Apr 2016 13:57:22 -0700 Brian Norris wrote: > On Fri, Apr 01, 2016 at 02:26:35PM +0200, Boris Brezillon wrote: > > Standardize the NAND controller/NAND chip DT representation. Now, all new > > NAND controller drivers should comply with this representation, even if > > they are only supporting a single NAND chip. > > > > Existing drivers can keep support for the old representation (where only > > the NAND chip was described), but are encouraged to also support the new > > one. > > > > Signed-off-by: Boris Brezillon > > --- > > Changes since v1: > > - fix typo > > --- > > Thanks for doing this. This mostly looks pretty good. > > > Documentation/devicetree/bindings/mtd/nand.txt | 37 +++++++++++++++++++++++++- > > 1 file changed, 36 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt > > index b53f92e..a17662b 100644 > > --- a/Documentation/devicetree/bindings/mtd/nand.txt > > +++ b/Documentation/devicetree/bindings/mtd/nand.txt > > @@ -1,4 +1,23 @@ > > -* MTD generic binding > > +* NAND chip and NAND controller generic binding > > + > > +NAND controller/NAND chip representation: > > You're starting with an assumption that there is a difference. I suppose > that's usually the case, but is there ever a case that there isn't > really? For instance, what about gpio.c? It's just a few GPIOs wired > directly to a NAND chip. Well, even if it's a bit-banging controller which is able to only interface with a single chip it's still a controller and not the NAND chip itself, so I think keeping the separation in this case is still valid. As an example, see the i2c or spi bit-banging drivers, even if there's no real controller, they are still represented with their own node... > Or perhaps, does it make sense still, even > there? For instance, if you wanted to wire multiple chips but share most > of the lines, you'd need to coordinate this in a "controller" node > somehow. Yep. > > All-in-all, looks good though, and we can patch this up with any other > additions. (It's not exactly a formal specification, after all, but just > guidelines.) So: > > Acked-by: Brian Norris Ok, I'll wait for an ack from a DT maintainer before taking this patch. Thanks, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com