Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1409406
| 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 |
[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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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