[U-Boot] [PATCH v4] powerpc: Restore core of mpc8xx

[Tom Rini]

On Fri, Jun 23, 2017 at 08:39:15PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20170623140934.GD27196 at bill-the-cat> you wrote:
> > 
> > Since he addressed a number of the comments from the previous
> > discussions, it would be helpful to point out the things that were
> > overlooked, thanks!
> 
> I thought this should be clear from the previous discussion.  The
> major concern is that this patch brings back a large amount of ccode
> that will obviously remain unfixed, untested and unmaintained.  Just
> to list a few examples:
> 
> arch/powerpc/cpu/mpc8xx/bedbug_860.c
> arch/powerpc/cpu/mpc8xx/kgdb.S
> arch/powerpc/cpu/mpc8xx/video.c
> drivers/block/sil680.c
> drivers/pcmcia/mpc8xx_pcmcia.c
> drivers/usb/gadget/mpc8xx_udc.c
> examples/standalone/test_burst.*
> examples/standalone/timer.c
> post/cpu/mpc8xx/usb.c (probably even post/cpu/mpc8xx/*)

OK, cool.  Now we have concrete reminders and we also have some
platforms coming in that will be making use of mpc8xx.

> Also, directory hierarchy should be fixed for a number of drivers.
> 
> It is IMO wrong to plan for a remove - revert - remove sequence.
> 
> This may be the way how Christophe actually starts developing his
> patches.  As he mentioned, it might be useful for history reasons.
> But as I also explained before, going this route is a guarantee to
> keep a ton of unused, untested and unmaintained code which will not
> be removed as Christophe does not understand what it might be needed
> for.  Please don't misunderstand me: I don't mean to suggest that I
> doubt on Christophe's qualification for this job - I mean nobody
> would be able to do this without being able to test the code on all
> the plethora of different boards that once needed such quirks.
> 
> Starting with all the old code and trying to remove unused stuff is
> _guaranteed_ to fail.  We have to go the other way: start with
> minimal code and add only what is really needed - especially as this
> is a dead, obsolete processor architecture, and chances that any new
> boards be added is epsilon.
> 
> It is in Christophe's own interest to restrict the code to those
> parts that his boards really need.  I admit that I am responsible
> for large parts of that code, and I well remeber the #ifdef mess
> that was added way back thento deal with all the subtleties of the
> many boards we had to support.  Trust me, I know what I'm speaking
> about.
> 
> To make this clear: I am in no way against continuing to support
> mpc8xx.  But we should not let him run into an unmaintainable mess
> of code.

So, Christophe, please iterate on the mpc8xx patches so that you're
bringing back just the parts of the code that you need.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170623/0efa93b3/attachment.sig>