Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1409406

Re: [PATCH 13/15] mtd: nand: samsung: retrieve ECC requirements from extended ID

From Valdis.Kletnieks@vt.edu
Newsgroups linux.kernel
Subject Re: [PATCH 13/15] mtd: nand: samsung: retrieve ECC requirements from extended ID
Date 2016-05-30 23:00 +0200
Message-ID <rECs4-VP-87@gated-at.bofh.it> (permalink)
References <rDpwR-3xK-3@gated-at.bofh.it> <rDpwS-3xK-35@gated-at.bofh.it> <rEjfH-5dz-1@gated-at.bofh.it> <rEq7w-1cH-11@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

On Mon, 30 May 2016 09:44:46 +0200, Boris Brezillon said:
> Hi Valdis,

> Actually, that was my first reaction [1], but the more I think about it
> the more I realize it's a non-issue.
> AFAICT, there's no full-id entries for Samsung NANDs in the nand_ids
> table, so this either means there's no real users of Samsung MLCs or
> NAND controller drivers connecting to those chips don't care about the
> ->ecc_{step_ds,strength_ds} fields.

I'm mostly, though not totally convinced (not having looked closely at
the existing code).  There's still a possible issue with the distinction
between:

A) "driver never references the variable" and

B) driver check if it's zero, and acts like it doesn't care if it is, but if
it's non-zero, it goes ahead and uses it, with possible hilarity ensuing if the
value is wrong.

Should be pretty easy for somebody who knows the code better than I to rule
out case B fairly quickly...

> I agree that the solution is not perfect, but I'd prefer seeing the
> NAND detection code iteratively improved than rejecting everything
> until we're 100% sure that all cases are correctly handled (which might
> never happen since NAND vendors introduce new NAND ID scheme if they
> need to).
>
> BTW, do you have Samsung datasheets describing a different NAND ID
> format, or is it purely hypothetical?

Mostly hypothetical.  I've just seen too many patches that assume "all chips
from  vendor XYZ do *this*" that were not at all corrrect.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH 00/15] mtd: nand: allow vendor specific detection/initialization Boris Brezillon <boris.brezillon@free-electrons.com> - 2016-05-27 15:00 +0200
  [PATCH 05/15] mtd: nand: add vendor specific initialization step Boris Brezillon <boris.brezillon@free-electrons.com> - 2016-05-27 15:00 +0200
  [PATCH 13/15] mtd: nand: samsung: retrieve ECC requirements from extended ID Boris Brezillon <boris.brezillon@free-electrons.com> - 2016-05-27 15:00 +0200
    Re: [PATCH 13/15] mtd: nand: samsung: retrieve ECC requirements from extended ID Valdis.Kletnieks@vt.edu - 2016-05-30 02:30 +0200
      Re: [PATCH 13/15] mtd: nand: samsung: retrieve ECC requirements  from extended ID Boris Brezillon <boris.brezillon@free-electrons.com> - 2016-05-30 09:50 +0200
        Re: [PATCH 13/15] mtd: nand: samsung: retrieve ECC requirements from extended ID Valdis.Kletnieks@vt.edu - 2016-05-30 23:00 +0200
          Re: [PATCH 13/15] mtd: nand: samsung: retrieve ECC requirements  from extended ID Boris Brezillon <boris.brezillon@free-electrons.com> - 2016-05-31 00:30 +0200
            Re: [PATCH 13/15] mtd: nand: samsung: retrieve ECC requirements  from extended ID Boris Brezillon <boris.brezillon@free-electrons.com> - 2016-05-31 00:40 +0200
  [PATCH 14/15] mtd: nand: hynix: rework NAND ID decoding to extract more information Boris Brezillon <boris.brezillon@free-electrons.com> - 2016-05-27 15:00 +0200
  [PATCH 09/15] mtd: nand: move toshiba specific initialization in nand_toshiba.c Boris Brezillon <boris.brezillon@free-electrons.com> - 2016-05-27 15:00 +0200

csiph-web