From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751335AbcFRWJs (ORCPT ); Sat, 18 Jun 2016 18:09:48 -0400 Received: from b.ns.miles-group.at ([95.130.255.144]:44723 "EHLO radon.swed.at" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751046AbcFRWJr (ORCPT ); Sat, 18 Jun 2016 18:09:47 -0400 Subject: Re: [PATCH v2 00/15] mtd: nand: allow vendor specific detection/initialization To: Boris Brezillon , David Woodhouse , Brian Norris , linux-mtd@lists.infradead.org References: <1465390849-13199-1-git-send-email-boris.brezillon@free-electrons.com> Cc: Hans de Goede , linux-kernel@vger.kernel.org, Aleksei Mamlin From: Richard Weinberger Message-ID: <5765C6A6.3070206@nod.at> Date: Sun, 19 Jun 2016 00:09:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <1465390849-13199-1-git-send-email-boris.brezillon@free-electrons.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 08.06.2016 um 15:00 schrieb Boris Brezillon: > Hello, > > This patch series is a step forward in supporting vendor-specific > functionalities. > This series is mainly moving vendor-specific initialization or > detection code out of the core, but also introduces an infrastructure > allowing support for vendor-specific features. > > While those features might seem useless to most users, some of them are > actually required on modern MLC/TLC NANDs (this is the case of read-retry > support, which AFAICT has not been standardized by the JEDEC consortium). > > Now, let's detail what's inside this patch-set. > > Patches 1 to 4 are simple reworks simplifying auto-detection function > prototypes, and clarifying their purpose. > > Patch 5 is introducing the vendor-specific initialization > infrastructure. > > Patch 6 is removing the MTD_NAND_IDS Kconfig option to avoid creating > a nand_ids.ko module when MTD_NAND is enabled as a module. This prevents > a future cross-dependency between nand.ko where all vendor specific > code will rely and nand_ids.ko which will reference vendor-specific ops > in its manufacturer table, which in turn is referenced by the core code > linked in nand.ko. > > Patches 7 to 12 are moving vendor-specific code into their respective > nand_.c files. > > Patch 13 is taking a patch proposed by Hans and adding support for ECC > requirements extraction from the samsung extended IDs. It seems to apply > to all Samsung MLCs, but even if it's not the case, the detection code > should be improved to support the new formats. > > Patch 14 is adding support for advanced NAND ID decoding to the Hynix > driver (OOB size, ECC and scrambling requirements extraction). Again > this detection code might be incomplete, but I'd like people to extend > it if required rather than adding new full-id entries in the nand_ids > table. > > And finally, patch 15 is showing how useful this vendor-specific stuff > can be by implementing read-retry support for Hynix 1x nm MLCs. And > trust me, you don't want to try using such a NAND without read-retry > support ;). > > As always, I'm open to any suggestion to improve this vendor-specific > infrastructure, so please review the code :). Series looks good to me. :-) BTW: I wonder whether this work can also be used to support Micron On-Die-ECC and Toshiba BENAND in a proper way. Thanks, //richard