[U-Boot] [PATCH v2 03/14] arm/km: convert mgcoge3un target to km_kirkwood

[Holger Brunck <holger.brunck@keymile.com>]

Hi Prafulla,

On 07/03/2012 04:39 PM, Prafulla Wadaskar wrote:
>> On 07/03/2012 03:07 PM, Prafulla Wadaskar wrote:
>>>>>
>>>>
>>>> But 01-08 are not only bugfixes there are also two new boards in
>> these
>>>> patches.
>>>> So will you pull these eight patches in if I post them again
>> without
>>>> 09-14?
>>>
>>> Pls post bug fixes and improvement patches first those will be
>> pulled faster.
>>>
>> This was already done from my side:
>> http://lists.denx.de/pipermail/u-boot/2012-May/125219.html
>>
>> Sorry Prafulla but I have admit that this whole discussion costs a lot
>> of time
>> which I do not have. We are moving in circles your last comment was
>> already
>> discussed several times e.g.:
>> http://lists.denx.de/pipermail/u-boot/2012-June/126081.html
> 
> 
> Do you think I should pull this patch series, I hope it applies cleanly on the recent master branch.
> Please confirm.
> 

at time of submission it applied cleanly, now I see some merge conlicts due to
some underlying changes in boards.cfg in your current master. But if you are now
fine with the patch serie I can provide an update which applies cleanly again.

>>
>> So again you have no specific inputs of improvements for 01-08 right?
>> All you
>> rephrase are some general comments which are not very helpfull to
>> improve our
>> situation and to get our own board code into mainline.
> 
> Well.. we can keep discussing patches here until all the patches in the patch series gets acked.
> This adds time/cost to the developer and reviewer too.
> My old experience tells me that shorter is simpler and easier to accept.
> 

yes I agree but if you add new boards and new features there is sometimes no
chance to make everything small and simple.

> I personally don't wish to hold any thing that sounds good to me.
> The idea is how the development can be shared across the community.
> 
> So I had certain questions in my mind about your development for which I don't want any answers. You can treat them as feedback for your future development.
> 
> 1. Why do you modify the board parameters so frequently? I see several patches for these, cant you freeze all this well before posting board support patch?
> 2. Why do you use your own keymile-common.h, can't you migrate to use mv_common.h which mainly created for the same purpose?

The mentioned keymile-common.h has a completely different intention then
mv-common.h. Our header is mainly to collect all features for our boards which
are common for our ppc and arm based boards (environment variables, cmd features
etc.). And including mv-common.h into our environment for our arm based boards
was investigated. But many many features which are used in this header is not
valid for our boards, so it would end up in a big set of #ifdefs.

> 3. When you support any generic peripheral can't you think of generic use case?
> 
>>
>> We try to stick to every rule which is valid for u-boot development.
>> But we
>> can't stick to rules which are not clearly stated.
> 
> You better can have your own world, and maintain the code the way you want, not necessarily you need u-boot for this.
> 
> We both have different thinking hats :-D
> In your view, your code is important to get mainlined, may be you don't care other things.
> In my view, how any support can be added in simpler, shorter, reusable, cleaner way in-sync with development strategy. I am just trying to follow this.
> I might have done mistakes, I express grand SORRY for that :-(
> 
> I am always there to help everybody with my limited resources and time.
> 

yes and I don't want to offend anybody here. At the end we should benefit from
each other. Our side that we have our boards in mainline and you and others in
the community which take advantage from the bugfixes and bug reports we provide
for common code, as already done at several places.

Regards
Holger