- 07 Jan, 2014 17 commits
-
-
Brian Norris authored
Fixes this sparse warning: CHECK drivers/mtd/onenand/generic.c drivers/mtd/onenand/generic.c:61:62: warning: Using plain integer as NULL pointer Signed-off-by:Brian Norris <computersforpeace@gmail.com>
-
Brian Norris authored
The omap_{read,write}_buf{8,16}() functions are identical to the default nand_base versions. Just let nand_base assign them in the NAND_OMAP_POLLED case. Signed-off-by:Pekon Gupta <pekon@ti.com>
-
Brian Norris authored
We shouldn't try to allocate a resource until we're sure the of_property_read_u64() call didn't fail. This is especially important if we use this code for both CONFIG_OF and !CONFIG_OF builds, since of_property_read_u64() will always return -ENOSYS for !CONFIG_OF. Signed-off-by: -
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
Jingoo Han authored
Use devm_*() functions to make cleanup paths simpler. Signed-off-by:
-
Jingoo Han authored
Use devm_*() functions to make cleanup paths simpler. Signed-off-by:
-
Jingoo Han authored
Use dev_err() instead of printk() to provide a better message to userspace. Signed-off-by:
-
Jingoo Han authored
Use dev_err() instead of printk() to provide a better message to userspace. Signed-off-by:
-
Jingoo Han authored
Use dev_warn() instead of printk() to provide a better message to userspace. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Jingoo Han authored
Use dev_err() instead of printk() to provide a better message to userspace. Signed-off-by:
Josh Wu <josh.wu@atmel.com> Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
Roland Stigge <stigge@antcom.de> Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
- 03 Jan, 2014 23 commits
-
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
Use devm_*() functions to make cleanup paths simpler. Signed-off-by:
-
Jingoo Han authored
Use devm_*() functions to make cleanup paths simpler. Signed-off-by:
-
Jingoo Han authored
Use devm_*() functions to make cleanup paths simpler. Signed-off-by:
-
Jingoo Han authored
Use devm_clk_get() to make cleanup paths simpler. Signed-off-by:
-
Jingoo Han authored
Use devm_kzalloc() to make cleanup paths simpler. Also, checking return value of devm_kzalloc() is added in order to check if the allocation succeded. Signed-off-by:
John Crispin <blogic@openwrt.org> Signed-off-by:
-
Jingoo Han authored
Use devm_*() functions to make cleanup paths simpler. Signed-off-by:
-
Ezequiel Garcia authored
In order to avoid code duplication, let's consolidate the ECC setting for all SoC variants. Such decision is based on page size and ECC strength requirements. Also, provide a default value for the case where such ECC information is not provided (non-ONFI devices). Tested-by:
Arnaud Ebalard <arno@natisbad.org> Signed-off-by:
Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by:
-
Ezequiel Garcia authored
Currently, we have two different cmdfunc's implementations: one for PXA3xx SoC variant and one for Armada 370/XP SoC variant. The former is the legacy one, typically constrained to devices with page sizes smaller or equal to the controller's FIFO buffer. On the other side, the latter _only_ supports the so-called extended command semantics, which allow to handle devices with larger page sizes (4 KiB, 8 KiB, ...). This means we currently don't support devices with smaller pages on the A370/XP SoC. Fix it by first renaming the cmdfuncs variants, and then make the choice based on device page size (and SoC variant), rather than SoC variant alone. While at it, add a check for page size, to make sure we don't allow larger pages sizes on the PXA3xx variant. Tested-by:
-
Ezequiel Garcia authored
Currently the driver assumes all commands will eventually trigger a RnB transition, and thus a "device is ready" IRQ. This assumption means that on every issued command, the dev_ready completion handler is init'ed and the need_wait flag is set. However this is incorrect: some commands (such as NAND_CMD_STATUS) don't make the device 'busy' and thus a RnB transition never occurs. Given, the NAND core never calls waitfunc() after such commands, this is not a problem. Therefore, it's possible to only clear the need_wait flag on every command that is started. This fixes a current bug that can be reproduced on PXA boards by writing blank (all 0xff'ed) to a page: 1. The kernel issues NAND_CMD_STATUS and sets need_wait=1. The flag won't be cleared for this command since no RnB transition is involved. 2. NAND_CMD_PAGEPROG is issued but since the data is blank, the driver decides not to execute the command (and no IRQ activity is involved). 3. The NAND core calls waitfunc() and waits for the dev_ready completion, which will never end since the device _is_ already ready. Tested-by:
-
