| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
nand_release() is supposed be called after MTD device registration.
Here, only nand_scan() happened, so use nand_cleanup() instead.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
which makes this change possible. However, pointing this commit as the
culprit for backporting purposes makes sense even if this commit is not
introducing any bug.
Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
Signed-off-by: Miquel Raynal <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Cc: Paul Cercueil <[email protected]>
Cc: Harvey Hunt <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
nand_release() is supposed be called after MTD device registration.
Here, only nand_scan() happened, so use nand_cleanup() instead.
There is no real Fixes tag applying here as the use of nand_release()
in this driver predates the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
which makes this change possible. Hence, pointing it as the commit to
fix for backporting purposes, even if this commit is not introducing
any bug makes sense.
Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
Signed-off-by: Miquel Raynal <[email protected]>
Cc: [email protected]
Cc: Paul Cercueil <[email protected]>
Cc: Harvey Hunt <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Cc: Han Xu <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Not sure nand_cleanup() is the right function to call here but in any
case it is not nand_release(). Indeed, even a comment says that
calling nand_release() is a bit of a hack as there is no MTD device to
unregister. So switch to nand_cleanup() for now and drop this
comment.
There is no Fixes tag applying here as the use of nand_release()
in this driver predates by far the introduction of nand_cleanup() in
commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
which makes this change possible. However, pointing this commit as the
culprit for backporting purposes makes sense even if it did not intruce
any bug.
Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources")
Signed-off-by: Miquel Raynal <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Acked-by: Masahiro Yamada <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Denali driver keeps track of devices with a list. Delete items of this
list as long as they are not in use anymore.
Signed-off-by: Miquel Raynal <[email protected]>
Acked-by: Masahiro Yamada <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Cc: Brian Norris <[email protected]>
Cc: Kamal Dasu <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
There are 2 different chips (w25q256fv and w25q256jv) that share
the same JEDEC ID. Only w25q256jv fully supports 4-byte opcodes.
Use SFDP header version to differentiate between them.
Fixes: 10050a02f7d5 ("mtd: spi-nor: Add 4B_OPCODES flag to w25q256")
Signed-off-by: Mantas Pucka <[email protected]>
Signed-off-by: Tudor Ambarus <[email protected]>
|
|
Despite of how spi_nor_parse_bfpt() abuses the structure fields during
their calculation, gcc manages to make some decent code out of that. :-)
Yet adding a local variable to store the BFPT DWORDs during calculations
still saves 12 bytes of the object code (AArch64 gcc 4.8.5)...
Signed-off-by: Sergei Shtylyov <[email protected]>
Signed-off-by: Tudor Ambarus <[email protected]>
|
|
JESD216 rev D makes BFPT 20 DWORDs. Update the BFPT size define to
reflect that.
The check for rev A or later compared the BFPT header length with the
maximum BFPT length, BFPT_DWORD_MAX. Since BFPT_DWORD_MAX was 16, and so
was the BFPT length for both rev A and B, this check worked fine. But
now, since BFPT_DWORD_MAX is 20, it means this check will also stop BFPT
parsing for rev A or B, since their length is 16.
So, instead check for BFPT_DWORD_MAX_JESD216 to stop BFPT parsing for
the first JESD216 version, and check for BFPT_DWORD_MAX_JESD216B for the
next two versions.
Signed-off-by: Pratyush Yadav <[email protected]>
Signed-off-by: Tudor Ambarus <[email protected]>
|
|
JESD216D.01 says that when the address width can be 3 or 4, it defaults
to 3 and enters 4-byte mode when given the appropriate command. So, when
we see a configurable width, default to 3 and let flash that default to
4 change it in a post-bfpt fixup.
This fixes SMPT parsing for flashes with configurable address width. If
the SMPT descriptor advertises variable address width, we use
nor->addr_width as the address width. But since it was not set to any
value from the SFDP table, the read command uses an address width of 0,
resulting in an incorrect read being issued.
Signed-off-by: Pratyush Yadav <[email protected]>
Signed-off-by: Tudor Ambarus <[email protected]>
|
|
The Cypress cy15b104q and cy15v104q are 4Mbit serial SPI F-RAM devices.
Add support for them to the spi-nor driver.
The actual Device ID of this chip is 7f 7f 7f 7f 7f 7f c2 2c 04. That is
six times the continuation code 7f followed by c2 for Ramtron.
Unfortunately the chip sends the Device ID in reversed order, so the
continuation code is not at the beginning, but instead at the end. Even
more unfortunate is that when reading further the chip sends more 7f
codes which means we are not even able to count the continuation codes.
We can only hope that this reversed Device ID will never match any other
devices ID.
Collisions are improbable as of now, the solution from above is good
enough. In case of future collisions one can introduce an INFO9 macro,
with the downsize that struct flash_info would grow and we have lots of
flashes. A more elegant solution would be to introduce dedicated
flash ID tables for each bank in JESP106BA.
Signed-off-by: Sascha Hauer <[email protected]>
[[email protected]: amend commit description with possible
future solutions in case collisions occur.]
Signed-off-by: Tudor Ambarus <[email protected]>
|
|
The correct terminology is serial NOR flash or SPI NOR.
s/SPI-NOR/SPI NOR and s/spi-nor/SPI NOR across the subsystem.
Signed-off-by: Tudor Ambarus <[email protected]>
Reviewed-by: Sergei Shtylyov <[email protected]>
|
|
s25fs256s was identified as s25fl256s. Differentiate between them by
the Family ID using the INFO6 macro.
Fixes: b199489d37b2 ("mtd: spi-nor: add the framework for SPI NOR")
Signed-off-by: Tudor Ambarus <[email protected]>
Reviewed-by: Alexander Sverdlin <[email protected]>
|
|
Add support for Cypress s25fs128s1 flash. Previously the flash is
decoded as s25fl129p1 by mistake.
Add it in the flash info list to correctly decode. The flash also
needs a fixup for s25fs-s family. Further capability of the flash will
be parsed from bfpt.
The flash has been tested under SPI/DUAL/QUAD mode on hisi-sfc-v3xx
controller, all the write/read/erase works well.
Signed-off-by: Yicong Yang <[email protected]>
Signed-off-by: Tudor Ambarus <[email protected]>
|
|
Spansion S25FS-S family has an issue in the Basic Flash Parameter Table
(BFPT): Dword-11 bits 7:4 specify a page size of 512 bytes. Actually
this is configurable in the vendor unique register (CR3V) and even the
factory default setting is to "wrap at 256 bytes", so blindly relying
on BFPT breaks the page writes on these chips. Add the post-BFPT fixup
which restores the default page size of 256 bytes -- to properly read
CR3V this early is quite intrusive and should better be done as a new
feature; Alexander Sverdlin had the patch doing that:
https://patchwork.ozlabs.org/project/linux-mtd/patch/[email protected]/
Fixes: dfd2b74530e ("mtd: spi-nor: add Spansion S25FS512S ID")
Signed-off-by: Sergei Shtylyov <[email protected]>
Reviewed-by: Alexander Sverdlin <[email protected]>
Tested-by: Kuldeep Singh <[email protected]>
Signed-off-by: Tudor Ambarus <[email protected]>
|
|
This helper is not very useful and very often people get confused:
they use nand_release() instead of nand_cleanup().
Let's stop using nand_release() by calling mtd_device_unregister() and
nand_cleanup() directly.
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Add support for the hardware ECC BCH engine.
Please mind that this engine has an important limitation:
BCH implementation does not inform the user when an uncorrectable ECC
error occurs. To workaround this, we avoid using the hardware engine
in the read path and do the computation with the software BCH
implementation, which is faster than mixing hardware (for correction)
and software (for verification).
Signed-off-by: Miquel Raynal <[email protected]>
Reviewed-by: Boris Brezillon <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Add the Arasan NAND controller driver. This brings only NAND
controller support. The ECC engine being a bit subtle, hardware ECC
support will be added in a second time.
This work is based on contributions from Naga Sureshkumar Relli.
Signed-off-by: Miquel Raynal <[email protected]>
Reviewed-by: Boris Brezillon <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
There are cases where ECC bytes are not byte-aligned. Indeed, BCH
implies using a number of ECC bits, which are not always a multiple of
8. We then need a helper like nand_extract_bits() to extract these
syndromes from a buffer.
Signed-off-by: Miquel Raynal <[email protected]>
Reviewed-by: Boris Brezillon <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
The main NAND read page function can loop over "page reads" many times
in if the reading reports uncorrectable error(s) and if the chip
supports the read_retry feature.
In this case, the number of bitflips is summarized between
attempts. Fix this by re-initializing the entire mtd_ecc_stats object
each time we retry.
Suggested-by: Boris Brezillon <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Reviewed-by: Boris Brezillon <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
It seems that several hardware ECC engine use a swapped representation
of bytes compared to software. This might having to do with how the
ECC engine is wired to the NAND controller or the order the bits are
passed to the hardware BCH logic.
This means that when the software BCH engine is working in conjunction
with data generated with hardware, sometimes we might need to swap the
bits inside bytes, eg:
0x0A = b0000_1010 -> b0101_0000 = 0x50
Make it possible by adding a boolean to the BCH initialization routine.
Regarding the implementation itself, this is a rather simple approach
that can probably be enhanced in the future by preparing the
->a_{mod,pow}_tab tables with the swapping in mind.
Suggested-by: Boris Brezillon <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Reviewed-by: Boris Brezillon <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
There are four exported functions, all suffixed by _bch, which is
clearly not the norm. Let's rename them by prefixing them with bch_
instead.
This is a mechanical change:
init_bch -> bch_init
free_bch -> bch_free
encode_bch -> bch_encode
decode_bch -> bch_decode
Signed-off-by: Miquel Raynal <[email protected]>
Reviewed-by: Boris Brezillon <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
There are controllers not able to just read data cycles on the
bus. There are controllers not able to do a change column.
If we want to support both, we need to check which operation is
supported first. This is the exact same mechanism that is in use for
parameter page reads (ONFI/JEDEC) as the same problem occurs.
Speed testing does not show any throughput penalty so we do not
optimize more than that. However it is likely that, in the future, a
more robust and exhaustive test will run at boot time to avoid
re-checking what is supported and what is not at every call.
Signed-off-by: Miquel Raynal <[email protected]>
Reviewed-by: Boris Brezillon <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
The CM-X270 board has been removed, we can remove the custom NAND
driver as well.
Signed-off-by: Boris Brezillon <[email protected]>
Acked-by: Robert Jarzmik <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Mimic what's done in nand_soft_waitrdy() and add one to the jiffies
timeout so we don't end up waiting less than actually required.
Reported-by: Tudor Ambarus <[email protected]>
Fixes: b0e137ad24b6c ("mtd: rawnand: Provide helper for polling GPIO R/B pin")
Cc: <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
Reviewed-by: Tudor Ambarus <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Now that exec_op() is implemented we can get rid of the legacy interface
implementation.
Signed-off-by: Boris Brezillon <[email protected]>
Reviewed-by: Miquel Raynal <[email protected]>
Tested-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
Implement exec_op() so we can later get rid of the legacy interface
implementation.
Signed-off-by: Boris Brezillon <[email protected]>
Tested-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|
|
We can use info->current_cs directly instead of doing this weird
IO_ADDR_{R,W} re-assignment dance.
Signed-off-by: Boris Brezillon <[email protected]>
Reviewed-by: Miquel Raynal <[email protected]>
Tested-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
|