[PATCH] Bug fix in kernel nand driver code for ONFI flash with unconfigured buswidth

pekon pekon at pek-sem.com
Tue Jun 30 12:10:51 PDT 2015


On Tuesday 30 June 2015 12:26 AM, Willem Atsma wrote:
> Thank you for reviewing my patch and the feedback. I understand I am
> creating a "false pass" and that the check is in fact needed to ensure
> the initial setup was correct.  My patch incorrectly fixes this bug as
> configuration fails without a fix.
>
> With the nand I have the configuration will succeed under the following
> conditions:
>
>   - I force ONFI to fail (i.e. make nand_flash_detect_onfi() return 0)
>   - Set the options structure as indicated (and create the false pass).
>
> In nand_get_flash_type() a successful call to nand_flash_detect_onfi()
> results in a jump to ident_done, skipping code that would otherwise
> correctly initialize the chip, including buswidth. This suggested to me
> that:
>
>   - the driver configuration is correctly configured;
>   - failure results from (in this instance) inappropriate comparison
> between ONFI setting and buswidth setting done up to this point.
>
>  From this I understand that the driver setting should have been set to
> NAND_BUSWIDTH_AUTO. The chip can in fact handle either 8 or 16 and is
> connected with 16.
>
Yes, that is correct ..
By default if the NAND_BUSWIDTH_AUTO is set, then driver should start 
the probe in x8 mode, and then switch based on device's bus-width which 
is detected from
- ONFI parameter page, or
- NAND_ID bytes

> Where do I correct/find DT and/or platform-data?
>
It will be in arch specific folder, like for OMAP devices ..
- arch/arm/mach-omap2/board-flash.c
- arch/arm/boot/dts/...


with regards, pekon




More information about the linux-mtd mailing list