From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965242AbbJ1ICc (ORCPT ); Wed, 28 Oct 2015 04:02:32 -0400 Received: from down.free-electrons.com ([37.187.137.238]:53179 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S964828AbbJ1IC0 (ORCPT ); Wed, 28 Oct 2015 04:02:26 -0400 Date: Wed, 28 Oct 2015 09:02:23 +0100 From: Boris Brezillon To: Brian Norris Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, Ezequiel Garcia , Marek Vasut , Scott Wood , Josh Wu , Robert Jarzmik , Kyungmin Park , Han Xu , Huang Shijie Subject: Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node Message-ID: <20151028090223.4564a966@bbrezillon> In-Reply-To: <20151028010102.GB13239@google.com> References: <1445913070-17950-1-git-send-email-computersforpeace@gmail.com> <1445913070-17950-2-git-send-email-computersforpeace@gmail.com> <20151027084200.2434180f@bbrezillon> <20151027175446.GT13239@google.com> <20151028010102.GB13239@google.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; 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 Hi Brian, On Tue, 27 Oct 2015 18:01:02 -0700 Brian Norris wrote: > On Tue, Oct 27, 2015 at 10:54:46AM -0700, Brian Norris wrote: > > On Tue, Oct 27, 2015 at 08:42:00AM +0100, Boris Brezillon wrote: > > > On Mon, 26 Oct 2015 19:31:06 -0700 > > > I like the idea, but how about pushing the solution even further and > > > killing the ->flash_node field which AFAICT is rendered useless by > > > your patch? > > > > I suppose we could do that. I do think there's something to be said for > > layering, though. Historically, we haven't done a very good job of > > layering in MTD, so low-level drivers often have to poke around in the > > MTD structures, even if they really should only have to know a few > > things about their helper subsystem/library, like NAND or SPI NOR. So > > with that in mind, I think the ->flash_node serves some purpose -- > > drivers can just initialize struct nand_chip/spi_nor and be assured that > > the NAND/SPI-NOR subsystems will take care of things. > > > > Now, I don't think there's much reason to suspect that we'd have a more > > complex mapping than 1:1 between struct mtd_info and struct nand_chip or > > struct spi_nor, so maybe we don't actually need duplicate storage > > (mtd.dev.of_node and {spi_nor,nand_chip}.flash_node), and the layering > > is just have these APIs: > > > > nand_set_flash_node() > > spi_nor_set_flash_node() > > > > which just call mtd_set_of_node()? > > I looked at this quickly for NAND, and it's hard to do right now because > of the below quote. The SPI NOR layering is better though, so that > works. Mind if I defer the dropping the flash_node in NAND but do the > SPI NOR one? No, I don't mind (we'll solve that later). > > > Speaking of layering: why do we have NAND drivers initializing mtd->priv > > for us, yet nand_base just assumes that it points to a struct nand_chip? > > And why isn't struct mtd_info just embedded in struct nand_chip? Are > > there ever cases we want more than one (master) MTD per nand_chip? Or > > vice versa? > > The layering (or lack thereof) make it hard to extract a struct mtd_info > from a struct nand_chip. That's true, and that's why we'd better rework a few things (embed or point to an allocated mtd struct in nand_chip) before trying to automatically assign mtd->priv to a nand_chip pointer. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com