Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3001530imm; Sun, 19 Aug 2018 09:47:35 -0700 (PDT) X-Google-Smtp-Source: AA+uWPxSvdeDani16BgAM0NqbM7SuABZWymWH2GMj42/5unITRCNM4vq+YEdnU1IrSpgmjWndqDR X-Received: by 2002:a17:902:543:: with SMTP id 61-v6mr42426869plf.126.1534697255870; Sun, 19 Aug 2018 09:47:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534697255; cv=none; d=google.com; s=arc-20160816; b=XYW05VnF3c45dbRvb+2iUHlR0bLxNHzWvXr3rbXtEXDyyP2Sv8BoOq48XXQvswt72m pVnv6FA2ZZM2LYAm2dic1sHDoWtErNUigD1iDNd5ePlGfQxXbZVD1+WvWq9IVUeu/w+H iB33FF9Ne3/huaA01vKvpmduwkBbYDtlfC/FpJisxHwN7YGjQE4ek2ZueN5HU4eEH5D3 Vz+MfflBFk9+vTek6FKNMbf7jdDH2DmX9HW5mBnqpVHbDjRTKDjRMBLMX4X5bV9QKUx6 Dxpcp8Yj1WlhsmYRwmhT5PB0xXdvswwnLgGSYlUD+S75HP8XnI1Ncd2n2vCO9y4zVeCN VV5g== 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 :arc-authentication-results; bh=8aw9zDLGR/e/eZnOvJcGutASSZHghy+QM72kMSID/do=; b=hYyu6p9phothXHP9yOq3lQAV5lh00VUnry0q7UtpVbzWvvdPDmW8nJAgzfxqYki9ag adBh2dER2YaiaeHi1vnCnyaUIaZdnUPTp7eAwAjBiJOTyGGz4qkixdo3xNWzm0phNEF/ vImwGriV14r2+XZG4NYpMdBkCX7Rc+gRqGbBl5XIFf2VKx+iXfHzIxGJmEQ7Phcf9VVM H06RKraDHDB4zb3Oof+HVPt+Xi6WRLkhs33ob00Z9tHkGTct1X142TMX1mYPbKliIr1B Jigw2m/SV7jkOoRdXxuUVul9nBZqUdVmsO/jbPvJ7k6zoqjt98dQITeVqo9fIn9BjaUY zViA== 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 t13-v6si8189475pfc.194.2018.08.19.09.47.20; Sun, 19 Aug 2018 09:47:35 -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 S1726586AbeHST6T (ORCPT + 99 others); Sun, 19 Aug 2018 15:58:19 -0400 Received: from mail.bootlin.com ([62.4.15.54]:52370 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726131AbeHST6T (ORCPT ); Sun, 19 Aug 2018 15:58:19 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 6350220802; Sun, 19 Aug 2018 18:46:12 +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 shortcircuit=ham autolearn=disabled version=3.4.0 Received: from bbrezillon (unknown [91.160.177.164]) by mail.bootlin.com (Postfix) with ESMTPSA id 88055207C4; Sun, 19 Aug 2018 18:46:11 +0200 (CEST) Date: Sun, 19 Aug 2018 18:46:09 +0200 From: Boris Brezillon To: Alban , Srinivas Kandagatla Cc: Bartosz Golaszewski , Jonathan Corbet , Sekhar Nori , Kevin Hilman , Russell King , Arnd Bergmann , Greg Kroah-Hartman , David Woodhouse , Brian Norris , Marek Vasut , Richard Weinberger , Grygorii Strashko , "David S . Miller" , Naren , Mauro Carvalho Chehab , Andrew Morton , Lukas Wunner , Dan Carpenter , Florian Fainelli , Ivan Khoronzhuk , Sven Van Asbroeck , Paolo Abeni , Rob Herring , David Lechner , Andrew Lunn , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org, linux-mtd@lists.infradead.org, linux-omap@vger.kernel.org, netdev@vger.kernel.org, Bartosz Golaszewski Subject: Re: [PATCH v2 06/29] mtd: Add support for reading MTD devices via the nvmem API Message-ID: <20180819184609.6dcdbb9a@bbrezillon> In-Reply-To: <20180819133106.0420df5f@tock> References: <20180810080526.27207-1-brgl@bgdev.pl> <20180810080526.27207-7-brgl@bgdev.pl> <20180817182720.6a6e5e8e@bbrezillon> <20180819133106.0420df5f@tock> 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 Sun, 19 Aug 2018 13:31:06 +0200 Alban wrote: > On Fri, 17 Aug 2018 18:27:20 +0200 > Boris Brezillon wrote: > > > Hi Bartosz, > > > > On Fri, 10 Aug 2018 10:05:03 +0200 > > Bartosz Golaszewski wrote: > > > > > From: Alban Bedel > > > > > > Allow drivers that use the nvmem API to read data stored on MTD devices. > > > For this the mtd devices are registered as read-only NVMEM providers. > > > > > > Signed-off-by: Alban Bedel > > > [Bartosz: > > > - use the managed variant of nvmem_register(), > > > - set the nvmem name] > > > Signed-off-by: Bartosz Golaszewski > > > > What happened to the 2 other patches of Alban's series? I'd really > > like the DT case to be handled/agreed on in the same patchset, but > > IIRC, Alban and Srinivas disagreed on how this should be represented. > > I hope this time we'll come to an agreement, because the MTD <-> NVMEM > > glue has been floating around for quite some time... > > These other patches were to fix what I consider a fundamental flaw in > the generic NVMEM bindings, however we couldn't agree on this point. > Bartosz later contacted me to take over this series and I suggested to > just change the MTD NVMEM binding to use a compatible string on the > NVMEM cells as an alternative solution to fix the clash with the old > style MTD partition. > > However all this has no impact on the code needed to add NVMEM support > to MTD, so the above patch didn't change at all. It does have an impact on the supported binding though. nvmem->dev.of_node is automatically assigned to mtd->dev.of_node, which means people will be able to define their NVMEM cells directly under the MTD device and reference them from other nodes (even if it's not documented), and as you said, it conflict with the old MTD partition bindings. So we'd better agree on this binding before merging this patch. I see several options: 1/ provide a way to tell the NVMEM framework not to use parent->of_node even if it's != NULL. This way we really don't support defining NVMEM cells in the DT, and also don't support referencing the nvmem device using a phandle. 2/ define a new binding where all nvmem-cells are placed in an "nvmem" subnode (just like we have this "partitions" subnode for partitions), and then add a config->of_node field so that the nvmem provider can explicitly specify the DT node representing the nvmem device. We'll also need to set this field to ERR_PTR(-ENOENT) in case this node does not exist so that the nvmem framework knows that it should not assign nvmem->dev.of_node to parent->of_node 3/ only declare partitions as nvmem providers. This would solve the problem we have with partitions defined in the DT since defining sub-partitions in the DT is not (yet?) supported and partition nodes are supposed to be leaf nodes. Still, I'm not a big fan of this solution because it will prevent us from supporting sub-partitions if we ever want/need to. 4/ Add a ->of_xlate() hook that would be called if present by the framework instead of using the default parsing we have right now. 5/ Tell the nvmem framework the name of the subnode containing nvmem cell definitions (if NULL that means cells are directly defined under the nvmem provider node). We would set it to "nvmem-cells" (or whatever you like) for the MTD case. There are probably other options (some were proposed by Alban and Srinivas already), but I'd like to get this sorted out before we merge this patch. Alban, Srinivas, any opinion?