public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: Huang Shijie <b32955@freescale.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"dwmw2@infradead.org" <dwmw2@infradead.org>,
	"Gupta, Pekon" <pekon@ti.com>,
	"dedekind1@gmail.com" <dedekind1@gmail.com>
Subject: Re: [PATCH v3 3/6] mtd: set the ecc step size for master/slave mtd_info
Date: Mon, 12 Aug 2013 17:25:12 -0700	[thread overview]
Message-ID: <20130813002512.GC7267@brian-ubuntu> (raw)
In-Reply-To: <5208AE99.6020508@freescale.com>

On Mon, Aug 12, 2013 at 05:44:57PM +0800, Huang Shijie wrote:
> 于 2013年08月12日 17:24, Gupta, Pekon 写道:
> >[Pekon]: Following Artem's recommendations.. Can this be named as
> >chip->ecc.size = ecc_step_size.
> >then chip->ecc.bytes  = ecc_syndrome_size (or ecc_code_size)
> yes, we can rename these fields in the future with another patch set.

Internal naming can be changed in the future if needed, but we really
need to get a good sysfs name now, since that becomes ABI. And it would
also be good to get this to be clearly consistent internally too.

So the main decision to be made here: what to name the sysfs field? It
currently stands as ecc_step, but for clarity to users (and for avoiding
internal confusion with nand_chip.ecc.steps), I think ecc_step_size is
just as good or better.

Then, we might as well have the mtd_info field be
mtd_info.ecc_step_size. So we would have the following names.

For ECC step size:

  /sys/class/mtd/mtdX/ecc_step_size
  mtd_info.ecc_step_size
  nand_chip.ecc.size    <--- candidate for renaming to ...ecc.step_size

For ECC strength:

  /sys/class/mtd/mtdX/ecc_strength
  mtd_info.ecc_strength
  nand_chip.ecc.strength

Other fields to consider for internal naming:

  # Number of ECC steps per page
  nand_chip.ecc.steps

  # Number of ECC bytes per ECC step
  nand_chip.ecc.bytes

Please, let's get an agreement on one of these, so we hopefully only
need at most a v4 patch series:

(1) Huang's current patch set (v3)
(2) My proposed naming above
(3) A third option? (AFAICT, (1) or (2) should be satisfactory)

If we go with (2), the v4 patch series only needs to take care of the
new sysfs naming (plus documentation) and the new mtd_info field naming.
Any internal consistency patches (e.g., for nand_ecc_ctrl) can come as
follow-ups.

> >In addition, chip->ecc.bytes should also be helpful for userspace
> >utility to determine how much bytes to reserve in spare-area for ECC.
> >So exposing that as sysfs entry is also good.
> >
> I do not need the chip->ecc.bytes. :)
> For me, export the chip->ecc.size is enough.

A better argument against this is that ecc.bytes does not necessarily
have utility across many types of NAND drivers by itself, since ECC
layouts differ. And at that point, we're trying to duplicate the
behavior of ioctl(ECCGETLAYOUT) (which notably has run out of room and
isn't 100% informative anymore).

> So you can submit a patch if you need this field.

Yes, if you have good reason for exporting it, send a patch and a good
argument. And it would need to explain why we can't just use
ECCGETLAYOUT.

Brian

  reply	other threads:[~2013-08-13  0:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-12  5:24 [PATCH v3 0/6] Export the ECC step size to user applications Huang Shijie
2013-08-12  5:24 ` [PATCH v3 1/6] mtd: add a new field to mtd_info{} Huang Shijie
2013-08-12  5:24 ` [PATCH v3 2/6] mtd: add a new sys node to show the ecc step size Huang Shijie
2013-08-12  5:24 ` [PATCH v3 3/6] mtd: set the ecc step size for master/slave mtd_info Huang Shijie
2013-08-12  7:00   ` Gupta, Pekon
2013-08-12  8:28     ` Huang Shijie
2013-08-12  9:24       ` Gupta, Pekon
2013-08-12  9:44         ` Huang Shijie
2013-08-13  0:25           ` Brian Norris [this message]
2013-08-13  4:29             ` Gupta, Pekon
2013-08-13  6:14               ` Huang Shijie
2013-08-17 18:58               ` Brian Norris
2013-08-12  5:24 ` [PATCH v3 4/6] mtd: set ONFI nand's default hooks in nand_set_defaults() Huang Shijie
2013-08-12  5:24 ` [PATCH v3 5/6] mtd: gpmi: remove the nand_scan() Huang Shijie
2013-08-12  5:24 ` [PATCH v3 6/6] mtd: update the ABI document about the ecc step Huang Shijie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130813002512.GC7267@brian-ubuntu \
    --to=computersforpeace@gmail.com \
    --cc=b32955@freescale.com \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=pekon@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox