[U-Boot] [PATCH v2 0/9] Added support for SPEAr SoCs

[Peter Tyser <ptyser@xes-inc.com>]

On Fri, 2010-01-08 at 10:05 +0530, Vipin KUMAR wrote:
> Hello Peter,
> 
> > > This patch set is a reworked patch which incorporates all review
> > feedbacks from
> > > earlier earlier mails
> > >
> > > This patch set contains the support for 4 SoCs
> > > SPEAr600
> > > SPEAr300
> > > SPEAr310
> > > SPEAr320
> > >
> > > SPEAr is an ARM based SoC which supports rich set of peripherals like
> > Ethernet,
> > >       USB Host, USB Device etc to support various general
> > applications
> > >
> > > For further info on SPEAr SoC, please see README.spear also contained
> > in the
> > > patch set.
> > >
> > > Vipin (9):
> > >   Added README.spear
> > >   SPEAr600 SoC support added
> > >   SPEAr300 SoC support added
> > >   SPEAr310 SoC support added
> > >   SPEAr320 SoC support added
> > >   i2c driver support for SPEAr SoCs
> > >   smi driver support for SPEAr SoCs
> > >   nand(fsmc) driver support for SPEAr SoCs
> > >   usbd driver support for SPEAr SoCs
> > 
> > It would be nice if you reordered the patches.  At a glance, some of
> > the
> > boards added first rely on drivers added later.  Eg patch 1 uses the
> > I2C
> > driver in patch 6.  This will cause 'git bisects' to break.  To prevent
> > this you should add SOC + driver code first, then boards last.
> > Something like:
> > 
> > 1. Initial SPEAr SOC support
> > 2. SPEAr: Add I2C support
> > 3. SPEAr: Add SMI support
> > ....
> > 6. Add SPEAr 600 board support
> > 7. Add SPEAr 300 board support
> > 8. Add SPEAr 310 board support
> > 9. Add SPEAr 320 board support
> > 
> 
> I am planning to keep the patch order as it is but I would remove 
> dependencies eg. SPEAr600 would not contain code that depends on
> a driver added later and so on.
> 
> This should also be OK. Right?

It should remove the 'git bisect' issue, which is the important thing to
me.  The way you did it in v3 should work, its just a bit uglier than
doing it the "right" way that I outlined above.  Eg you modify spear.h
and config.mk each time you add a new driver, basically tweaking the
board support as the patch sequence progresses instead of just adding
proper board support in 1 patch at the end.

Also, its a bit ugly to add both spear arch support as well as board
support in patch 2/11.  Ideally you'd have 1 patch adding spear
architectural support, then additional patches for drivers, then patches
for boards.

In any case, my comments are mostly aesthetic and I don't really care
how you split up the patches as long as you don't break bisection:)
Wolfgang or Tom can force you to reorganize the patches if they care
about it enough.

Best,
Peter