- 23 9月, 2016 5 次提交
-
-
由 Boris Brezillon 提交于
The NAND framework provides several helpers to query timing modes supported by a NAND chip, but this implies that all NAND controller drivers have to implement the same timings selection dance. Also currently NAND devices can be resetted at arbitrary places which also resets the timing for ONFI chips to timing mode 0. Provide a common logic to select the best timings based on ONFI or ->onfi_timing_mode_default information. Hook this into nand_reset() to make sure the new timing is applied each time during a reset. NAND controller willing to support timings adjustment should just implement the ->setup_data_interface() method. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
-
由 Sascha Hauer 提交于
When NAND devices are resetted some initialization may have to be done, like for example they have to be configured for the timing mode that shall be used. To get a common place where this initialization can be implemented create a nand_reset() function. This currently only issues a NAND_CMD_RESET to the NAND device. The places issuing this command manually are replaced with a call to nand_reset(). Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de> Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
由 Andrey Smirnov 提交于
Using "goto" and "switch" statement only makes it harder to follow control flow and doesn't bring any advantages. Rewrite the code to avoid using "goto". Signed-off-by: NBrian Norris <computersforpeace@gmail.com> Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
由 Andrey Smirnov 提交于
If no user specified chip->select_chip() function is provided, code in nand_base.c will automatically set this hook to nand_select_chip(), which in turn depends on chip->cmd_ctrl() hook being valid. Not providing both of those functions in NAND controller driver (for example by mistake) will result in a bit cryptic segfault. Same is true for chip->cmdfunc(). To avoid the above scenario add a check in nand_scan_dent and error out if cmd_ctrl() is not provided. Suggested-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Suggested-by: NBrian Norris <computersforpeace@gmail.com> Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
由 Marc Gonzalez 提交于
The code to initialize a struct nand_hw_control is duplicated across several drivers. Factorize it using an inline function. Signed-off-by: NMarc Gonzalez <marc_gonzalez@sigmadesigns.com> Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
- 20 7月, 2016 1 次提交
-
-
由 Hector Palacios 提交于
nand_do_write_ops() determines if it is writing a partial page with the formula: part_pagewr = (column || writelen < (mtd->writesize - 1)) When 'writelen' is exactly 1 byte less than the NAND page size the formula equates to zero, so the code doesn't process it as a partial write, although it should. As a consequence the function remains in the while(1) loop with 'writelen' becoming 0xffffffff and iterating endlessly. The bug may not be easy to reproduce in Linux since user space tools usually force the padding or round-up the write size to a page-size multiple. This was discovered in U-Boot where the issue can be reproduced by writing any size that is 1 byte less than a page-size multiple. For example, on a NAND with 2K page (0x800): => nand erase.part <partition> => nand write $loadaddr <partition> 7ff [Editor's note: the bug was added in commit 29072b96, but moved around in commit 66507c7b ("mtd: nand: Add support to use nand_base poi databuf as bounce buffer")] Fixes: 29072b96 ("[MTD] NAND: add subpage write support") Signed-off-by: NHector Palacios <hector.palacios@digi.com> Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Cc: <stable@vger.kernel.org> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
- 06 5月, 2016 8 次提交
-
-
由 Rafał Miłecki 提交于
So far it was only possible to specify ECC algorithm using "soft" and "soft_bch" values of nand-ecc-mode prop. There wasn't a way to specify it for a hardware ECC mode. Now that we have independent field in NAND subsystem for storing info about ECC algorithm we may also add support for this new DT property. Signed-off-by: NRafał Miłecki <zajec5@gmail.com> Acked-by: NRob Herring <robh@kernel.org> Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
由 Rafał Miłecki 提交于
This value should not be part of nand_ecc_modes_t as it specifies algorithm not a mode. We successfully managed to introduce new "algo" field which is respected now. Signed-off-by: NRafał Miłecki <zajec5@gmail.com> Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
由 Rafał Miłecki 提交于
There isn't any difference between handling NAND_ECC_SOFT and NAND_ECC_SOFT_BCH now. What matters is the new field called "algo". Please note we're keeping backward DT compatibility. We are still treating "soft_bch" value as the one setting Hamming algorithm, it's just handled in of_get_nand_ecc_algo now. Signed-off-by: NRafał Miłecki <zajec5@gmail.com> Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
由 Rafał Miłecki 提交于
Now we have all drivers properly setting this new field we can start using it. For a very short period of time we should support both values: NAND_ECC_SOFT and NAND_ECC_SOFT_BCH treating them the same. It's because of_get_nand_ecc_mode may still be setting NAND_ECC_SOFT_BCH. Signed-off-by: NRafał Miłecki <zajec5@gmail.com> Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
由 Rafał Miłecki 提交于
This is part of process deprecating NAND_ECC_SOFT_BCH (and switching to enum nand_ecc_algo). Signed-off-by: NRafał Miłecki <zajec5@gmail.com> Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
由 Boris Brezillon 提交于
Now that all drivers go through nand_set_flash_node() to parse the generic NAND properties, we can move all of_get_nand_xxx() helpers in to nand_base.c, make them static and remove of_mtd.c and of_mtd.h. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
由 Boris Brezillon 提交于
Now that all NAND drivers have switched to mtd_ooblayout_ops, we can kill the ecc->layout field. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
由 Boris Brezillon 提交于
Replace the nand_ecclayout definition by the equivalent mtd_ooblayout_ops definition. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
- 20 4月, 2016 6 次提交
-
-
由 Boris Brezillon 提交于
Replace the default nand_ecclayout definitions for large and small page devices with the equivalent mtd_ooblayout_ops. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
由 Boris Brezillon 提交于
Use the mtd_set_ecclayout() helper instead of directly assigning the mtd->ecclayout field. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
由 Boris Brezillon 提交于
The mtd_ooblayout_xxx() helper functions have been added to avoid direct accesses to the ecclayout field, and thus ease for future reworks. Use these helpers in all places where the oobfree[] and eccpos[] arrays where directly accessed. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
由 Boris Brezillon 提交于
Export the default read/write oob functions (for the standard and syndrome scheme), so that drivers can use them for their raw implementation and implement their own functions for the normal oob operation. This is required if your ECC engine is capable of fixing some of the OOB data. In this case you have to overload the ->read_oob() and ->write_oob(), but if you don't specify the ->read/write_oob_raw() functions they are assigned to the ->read/write_oob() implementation, which is not what you want. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
由 Ezequiel García 提交于
There's no reason to BUG() when parameters are being validated. Drivers can get things wrong, and it's much nicer to just throw a noisy warn and fail gracefully, than calling BUG() and throwing the whole system down the drain. Signed-off-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar> Reviewed-by: NRichard Weinberger <richard@nod.at> Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
由 Rafał Miłecki 提交于
Use recently added of_get_nand_ecc_algo for that. Signed-off-by: NRafał Miłecki <zajec5@gmail.com> Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
- 13 4月, 2016 1 次提交
-
-
由 Ezequiel Garcia 提交于
This commit removes the "nand-disk" LED trigger from the NAND code. A trigger with the same name is already available selecting LEDS_TRIGGER_MTD. Note that "nand-disk" trigger is being deprecated in favor of the "mtd" trigger. Signed-off-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar> Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>
-
- 03 4月, 2016 1 次提交
-
-
由 Ezequiel García 提交于
Since commit 807f16d4 ("mtd: core: set some defaults when dev.parent is set"), it's now legal for drivers to call nand_scan and nand_scan_ident without setting mtd.owner. Drop the check and while at it remove the BUG() abuse. Fixes: 807f16d4 ("mtd: core: set some defaults when dev.parent is set") Signed-off-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar> Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com> [Brian: editorial note - while commit 807f16d4 wasn't explicitly broken, some follow-up commits in the v4.4 release broke a few drivers, since they would hit this BUG() if they used nand_scan() and were built as modules] Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
- 12 3月, 2016 1 次提交
-
-
由 Brian Norris 提交于
The 'getchip' parameter is gone as of commit 9f3e0429 ("mtd: nand: don't select chip in nand_chip's block_bad op"), so kill the doc with it. Reported-by: Nkbuild test robot <fengguang.wu@intel.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com> Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
- 11 3月, 2016 1 次提交
-
-
由 Archit Taneja 提交于
One of the arguments passed to struct nand_chip's block_bad op is 'getchip', which, if true, is supposed to get and select the nand device, and later unselect and release the device. This op is intended to be replaceable by drivers. The drivers shouldn't be responsible for selecting/unselecting chip. Like other ops, the chip should already be selected before the block_bad op is called. Remove the getchip argument from the block_bad op and nand_block_checkbad. Move the chip selection to nand_block_isbad, since it is the only caller to nand_block_checkbad which requires chip selection. Modify nand_block_bad (the default function for the op) such that it doesn't select the chip. Remove the getchip argument from the bad_block funcs in cafe_nand, diskonchip and docg4 drivers. Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
- 08 3月, 2016 4 次提交
-
-
由 Boris BREZILLON 提交于
nand_bch_init() requires several arguments which could directly be deduced from the mtd device. Get rid of those useless parameters. nand_bch_init() is also requiring the caller to provide a proper eccbytes value, while this value could be deduced from the ecc.size and ecc.strength value. Fallback to eccbytes calculation when it is set to 0. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
由 Boris BREZILLON 提交于
Currently, all MTD drivers/sublayers exposing an OOB area are doing the same kind of test to extract the available OOB size based on the mtd_info and mtd_oob_ops structures. Move this common logic into an inline function and make use of it. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Suggested-by: NPriit Laes <plaes@plaes.org> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
由 Boris BREZILLON 提交于
ecclayout->oobavail is just redundant with the mtd->oobavail field. Moreover, it prevents static const definition of ecc layouts since the NAND framework is calculating this value based on the ecclayout->oobfree field. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
由 Brian Norris 提交于
In commit b70af9be ("mtd: nand: increase ready wait timeout and report timeouts"), we increased the likelihood of scheduling during nand_wait(). This makes us more likely to hit the time_before(...) condition, since a lot of time may pass before we get scheduled again. Now, the loop was already buggy, since we don't check if the NAND is ready after exiting the loop; we simply print out a timeout warning. Fix this by doing a final status check before printing a timeout message. This isn't actually a critical bug, since the only effect is a false warning print. But too many prints never hurt anyone, did they? :) Side note: perhaps I'm not smart enough, but I'm not sure what the best policy is for this kind of loop; do we busy loop (i.e., no cond_resched()) to keep the lowest I/O latency (it's not great if the resched is delaying Richard's system ~400ms)? Or do we allow rescheduling, to play nice with the rest of the system (since some operations can take quite a while)? Reported-by: NRichard Weinberger <richard@nod.at> Signed-off-by: NBrian Norris <computersforpeace@gmail.com> Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by: NRichard Weinberger <richard@nod.at> Reviewed-by: NHarvey Hunt <harvey.hunt@imgtec.com>
-
- 07 1月, 2016 2 次提交
-
-
由 Boris BREZILLON 提交于
The default NAND read functions are relying on the underlying controller driver to correct bitflips, but some of those controllers cannot properly fix bitflips in erased pages. Check for bitflips in erased pages in default core functions if the driver delegated the this check by setting the NAND_ECC_GENERIC_ERASED_CHECK flag. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Tested-by: NFranklin S Cooper Jr. <fcooper@ti.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
由 Brian Norris 提交于
Commits such as commit 853f1c58 ("mtd: nand: omap2: show parent device structure in sysfs") attempt to rely on the core MTD code to set the MTD name based on the parent device. However, nand_base tries to set a different default name according to the flash name (e.g., extracted from the ONFI parameter page), which means NAND drivers will never make use of the MTD defaults. This is not the intention of commit 853f1c58. This results in problems when trying to use the cmdline partition parser, since the MTD name is different than expected. Let's fix this by providing a default NAND name, where possible. Note that this is not really a great default name in the long run, since this means that if there are multiple MTDs attached to the same controller device, they will have the same name. But that is an existing issue and requires future work on a better controller vs. flash chip abstraction to fix properly. Fixes: 853f1c58 ("mtd: nand: omap2: show parent device structure in sysfs") Reported-by: NHeiko Schocher <hs@denx.de> Signed-off-by: NBrian Norris <computersforpeace@gmail.com> Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Tested-by: NHeiko Schocher <hs@denx.de> Cc: Heiko Schocher <hs@denx.de> Cc: Frans Klaver <fransklaver@gmail.com> Cc: <stable@vger.kernel.org>
-
- 19 12月, 2015 3 次提交
-
-
由 Helmut Schaa 提交于
nand_write_subpage_hwecc causes a crash if the driver did not register ecc->hwctl or ecc->calculate. Fix this by disabling subpage writes if ecc->hwctl or ecc->calculate is not provided by the driver. This behavior was introduced in commit 837a6ba4 "mtd: nand: subpage write support for hardware based ECC schemes". This fixes a crash with fsl_elbc_nand and maybe others: Unable to handle kernel paging request for instruction fetch Faulting instruction address: 0x00000000 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2 P1020 RDB Modules linked in: ath9k ath9k_common pppoe ppp_async option iptable_nat ath9k_hw ath usb_wwan pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv4 mac80211 ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_quota xt_policy xt_pkttype xt_owner xt_nat xt_multiport xt_mh CPU: 1 PID: 2161 Comm: ubiformat Not tainted 3.10.26 #6 task: efbc2700 ti: c7950000 task.ti: c7950000 NIP: 00000000 LR: c01a495c CTR: 00000000 REGS: c7951cb0 TRAP: 0400 Not tainted (3.10.26) MSR: 00029000 <CE,EE,ME> CR: 24002028 XER: 00000000 GPR00: c01a4b6c c7951d60 efbc2700 ef84b000 00000001 00000000 000001ff c7800500 GPR08: 00000000 00000000 efae5e40 c01a4ae4 24002022 10023418 c7951e5c c7800500 GPR16: c017b6a8 00000000 0000003f c053404c 00000000 00000004 00000000 00000003 GPR24: 00000010 00000200 ef84b000 c7800d00 c7800000 c7800500 ef84b1c8 00000000 NIP [00000000] (null) LR [c01a495c] nand_write_subpage_hwecc+0x74/0x174 Call Trace: [c7951d60] [c7951d64] 0xc7951d64 (unreliable) [c7951da0] [c01a4b6c] nand_write_page+0x88/0x198 [c7951dd0] [c01a5f7c] nand_do_write_ops+0x2f4/0x39c [c7951e40] [c01a61e0] nand_write+0x58/0x84 [c7951e80] [c019e29c] mtdchar_write+0x1dc/0x28c [c7951ef0] [c00aba84] vfs_write+0xcc/0x1ac [c7951f10] [c00ac04c] SyS_write+0x4c/0x90 [c7951f40] [c000cd84] ret_from_syscall+0x0/0x3c --- Exception: c01 at 0x48050ed8 LR = 0x100071b8 Instruction dump: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ---[ end trace 161d3c65a2a15cb8 ]--- Kernel panic - not syncing: Fatal exception [Brian: editorial note - we've applied a previous fix for the driver in question (fsl_elbc_nand) long ago: commit f034d87d ("mtd: eLBC NAND: fix subpage write support") but this still makes sense, and it could solve issues on some other unforseen driver.] Cc: Pekon Gupta <pekon.gupta@gmail.com> Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Cc: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
由 Boris BREZILLON 提交于
Now that the nand_chip struct directly embeds an mtd_info struct we can get rid of the ->flash_node field and forward set/get_flash_node requests to the MTD layer. As a side effect, we no longer need the mtd_set_of_node() call done in nand_dt_init(). Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
由 Boris BREZILLON 提交于
nand_dt_init() function requires 3 arguments where it actually needs one (dn and mtd can both be retrieved from chip). Drop these parameters. Testing for dn != NULL inside nand_dt_init() also helps simplifying the caller code. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
- 09 12月, 2015 1 次提交
-
-
由 Boris BREZILLON 提交于
mtd_to_nand() was recently introduced to avoid direct access to the mtd->priv field. Update core code to use mtd_to_nand(). Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
- 17 11月, 2015 1 次提交
-
-
由 Brian Norris 提交于
If multiple NAND chips are registered to the same controller, then when rebooting the system, the first one will grab the controller lock, while the second will wait forever for the first one to release it. i.e., a classic deadlock. This problem was solved for a similar case (suspend/resume) back in commit 6b0d9a84 ("mtd: nand: fix multi-chip suspend problem"), and the shutdown state really isn't much different for us, so rather than adding a new special case to nand_get_device(), we can just overload the FL_PM_SUSPENDED state. Now, multiple chips can "get" the same controller lock (preventing further I/O), while we still allow other chips to pass through nand_shutdown(). Original report: http://thread.gmane.org/gmane.linux.drivers.mtd/59726 http://lists.infradead.org/pipermail/linux-mtd/2015-July/059992.html Fixes: 72ea4036 ("mtd: nand: added nand_shutdown") Reported-by: NAndrew E. Mileski <andrewm@isoar.ca> Signed-off-by: NBrian Norris <computersforpeace@gmail.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: Andrew E. Mileski <andrewm@isoar.ca> Acked-by: NScott Branden <sbranden@broadcom.com> Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
- 12 11月, 2015 2 次提交
-
-
由 Boris BREZILLON 提交于
Used semantic patch with 'make coccicheck MODE=patch COCCI=script.cocci': ---8<---- virtual patch @@ struct nand_chip c; struct nand_chip *cp; @@ ( -(cp)->flash_node +nand_get_flash_node(cp) | -(c).flash_node +nand_get_flash_node(&c) ) ---8<---- Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
由 Brian Norris 提交于
We should pass along our flash DT node to the MTD layer, so it can set up ofpart for us. Signed-off-by: NBrian Norris <computersforpeace@gmail.com> Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
- 27 10月, 2015 1 次提交
-
-
由 Alex Smith 提交于
If nand_wait_ready() times out, this is silently ignored, and its caller will then proceed to read from/write to the chip before it is ready. This can potentially result in corruption with no indication as to why. While a 20ms timeout seems like it should be plenty enough, certain behaviour can cause it to timeout much earlier than expected. The situation which prompted this change was that CPU 0, which is responsible for updating jiffies, was holding interrupts disabled for a fairly long time while writing to the console during a printk, causing several jiffies updates to be delayed. If CPU 1 happens to enter the timeout loop in nand_wait_ready() just before CPU 0 re- enables interrupts and updates jiffies, CPU 1 will immediately time out when the delayed jiffies updates are made. The result of this is that nand_wait_ready() actually waits less time than the NAND chip would normally take to be ready, and then read_page() proceeds to read out bad data from the chip. The situation described above may seem unlikely, but in fact it can be reproduced almost every boot on the MIPS Creator Ci20. Therefore, this patch increases the timeout to 400ms. This should be enough to cover cases where jiffies updates get delayed. In nand_wait() the timeout was previously chosen based on whether erasing or programming. This is changed to be 400ms unconditionally as well to avoid similar problems there. nand_wait() is also slightly refactored to be consistent with nand_wait{,_status}_ready(). These changes should have no effect during normal operation. Debugging this was made more difficult by the misleading comment above nand_wait_ready() stating "The timeout is caught later" - no timeout was ever reported, leading me away from the real source of the problem. Therefore, a pr_warn() is added when a timeout does occur so that it is easier to pinpoint similar problems in future. Signed-off-by: NAlex Smith <alex.smith@imgtec.com> Signed-off-by: NHarvey Hunt <harvey.hunt@imgtec.com> Reviewed-by: NNiklas Cassel <niklas.cassel@axis.com> Cc: Alex Smith <alex@alex-smith.me.uk> Cc: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Niklas Cassel <niklas.cassel@axis.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
- 14 10月, 2015 1 次提交
-
-
由 Boris BREZILLON 提交于
The ->read_xxx() methods are all passed the page number the NAND controller is supposed to read, but ->write_xxx() do not have such a parameter. This is a problem if we want to properly implement data scrambling/randomization in order to mitigate MLC sensibility to repeated pattern: to prevent bitflips in adjacent pages in the same block we need to avoid repeating the same pattern at the same offset in those pages, hence the randomizer/scrambler engine need to be passed the page value in order to adapt its seed accordingly. Moreover, adding the page parameter to the ->write_xxx() methods add some consistency to the current API. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> CC: Josh Wu <josh.wu@atmel.com> CC: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> CC: Maxime Ripard <maxime.ripard@free-electrons.com> CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org> CC: Huang Shijie <shijie.huang@arm.com> CC: Stefan Agner <stefan@agner.ch> CC: devel@driverdev.osuosl.org CC: linux-arm-kernel@lists.infradead.org CC: linux-kernel@vger.kernel.org Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-
- 02 10月, 2015 1 次提交
-
-
由 Boris BREZILLON 提交于
The ->init_size() hook was introduced to let NAND controller drivers support NAND devices that could not be described in the nand_ids table. Since then, the core has added support for extended-id parsing and full-id description, thus allowing to describe pretty much all existing NANDs. Moreover, this hook is not used by any mainline driver, and should not be used by new drivers, because detecting the NAND chip is not something controller specific. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
-