Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp241899imm; Wed, 3 Oct 2018 15:20:21 -0700 (PDT) X-Google-Smtp-Source: ACcGV62zkASSf4jV+NZ1t4eQ2o1uNZQ0wFOfAK9uW9KOcJEkMvfDIFefmp7C1iaZfsVKbqhOHC0A X-Received: by 2002:a63:d917:: with SMTP id r23-v6mr3202226pgg.0.1538605221728; Wed, 03 Oct 2018 15:20:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538605221; cv=none; d=google.com; s=arc-20160816; b=wLDw4Dc8OPGyQqk7Y9Tciapxuxmg/4/Dh8MgwZe3h8Z3BGekVxZhi/Ek/YjbHsOePE P4CYxEdoODPMxRpmakArigbikAoJIyItH7u5h0ijIvyzAZPDc3CzVhbQAlWcpbs+ixr5 yPNuWZGkRaCZ/GXWWk3OEYbZGmjJn8JlhfwjuI0XGNt4i3dkHaTlvpfnGU/SCfeNUvX3 QTRGutCAK74L61dWK5EBSiDZ31YF3rDXDynjc3bdao9XiXjdbZTbr6PbIY5Pl7UgcM4k 9xxsSZ4c6gn6g5abtPxhhWwBIVicFhHVJSGzoPn0xbCBp3VBWgmZ43u1bhRqUmrEoK4j kFQQ== 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:subject:cc:to:from:date; bh=kGllbw71jNz2lpDh1p/ktZ7C7YZ0WElp4Lm11S0i5hM=; b=IAikDfTxt7wF6OFAd550kgser4ZyokIxTkC+OKv29cttAwbjWGyP2u1E98Urj1Gv5o BQyibKE3F/oofQqIzYWaTgx+BQnHCC3v3IytaMZ3rwUhX/PVOpcy0H9ol7DroThR8qEb KIVVfOdD2H6Q8K8mIlpdEOZW12sLQOm4JsibQqSoVR1AS3QqLP41kpp3Fg91ZC7nB25e E3I1c3ENtY6umvZDkvtnAner1P8LiXdaNzz7CO8lrR7UAxVwF9ktpJTGn5Oxchx4Nt3f 4Y/6y72WRENCvdqSMo4nAPvnB4HVQFg1L1/ycdLD5JpcksL/Xv93sBZ2yBWk532Y68il l7Wg== 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 bg10-v6si2715543plb.47.2018.10.03.15.20.06; Wed, 03 Oct 2018 15:20:21 -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 S1727367AbeJDFJo (ORCPT + 99 others); Thu, 4 Oct 2018 01:09:44 -0400 Received: from mail.bootlin.com ([62.4.15.54]:50442 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725922AbeJDFJo (ORCPT ); Thu, 4 Oct 2018 01:09:44 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id D006620802; Thu, 4 Oct 2018 00:19:24 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT, URIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.0 Received: from bbrezillon (91-160-177-164.subs.proxad.net [91.160.177.164]) by mail.bootlin.com (Postfix) with ESMTPSA id 76B06207CC; Thu, 4 Oct 2018 00:19:24 +0200 (CEST) Date: Thu, 4 Oct 2018 00:19:24 +0200 From: Boris Brezillon To: Ricardo Ribalda Delgado Cc: David Woodhouse , Brian Norris , Marek Vasut , Richard Weinberger , Zhouyang Jia , linux-mtd@lists.infradead.org, LKML , devicetree@vger.kernel.org Subject: Re: [PATCH v5 7/8] dt-binding: mtd: Document gpio-addr-flash Message-ID: <20181004001924.3644185d@bbrezillon> In-Reply-To: <20181004001415.224d53fe@bbrezillon> References: <20181003193859.23928-1-ricardo.ribalda@gmail.com> <20181003193859.23928-7-ricardo.ribalda@gmail.com> <20181003232702.4c18e725@bbrezillon> <20181004001415.224d53fe@bbrezillon> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 4 Oct 2018 00:14:15 +0200 Boris Brezillon wrote: > On Wed, 3 Oct 2018 23:53:27 +0200 > Ricardo Ribalda Delgado wrote: > > > Hi Boris > > On Wed, Oct 3, 2018 at 11:27 PM Boris Brezillon > > wrote: > > > > > > On Wed, 3 Oct 2018 21:38:58 +0200 > > > Ricardo Ribalda Delgado wrote: > > > > > > > Add documentation for gpio-addr-flash. This binding allow creating > > > > flash devices that are paged using GPIOs. > > > > > > > > Cc: devicetree@vger.kernel.org > > > > Reviewed-by: Rob Herring > > > > Signed-off-by: Ricardo Ribalda Delgado > > > > --- > > > > .../bindings/mtd/gpio-addr-flash.txt | 54 +++++++++++++++++++ > > > > 1 file changed, 54 insertions(+) > > > > create mode 100644 Documentation/devicetree/bindings/mtd/gpio-addr-flash.txt > > > > > > > > diff --git a/Documentation/devicetree/bindings/mtd/gpio-addr-flash.txt b/Documentation/devicetree/bindings/mtd/gpio-addr-flash.txt > > > > new file mode 100644 > > > > index 000000000000..5006a26e1753 > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/mtd/gpio-addr-flash.txt > > > > @@ -0,0 +1,54 @@ > > > > +Memory Mapped flash with some address lines addressed using GPIOs > > > > + > > > > +Handle the case where a flash device is mostly addressed using physical > > > > +line and supplemented by GPIOs. This way you can hook up say a 8MiB flash > > > > +to a 2MiB memory range and use the GPIOs to select a particular range. > > > > + > > > > + - compatible : "cfi-gpio-addr-flash" > > > > + - reg : Address range of the mtd chip that is memory mapped, this is, > > > > + on the previous example 2MiB. > > > > + - bank-width : Width (in bytes) of the bank. Equal to the > > > > + device width times the number of interleaved chips. > > > > + - gpios: List of GPIO specifiers that will be used to address the MSBs address > > > > + lines. The order goes from LSB to MSB. > > > > + - probe-type : (optional) "cfi_probe", "jedec_probe". How the mtd chip > > > > + is going to be probed. If omitted, assumed to be equal to "cfi_probe". > > > > > > Looks like other bindings are encoding the probe type in the > > > compatible [1][2], and we should probably follow what's been done by > > > others. > > > > If I understood it right, they are special cases of physmap_of_core.c > > https://elixir.bootlin.com/linux/v4.18.11/source/drivers/mtd/maps/physmap_of_core.c#L242 > > > > The driver that handles the compatible is physmap_of_core.c, and afaik > > multiple drivers with the same > > compatible string is a very bad idea. > > Yes, I know. > > > > > We can convert the driver to something like Versatile or gemini, but > > then we will not support platform devices > > > > btw, the binding that I am used is used by: > > https://elixir.bootlin.com/linux/v4.18.11/source/drivers/mtd/maps/physmap_of_core.c#L91 > > Actually, the more I think about it the more I realize this should > somehow be integrated to the physmap core logic. I mean, there's nothing > controller/platform specific in what the gpio-physmap driver does. > > We could basically add the msb_addr_gpios related fields to map_info, > let physmap.c and physmap_of_core.c call > devm_gpiod_get_array_optional() and, based on the returned value, > call simple_map_init() (when the pointer is NULL) or > gpio_addr_map_init() (when the pointer is valid). Or even better, let simple_map_init() call gpio_addr_map_init() when map->addr_gpios != NULL, so that you don't even have to duplicate the selection logic in physmap.c and physmap_of_core.c. > > gpio_addr_map_init() would still be implemented in gpio-addr-flash.c so > that we can still enable/disable support for this feature (providing > dummy wrappers when it's disabled). By doing that, we also keep a single > driver which matches a generic compatible string. We also stay > compatible with .c based board files.