From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753474AbcKTK0o (ORCPT ); Sun, 20 Nov 2016 05:26:44 -0500 Received: from mail.free-electrons.com ([62.4.15.54]:39794 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753290AbcKTK0l (ORCPT ); Sun, 20 Nov 2016 05:26:41 -0500 Date: Sun, 20 Nov 2016 11:26:36 +0100 From: Boris Brezillon To: Richard Weinberger Cc: "linux-mtd@lists.infradead.org" , LKML , Daniel Walter Subject: Re: [PATCH v2 00/46] Nandsim facelift (part I of II) Message-ID: <20161120112636.257dd8c9@bbrezillon> In-Reply-To: References: <20161016182441.49adc653@bbrezillon> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; 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 Richard, On Mon, 14 Nov 2016 17:24:18 +0100 Richard Weinberger wrote: > Boris, > > sorry for the late answer. I was not on CC, therefore this mail was > unnoticed by me. :-( > > On Sun, Oct 16, 2016 at 6:24 PM, Boris Brezillon > wrote: > > Daniel, Richard, > > > > On Wed, 21 Sep 2016 11:43:29 +0200 > > Daniel Walter wrote: > > > >> Changes since V1: > >> Incooperate feedback for nand_cleanup() > >> Improve commit messages > > [..-] > > > I really like the new approach for 2 reasons: > > 1/ it allows creating several NAND devs, and you can do that after the > > module has been loaded. > > 2/ it fixes the partial NAND detection support by allowing one to > > describe its NAND in term of page size, eraseblock size, oob > > size, ... > > > > But I'm wondering if we should not create a new driver instead of > > trying to fix the old one (I must admit I haven't been through the 46 > > patches of this series, but last time we discussed it on IRC, Richard > > said it actually was a complete rewrite of the nandsim driver). > > > > Moreover, if we specify the flash layout manually, maybe we could make > > it an mtdsim driver instead of restricting the emulation to NAND > > devices. > > > > What do you think? > > I think we don't need a completely new driver. This series just adds > functionality to nandsim without much cost, in fact we reuse also some > bits from nandsim. > If we add a new nandsim alike driver we basically give up the current nandsim > and it will die a painful death. This series tries to avoid that. Well, the whole problem with the current nandsim driver is that it tries to do too many things. It not only tries to emulate a NAND device, with all its constraint (bitflips, and many more), but it also tries to register as a NAND driver with the NAND dev detection flow, and all the convoluted page read/write logic (with/without ECC, ...). Life (and code) would be much easier if the emulation driver was just trying to emulate a NAND device without registering to the NAND framework. All you'd have to do is implement your own mtd_info hooks, without this nandsim device state burden that is required for ->cmd_ctrl() to work properly. Of course, adding a new driver means marking the old one as deprecated and keeping it around for some time, but that's IMHO, cleaner than keeping a lot of code for something that we do not want to maintain. One example is the NAND ID detection: it is a real pain, and we have no easy solution to support ONFI chips. If we go for a solution where the user select all the NAND properties manually, we get rid of this complex beast, while leaving more freedom to test some corner cases (non-powerof2 number of blocks per die for example). > What we can do is splitting nandsim into three files (common, old and new). Well, it's not really about creating new files, it's more about maintaining things that IMO are not so useful... Regards, Boris