On Mon, 2014-11-03 at 15:40 -0600, Scott Wood wrote:
On Thu, 2014-10-23 at 21:25 +0900, Masahiro Yamada wrote:
Since commit ff94bc40af34 (mtd, ubi, ubifs: resync with Linux-3.14), chip->scan_bbt() is called at the end of nand_scan_tail(). It means the first read access happens immediately after the generic NAND initialization process.
It causes a problem to some SoCs of UniPhier platform because some of their register values need to be fixed up after the general initialization procedure has been finished. Otherwise, read asccess fails. Such a fix-up is SoC-specific enough to be written in a board file rather than in driver code.
One of possible and clean enough ways to work around this issue is postpone the BBT scanning until necessary fix-up is done in board_late_init() or somewhere else.
CONFIG_MTD_NAND_SKIP_BBTSCAN, if enabled, allows to skip the BBT scanning at the end of nand_scan_tail().
Signed-off-by: Masahiro Yamada yamada.m@jp.panasonic.com Cc: Scott Wood scottwood@freescale.com
Rotislav Lisovy already posted a patch to fix the regression, but I don't think you should be relying on this for your problem. Why don't you want to put SoC-specific knowledge in the driver? At least make it a callback from the driver to an SoC file, rather than hoping the NAND won't be touched for a certain amount of time after the driver has told the subsystem "I'm here and ready to be used".
Also, if you did have a valid reason to set NAND_SKIP_BBTSCAN, why would you want to set it from nand.c rather than from your driver's init function?
-Scott