[U-Boot] [PATCH 2/2 v3] arm: suen3, suen3_v1, mgcoge2_arm_p1a support

[Scott Wood]

Heiko Schocher wrote:
> Scott Wood wrote:
>> That's not how nand_init() is meant to be used.  It is meant to be called
>> once on system init.  There is probably at least a memory leak here, e.g.
>> chip->buffers.
> 
> Oh, Ok. How could/should this then be solved?

Well, for a hackish solution that avoids the leak on chip->buffers, see 
omap_nand_switch_ecc().

> (Some weak function, maybe: int nand_available(void)?, that board specific
>  code can overwrite, and this function is checked before a nand command
>  is executed?)

I'd rather make the callback specific to the driver -- you're not 
disabling any possible NAND controller that might be attached through 
whatever odd means, you're disabling the kirkwood NAND controller.

> In the First step, I don;t call nand_init() again, there is also a
>  warning message, that NAND is disabled, so the user should know, that
>  he don;t have longer access to it, is this Okay for you?
> 
>> Even as a hack, it looks like these boards use the kirkwood nand controller,
>> and its board_nand_init() will unconditionally return 0, telling
> 
> Yep, but ...
> 
>> nand_init_chip that it does indeed have NAND available.  Or is there a patch
>> somewhere changing that?
> 
> ... nand_get_flash_type() returns -ENODEV, if no manufacturer or/and
> id could be read from nand (And if using this u-boot command, the nand
> is not longer visible, because the nand is disabled, and the pins are
> used to access a SPI Flash) -> nand_scan_ident returns this error, and
> so nand_scan ...

Will the attempt to do a read ID command cause bad things to go on the 
SPI pins when configured as SPI?  Or will the NAND controller hardware 
know that it doesn't have access to the pins and just return dummy values?

-Scott