[U-Boot] [PATCH 1/2] OMAP3: Remove unused board-types

[Dirk Behme]

Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 23:01 Fri 24 Apr     , Wolfgang Denk wrote:
>> Dear Jean-Christophe PLAGNIOL-VILLARD,
>>
>> In message <20090424200323.GD2953 at game.jcrosoft.org> you wrote:
>>>> What exactly do you mean by "move the STD API"? 
>>>>
>>>> In which way should the "STD API" be moved, and what exactly is the
>>>> "STD API" you are referring to?
>>> extract of arm init function
>>>
>>> #if defined(CONFIG_DISPLAY_CPUINFO)
>>> 	print_cpuinfo,		/* display cpu info (and speed) */
>>> #endif
>>> #if defined(CONFIG_DISPLAY_BOARDINFO)
>>> 	checkboard,		/* display board info */
>>> #endif
>>>
>>> I want we use the current API and not re-invent a new API for an arch only
>> Well, if you conside rthis the "standard API", this should (1) be
>> documented somewhere, and (2) it must be fixed - at the moment, the
>> code reads:
>>
>> 	lib_arm/board.c:int print_cpuinfo (void); /* test-only */
>>
>> I would not dare to use such a function in my code given the
>> "test-only" comment.
> sorry I've no time to clean every part of the arm as noone else are
> interrested in old code
> 
> so yes it will be cleanup but later asI work on other part of the arm actually
> which I will finish first

Uups :( And this is what I really have a problem with.

We sent a patch which removes only dead code, i.e. which consist only 
of '-' lines (well, except for the removal of a parameter passed by a 
function ;) ).

http://lists.denx.de/pipermail/u-boot/2009-April/051338.html

Then we are asked to change other stuff which is touched by this 
removal, too, to get the patch applied (One could argue that a better 
way to deal with this would be to apply the code removal patch and ask 
for sending an *additional* patch to clean up API usage. And not make 
it dependent. But that's an other topic...)

Then we find that the changes we are asked to do rely on code that is 
marked with 'test only' and needs documentation.

And the request for this documentation (would it take more than 0.5h?) 
get the answer above.

And now? What are we supposed to do?

Change our patch based on 'test only' undocumented code?

Or will a trivial 'remove dead code only' patch delayed until e.g. the 
Kconfig framework or e.g. the new clock framework or e.g. <add what 
you want> will be ready? And when will this be?

A confused

Dirk