From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.free-electrons.com ([62.4.15.54]) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1cpqIw-0006Kn-94 for linux-mtd@lists.infradead.org; Mon, 20 Mar 2017 05:56:32 +0000 Date: Mon, 20 Mar 2017 06:56:04 +0100 From: Boris Brezillon To: Peter Pan , Marek Vasut , Cyrille Pitchen Cc: Arnaud Mouiche , Peter Pan , Richard Weinberger , Brian Norris , Thomas Petazzoni , linux-mtd@lists.infradead.org, "linshunquan (A)" Subject: Re: [PATCH v3 7/8] nand: spi: Add generic SPI controller support Message-ID: <20170320065604.18a6340d@bbrezillon> In-Reply-To: References: <1489646857-10112-1-git-send-email-peterpandong@micron.com> <1489646857-10112-8-git-send-email-peterpandong@micron.com> <20170317152048.1eca677e@bbrezillon> <3efc4b1f-7391-03f9-497d-8ea5f89f5d59@gmail.com> <20170317184852.030709de@bbrezillon> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , +Cyrille and Marek. On Mon, 20 Mar 2017 12:58:26 +0800 Peter Pan wrote: > Hi Boris and Arnaud, > > On Sat, Mar 18, 2017 at 1:48 AM, Boris Brezillon > wrote: > > On Fri, 17 Mar 2017 18:32:28 +0100 > > Arnaud Mouiche wrote: > > > >> On 17/03/2017 15:20, Boris Brezillon wrote: > >> > [...] > >> > Should be done before calling spinand_detect(), just in case some DT > >> > props need to be parsed before the detection step. > >> > > >> > This being said, I'm not sure we should let the spinand controller > >> > driver do the registration step. I'm currently trying to rework the > >> > parallel NAND framework to act like all other busses, and I think SPI > >> > NAND controllers should also follow this road: > >> > > >> > 1/ spinand controller driver register a controller to the spinand core > >> > (spinand_controller_register()) > >> > 2/ the core parses the DT (or board info if DT is not available) and > >> > creates N spinand devices (the N value depends on the number of SPI > >> > nands connected to the controller) > >> > 3/ for each spinand device the detection/initialization takes place > >> > directly in the core (the spinand_controller_ops should contain > >> > anything required to do the detection) > >> > 4/ for each spinand dev the spinand_controller_ops->add() is called, to > >> > let the controller driver attach private data to the device (if > >> > required), and/or let it use it's own ECC engine (optional as well). > >> > 5/ underlying MTD device registered by spinand core code and spinand > >> > dev added to the list of devices controlled by this controller (done > >> > in the core) > >> > > >> > When removing a device, you just have the reverse steps: > >> > > >> > 1/ remove from list and unregister the MTD dev > >> > 2/ call spinand_controller_ops->remove() > >> > 3/ core/manufacturer cleanup > >> > > >> > Not sure how feasible this is, especially for the generic SPI NAND > >> > controller case where the SPI NAND controller does not have a node in > >> > the DT, but that would avoid all this boiler-plate duplication we have > >> > in the // NAND framework. > >> > >> Since the probe for generic spi devices is generally triggered by the > >> SPI layer, it will not match easily in the way you would like the > >> registration done. > > > > That's true, but I think we can find something to handle this case. > > > >> Can we let this registration question not be a showstopper for Peter's > >> effort ? > > > > Sure, I was just thinking out loud. > > Excellent idea, It's a quite big change, Let me try to how far I can go in v4. Let's keep that for later. Also, can you wait a bit before sending a v4, I know Cyrille wanted to comment on the SPI/dual-SPI/quad-SPI handling. Actually, I'd like to have feedback from both SPI NOR maintainers (Cyrille and Marek), can you Cc them in your next version?