[U-Boot] [PATCH] nand: lpc32xx: add SLC NAND controller support

[Albert ARIBAUD]

Hello Vladimir,

On Wed, 15 Jul 2015 11:49:01 +0300, Vladimir Zapolskiy <vz at mleia.com>
wrote:
> Hello Albert,
> 
> On 15.07.2015 10:05, Albert ARIBAUD wrote:
> > Hello Vladimir,
> > 
> > On Tue, 14 Jul 2015 23:23:57 +0300, Vladimir Zapolskiy <vz at mleia.com>
> > wrote:
> >> The change adds support of LPC32xx SLC NAND controller.
> >> 
> >> LPC32xx SoC has two different mutually exclusive NAND controllers 
> >> to communicate with single and multiple layer chips.
> >> 
> >> This simple driver allows to specify NAND chip timings and defines
> >>  custom read_buf()/write_buf() operations, because access to 8-bit 
> >> data register must be 32-bit aligned.
> >> 
> >> Support of hardware ECC calculation is not implemented (data 
> >> correction is always done by software), since it requires a working
> >> DMA engine.
> >> 
> >> The driver can be included to an SPL image.
> > 
> > This is needed for an upcoming new board support patch, right?
> 
> you are correct, I plan to extend current support of devkit3250 board.
> 
> > If so, then I suggest you put together all patches for this new
> > board in a single series. This will make it clear(er) you're not
> > adding dead code here.
> > 
> 
> I got the point, I will be able to complete board specific changes today
> tonight and send them for review.

Thanks.

> Please let me ask you for one more advice, if I want to add peripherals
> support on the board (by the way thank you for your drivers) and SPL
> image building support, both changes touch defconfig and board config
> header files. Should I split these changes into separate ones or is one
> "board support extension" patch preferred?

A commit should ideally be a single, self-contained, logical change.

So I would say each driver addition should be one commit, and the SPL
support addition should be its own commit, even though each of these
commits touches the defconfig and header config files.

This has at least two benefits:

- each commit is simpler to review (and to design and test, too). If a
  commit contains several logical changes, it is harder to sort out
  which change(s) a given patch chunk is about.

- in case a change was applied to U-Boot and later proves to cause
  an issue, then we can easily revert this change, and only
  this change, by reverting its commit. If the commit contains
  several change, then we cannot simply revert the commit, we need to
  manually "patch out" the problematic change while keeping the others.

> --
> With best wishes,
> Vladimir

Amicalement,
-- 
Albert.