Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756558Ab3EPIHA (ORCPT ); Thu, 16 May 2013 04:07:00 -0400 Received: from co1ehsobe001.messaging.microsoft.com ([216.32.180.184]:50504 "EHLO co1outboundpool.messaging.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756521Ab3EPIGx convert rfc822-to-8bit (ORCPT ); Thu, 16 May 2013 04:06:53 -0400 X-Forefront-Antispam-Report: CIP:70.37.183.190;KIP:(null);UIP:(null);IPV:NLI;H:mail.freescale.net;RD:none;EFVD:NLI X-SpamScore: 3 X-BigFish: VS3(z3121kz98dIc89bh936eI1432I1521Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6h1082kzzz2dh2a8h668h839h93fhe5bhf0ah1288h12a5h12a9h12bdh1354h137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19c3h1ad9h1b0ah1d0ch1d2eh1d3fh1889i1155h) Message-ID: <51949378.6020005@freescale.com> Date: Thu, 16 May 2013 16:06:16 +0800 From: Huang Shijie User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 MIME-Version: 1.0 To: CC: , , , Subject: Re: [PATCH v5 01/11] mtd: add datasheet's ECC information to nand_chip{} References: <1368607232-2210-1-git-send-email-b32955@freescale.com> <1368607232-2210-2-git-send-email-b32955@freescale.com> <1368619917.15764.99.camel@sauron.fi.intel.com> <51944184.7090107@freescale.com> <1368688465.15764.172.camel@sauron.fi.intel.com> In-Reply-To: <1368688465.15764.172.camel@sauron.fi.intel.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8BIT X-OriginatorOrg: freescale.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2050 Lines: 46 于 2013年05月16日 15:14, Artem Bityutskiy 写道: > On Thu, 2013-05-16 at 10:16 +0800, Huang Shijie wrote: >> 于 2013年05月15日 20:11, Artem Bityutskiy 写道: >>> On Wed, 2013-05-15 at 16:40 +0800, Huang Shijie wrote: >>>> + * @ecc_strength: [INTERN] ECC correctability from the datasheet. >>>> + * Minimum amount of bit errors per @ecc_step guaranteed to >>>> + * be correctable. If unknown, set to zero. >>>> + * @ecc_step: [INTERN] ECC step required by the @ecc_strength, >>>> + * also from the datasheet. It is the recommended ECC step >>>> + * size, if known; if unknown, set to zero. >>> Here and in other places you talk about "datasheet". Do you assume that >>> the real ECC strength/step used by NAND chips may be different? Or you >>> assume it must be the same? >>> >> The two fields are used to store the ecc info from the datasheet. >> The two fields are just for a reference. >> >> [1] The nand controller may do not use these two fields, it's ok; >> For example, the datasheet requires "4bits per 512 bytes". >> The nand controller can uses 8bits per 512 bytes. >> >> >> [2] but sometimes the nand controller must use these two fields. >> For example, the datasheet requires "40bits per 1024 bytes". >> For the hardware limit, the nand controller(BCH) may supports the >> 40bits ecc in the maximum. >> So the nand controller must use these two fields now. > I wonder if it makes sense to name things so that it is clear form the > names whether that is the "theoretical" datasheet values or the real > ones. I would prefer to clearly distinguish between them, in names and > comments. Thoughts? > what's about add the "_datasheet" for these two fields? such as ecc_strength__datasheet;ecc_step__datasheet Huang Shijie -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/