[PATCH v3 0/7] Marvell NAND controller rework with ->exec_op()

[Robert Jarzmik]

Boris Brezillon <boris.brezillon at free-electrons.com> writes:

> On Fri, 12 Jan 2018 17:43:52 +0100
> Robert Jarzmik <robert.jarzmik at free.fr> wrote:
>
>> Boris Brezillon <boris.brezillon at free-electrons.com> writes:
>> 
>> > I think I'm still missing something. If I look at the branch you just
>> > pushed, I see that ->flash_bbt was not set to 1 before this commit [1],
>> > which means the pxa3xx driver was no setting the NAND_BBT_USE_FLASH
>> > flag, which in turn means you were not using the on-flash-bbt.
>> > When you test the old (pxa3xx) driver, are you sure you're testing
>> > things with a mainline kernel? If you have extra commits on top of
>> > mainline, can you push them somewhere?  
>> 
>> Here is the branch I'm using with my pxa3xx driver :
>> git fetch https://github.com/rjarzmik/linux pxa3xx-test
>
> May I ask why this is not in mainline?
Sure.

The pxa3xx comes into 3 flavors of SoCs :
 - pxa300
 - pxa310
 - pxa320

In these 3, only pxa310 has an internal PoP NAND, and requires the keep_config =
1 setting (where timings are set by the internal ROM code).

Yet zylonite_init_nand() is shared across all 3 platforms. In order to not break
other existing pxa3xx devices, I don't want to change this setting. Instead, my
plan is slowly convert pxaXXX to devicetree, and have this parameter set in
devicetree in a per board basis.

As to the .flash_bbt = 1 parameter, it's even worse. That's the decision made in
the initial flash formatting that counts. With the zylonite310 I have, the BBT
is at the end of the NAND. There might be other parts where it's only in the OOB
area. So it's difficult to change it without taking a risk of breaking others.

Cheers.

-- 
Robert