- 31 Jul, 2018 29 commits
-
-
Miquel Raynal authored
Two helpers have been added to the core to do all kind of controller side configuration/initialization between the detection phase and the final NAND scan. Implement these hooks so that we can convert the driver to just use nand_scan() instead of the nand_scan_ident() + nand_scan_tail() pair. Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by:
Boris Brezillon <boris.brezillon@bootlin.com>
-
Miquel Raynal authored
Two helpers have been added to the core to do all kind of controller side configuration/initialization between the detection phase and the final NAND scan. Implement these hooks so that we can convert the driver to just use nand_scan() instead of the nand_scan_ident() + nand_scan_tail() pair. Signed-off-by:
-
Miquel Raynal authored
Two helpers have been added to the core to do all kind of controller side configuration/initialization between the detection phase and the final NAND scan. Implement these hooks so that we can convert the driver to just use nand_scan() instead of the nand_scan_ident() + nand_scan_tail() pair. Signed-off-by:
-
Miquel Raynal authored
Two helpers have been added to the core to do all kind of controller side configuration/initialization between the detection phase and the final NAND scan. Implement these hooks so that we can convert the driver to just use nand_scan() instead of the nand_scan_ident() + nand_scan_tail() pair. Signed-off-by:
-
Miquel Raynal authored
Two helpers have been added to the core to do all kind of controller side configuration/initialization between the detection phase and the final NAND scan. Implement these hooks so that we can convert the driver to just use nand_scan() instead of the nand_scan_ident() + nand_scan_tail() pair. Signed-off-by:
-
Miquel Raynal authored
Two helpers have been added to the core to do all kind of controller side configuration/initialization between the detection phase and the final NAND scan. Implement these hooks so that we can convert the driver to just use nand_scan() instead of the nand_scan_ident() + nand_scan_tail() pair. Signed-off-by:
-
Miquel Raynal authored
Two helpers have been added to the core to do all kind of controller side configuration/initialization between the detection phase and the final NAND scan. Implement these hooks so that we can convert the driver to just use nand_scan() instead of the nand_scan_ident() + nand_scan_tail() pair. Signed-off-by:
Xiaolei Li <xiaolei.li@mediatek.com>
-
Miquel Raynal authored
Two helpers have been added to the core to do all kind of controller side configuration/initialization between the detection phase and the final NAND scan. Implement these hooks so that we can convert the driver to just use nand_scan() instead of the nand_scan_ident() + nand_scan_tail() pair. Signed-off-by:
-
Miquel Raynal authored
Two helpers have been added to the core to do all kind of controller side configuration/initialization between the detection phase and the final NAND scan. Implement these hooks so that we can convert the driver to just use nand_scan() instead of the nand_scan_ident() + nand_scan_tail() pair. Signed-off-by:
-
Miquel Raynal authored
Two helpers have been added to the core to do all kind of controller side configuration/initialization between the detection phase and the final NAND scan. Implement these hooks so that we can convert the driver to just use nand_scan() instead of the nand_scan_ident() + nand_scan_tail() pair. Signed-off-by:
Harvey Hunt <harveyhuntnexus@gmail.com> Reviewed-by:
-
Miquel Raynal authored
Two helpers have been added to the core to do all kind of controller side configuration/initialization between the detection phase and the final NAND scan. Implement these hooks so that we can convert the driver to just use nand_scan() instead of the nand_scan_ident() + nand_scan_tail() pair. Signed-off-by:
-
Miquel Raynal authored
Two helpers have been added to the core to do all kind of controller side configuration/initialization between the detection phase and the final NAND scan. Implement these hooks so that we can convert the driver to just use nand_scan() instead of the nand_scan_ident() + nand_scan_tail() pair. Signed-off-by:
-
Miquel Raynal authored
Two helpers have been added to the core to do all kind of controller side configuration/initialization between the detection phase and the final NAND scan. Implement these hooks so that we can convert the driver to just use nand_scan() instead of the nand_scan_ident() + nand_scan_tail() pair. Signed-off-by:
-
Miquel Raynal authored
Two helpers have been added to the core to do all kind of controller side configuration/initialization between the detection phase and the final NAND scan. Implement these hooks so that we can convert the driver to just use nand_scan() instead of the nand_scan_ident() + nand_scan_tail() pair. Signed-off-by:
-
Miquel Raynal authored
Two helpers have been added to the core to do all kind of controller side configuration/initialization between the detection phase and the final NAND scan. Implement these hooks so that we can convert the driver to just use nand_scan() instead of the nand_scan_ident() + nand_scan_tail() pair. Signed-off-by:
-
Miquel Raynal authored
Return -ENOTSUPP instead of -1 from ->chip_init_tail() before migrating this driver to use nand_scan() and transform this function to be a callback run by the core. Signed-off-by: -
Miquel Raynal authored
Two helpers have been added to the core to do all kind of controller side configuration/initialization between the detection phase and the final NAND scan. Implement these hooks so that we can convert the driver to just use nand_scan() instead of the nand_scan_ident() + nand_scan_tail() pair. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com>
-
Miquel Raynal authored
Two helpers have been added to the core to do all kind of controller side configuration/initialization between the detection phase and the final NAND scan. Implement these hooks so that we can convert the driver to just use nand_scan() instead of the nand_scan_ident() + nand_scan_tail() pair. Also change the unused "struct device *dev" parameter of the driver structure into a platform device to reuse it in the ->attach_chip() hook. Signed-off-by:
-
Boris Brezillon authored
We don't use the GPIO API in this driver, let's just remove the <linux/gpio.h> inclusion. Signed-off-by:
-
Boris Brezillon authored
gpio/consumer.h defines everything we need, and it's clearly stated in gpio.h that GPIO consumers should directly stop including gpio.h if they can. Signed-off-by:
-
Boris Brezillon authored
Commit ddd5ed3a ("mtd: rawnand: sunxi: Remove support for GPIO-based Ready/Busy polling") removed GPIO-based RB polling. We no longer need to include gpio headers. Signed-off-by:
-
Boris Brezillon authored
GPIO consumers should no longer include <linux/gpio.h>, and instead include <linux/gpio/consumer.h>. Also, explicitly include <include/io.h> since it seems to be missing after switching to <linux/gpio/consumer.h>. This fixes a build error when selecting the driver without selecting GPIOLIB, which can happen when COMPILE_TEST=y. Fixes: 6968e07e ("mtd: rawnand: jz4740: Allow selection of this driver when COMPILE_TEST=y") Reported-by:
-
Miquel Raynal authored
In order to remove the limitation that forbids dynamic allocation in nand_scan_ident(), we must create a path that will be the same for all controller drivers. The idea is to use nand_scan() instead of the widely used nand_scan_ident()/nand_scan_tail() couple. In order to achieve this, controller drivers will need to adjust some parameters between these two functions depending on the NAND chip wired on them. This takes the form of two new hooks (->{attach,detach}_chip()) that are placed in a new nand_controller_ops structure, which is then attached to the nand_controller object at driver initialization time. ->attach_chip() is called between nand_scan_ident() and nand_scan_tail(), and ->detach_chip() is called in the error path of nand_scan() and in nand_cleanup(). Note that some NAND controller drivers don't have a dedicated nand_controller object and instead rely on the default/dummy one embedded in nand_chip. If you're in this case and still want to initialize the controller ops, you'll have to manipulate chip->dummy_controller directly. Last but not least, it's worth mentioning that we plan to move some of the controller related hooks placed in nand_chip into nand_controller_ops to make the separation between NAND chip and NAND controller methods clearer. Signed-off-by: -
Miquel Raynal authored
In the raw NAND core, a NAND chip is described by a nand_chip structure, while a NAND controller is described with a nand_hw_control structure which is not very meaningful. Rename this structure nand_controller. As the structure gets renamed, it is logical to also rename the core function initializing it from nand_hw_control_init() to nand_controller_init(). Lastly, the 'hwcontrol' entry of the nand_chip structure is not meaningful neither while it has the role of fallback when no controller structure is provided by the driver (the controller driver is dumb and can only control a single chip). Thus, it is renamed dummy_controller. Signed-off-by:
-
Boris Brezillon authored
Commit 260e89a6 ("mtd: core: tone down suggestion that dev.parent should be set") removed the only user of caller_is_module() but forgot to remove the definition itself. Let's remove it now. Signed-off-by:
-
Boris Brezillon authored
All of the code in the probe path assumes ->sets != NULL and ->nrsets > 0. Error out if that's not the case to avoid dereferencing a NULL pointer. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Miquel Raynal authored
A report from Colin Ian King pointed a CoverityScan issue where error values on these helpers where not checked in the drivers. These helpers can error out only in case of a software bug in driver code, not because of a runtime/hardware error. Hence, let's WARN_ON() in this case and return 0 which is harmless anyway. Fixes: 8878b126 ("mtd: nand: add ->exec_op() implementation") Signed-off-by:
-
Boris Brezillon authored
Make sure __LINUX_ARM_ARCH__ is defined before testing its value. This is needed if we want to allow selection of this driver when COMPILE_TEST=y. Signed-off-by:
-
Boris Brezillon authored
Include linux/sizes.h instead of asm/sizes.h to make code completely arch independent. Signed-off-by:
-
- 19 Jul, 2018 11 commits
-
-
Boris Brezillon authored
We currently don't store the on-die ECC state (enabled/disabled) which might force us to re-disable the engine even if it's already been disabled after we've read the page in raw mode to count the actual number of bitflips. Add an "enabled" field to struct micron_on_die_ecc to keep track of the ECC state. Signed-off-by:
Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by:
-
Boris Brezillon authored
Some chips have their on-die ECC forcibly enabled, there's no point in trying to enable/disable the ECC engine in that case. Signed-off-by:
-
Boris Brezillon authored
The MT29F2Gxxx chips with 4bits/512byte on-die ECC let us know when some bitflips were corrected by the on-die ECC, but they do not report the actual number of bitflips that were present in the data+ECC chunk. We initially decided to always return ecc->strength to avoid re-reading the page in raw mode + comparing it to the corrected buffer to extract the real number of bitflips, but this forces UBI to move data around as soon as one bitflip is present in a page. This not only wears the NAND out faster, but also degrades performances, since reading a full PEB + writing it back to a different PEB + erasing the old one is much more expensive than re-reading the faulty page in raw mode and comparing it to the corrected buffer. In most cases, the actual number of bitflips does not exceed the bitflips threshold, and UBI won't have to move data around. Otherwise, we can assume the time spent re-reading the page and doing the comparison is negligible compared to the time UBI spends moving a full PEB to another PEB. Note that this logic is not applied to chips with 8bits/512byte on-die ECC, because those chips provide fine-grained information (the maximum error is 1 bit, and it will not force UBI to move blocks around at the first bitflip). Suggested-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
-
Chris Packham authored
Some Micron NAND chips have on-die ECC forceably enabled. Allow such chips to be used as long as the controller has set chip->ecc.mode to NAND_ECC_ON_DIE. Signed-off-by:
-
Boris Brezillon authored
Some implementations simply can't disable their ECC engine. Expose helpers returning -ENOTSUPP so that the caller knows that raw accesses are not supported instead of silently falling back to non-raw accessors. Signed-off-by:
-
Chris Packham authored
Micron MT29F1G08ABAFAWP-ITE:F supports an on-die ECC with 8 bits per 512 bytes. Add support for this combination. Signed-off-by:
-
Boris Brezillon authored
Basing the "mandatory on-die" detection on ID byte 2 does not work, because Micron has plenty of NANDs using the same device ID code, and not all of them have forcibly enabled on-die ECC. Since the "Array Operation" feature does not provide the "ECC enabled/disabled" bit when the ECC can't be disabled, let's try to use the "ECC enabled/disabled" bit in the READ_ID bytes. It seems that this bit is dynamically updated on NANDs where on-die ECC can freely be enabled/disabled, so let's hope it stays at one when we have a NAND with on-die ECC forcibly enabled. Fixes: 51f3b3970a8c ("mtd: rawnand: micron: detect forced on-die ECC") Signed-off-by: -
Boris Brezillon authored
chip->read_buf is left unassigned since commit 4da712e7 ("mtd: nand: fsmc: use ->exec_op()"), leading to a NULL pointer dereference when it's called from fsmc_read_page_hwecc(). Fix that by using the appropriate helper to read data out of the NAND. Fixes: 4da712e7 ("mtd: nand: fsmc: use ->exec_op()") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Arnd Bergmann authored
Compile-testing this driver on x86 caused a link error: ERROR: "__phys_to_dma" [drivers/mtd/nand/raw/qcom_nandc.ko] undefined! The problem here is that the driver attempts to convert the physical address into the DMA controller as a dma_addr_t and calls phys_to_dma() to do the conversion. The correct way to do the conversion is using the dma mapping interfaces. Fixes: c76b78d8 ("mtd: nand: Qualcomm NAND controller driver") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
-
Stefan Agner authored
The Tegra driver currently only support a single chip select, hence check boundaries accordingly. This fixes a off by one issue catched with Smatch: drivers/mtd/nand/raw/tegra_nand.c:476 tegra_nand_select_chip() warn: array off by one? 'nand->cs[die_nr]' Also warn in case the stack asks for a chip select we currently do not support. Reported-by:Stefan Agner <stefan@agner.ch> Signed-off-by:
Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by:
-
Miquel Raynal authored
Some timings like tBERS (block erase time), tCCs (change column setup time), tPROG (page program time) and tR (page read time) are derived from the ONFI parameter page. They are set in the SDR interface only if the chip is ONFI compliant. It makes these timings unreliable and prevent the driver to use one of these four values with a non-ONFI chip. Fix this situation by taking the highest possible value (or a default one) value for each missing timing (stored as unsigned 16-bit entries in the parameter page). This makes tBERS and tPROG being ~65ms while typical values are at most a few milliseconds. As these are timeouts, it is not impacting at all the performances in nominal use. tR maximum time and tCCS minimum time (delay to wait after a change column) are set, according to the ONFI specification, to default 'slow' values; respectively 200us and 500ns. Signed-off-by:
-
