lkml.org 
[lkml]   [2017]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v6 00/17] mtd: nand: allow vendor specific detection/initialization
    +Thomas who is currently working on on-die ECC support for a Micron
    NAND and is basing his work on this series.

    On Mon, 9 Jan 2017 11:04:07 +0100
    Boris Brezillon <boris.brezillon@free-electrons.com> wrote:

    > Hello,
    >
    > I know I said it would be the last round, but I decided to change a few
    > things after Marek's review.
    >
    > Marek, Richard, I dropped your R-b/A-b tags on "mtd: nand: Add
    > manufacturer specific initialization/detection steps" (patch 8) and
    > "mtd: nand: Kill the MTD_NAND_IDS Kconfig option" (patch 6) since they
    > changed a bit in v6.
    > Can you have a look?
    >
    > Marek, I did not address your concern regarding the use of the extern
    > keyword for struct nand_manufacturer_ops defs. Let me know if this is
    > something you really find important, and why. If you have a good reason
    > to hide these objects behind an accessor, I might reconsider your
    > suggestion.
    >
    > 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 5 are simple reworks simplifying auto-detection function
    > prototypes, and clarifying their purpose.
    >
    > 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.
    >
    > Patch 7 is hiding NAND manufacturer table internals and exposing a
    > helper to get a nand_manufacturer object from a manufacturer ID.
    >
    > Patch 8 is introducing the vendor-specific initialization
    > infrastructure.
    >
    > Patches 9 to 14 are moving vendor-specific code into their respective
    > nand_<vendor>.c files.
    >
    > Patch 15 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 16 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 17 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 :).

    Applied, after fixing the bug reported by Julia.

    I might decide to drop these patches if someone reports a regression,
    hence the decision to apply them quite early in nand/next.

    \
     
     \ /
      Last update: 2017-03-16 10:05    [W:3.159 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site