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

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

On 07/05/2012 02:09 PM, Prafulla Wadaskar wrote:
>>>
>>> To avoid any further confusion let's keep aside all the past.
>>> 1. Pls post the new patch series that is just targeted for bugfixes
>> and updates (no addition of new boards or drivers)
>>
>> Ok so there are again no inputs to specific patches and no change
>> request for a
>> specific patch (beside the input to the managed switch). What you do
>> is to
>> rephrase a requirement for patch series in general. So there seems to
>> be a rule
>> that if you a) add new boards and b) cleanup and maintain existing
>> boards in the
>> same patch serie the patches needs to be in a special order. Please
>> show me the
>> pointer in u-boot guidlines to this if there is one. I know that such
>> tasks
>> should be seperated  into different patches what this serie defenitely
>> does. If
>> not please discuss this as a new requirement with other custodians as
>> Wolfgang
>> suggested in the same thread. I don't think that such a requirement
>> would be a
>> benefit for board maintainers and custodians, because code maintaining
>> and
>> improvement is always a good thing. Your requirement in practice would
>> mean,
>> stop code maintaining for board series during the time you need to add
>> new boards.
> 
> Dear Holger,
> 
> I think custodian should pull entire patch series if all the patches in the series are ACKED.
> If any patch within patch series is NACKED, the patch series does not stand valid to pull.
> Someone may correct me if I am wrong.
> 

yes of course this is a common rule. But what has this to do with my question above?

>>
>>> 2. You may post anther patch series for addition of new boards which
>> does not have any dependencies (if you have such)
>>> 3. You may post a standalone patch for a switch driver, needed ack
>> from Joe, that might go to u-boot-net.git
>>
>> Ok we can remove this very limited driver from the patch serie.
>>
>> So what we can do is providing a patch serie where the driver for this
>> managed
>> switch is not in. But as far as I understood this does not be in
>> accordance what
>> you requested?
> 
> Ideally, the answer is same as above. There will be no issues if all patches in the patch series are ACKED.
> 

and whats the answer here on my question?

Again. You NAK the simple driver in our own board code. Ok. So the question here
is if I remove the three patches which are concerning this driver. This are:
[U-Boot,v2,05/14] arm/km: correct init of 88e6352 switch in the reset_phy function
[U-Boot,v2,09/14] arm/km: add support for external switch configuration
[U-Boot,v2,10/14] arm/km: enable external switch configuration for kmnusa

And if I resend the remaining eleven patches in the same order as beneath
these are:
[U-Boot,v2,01/14] arm/km: add kmnusa board support
[U-Boot,v2,02/14] arm/km: add kmcoge5un board support
[U-Boot,v2,03/14] arm/km: convert mgcoge3un target to km_kirkwood
[U-Boot,v2,04/14] arm/km: remove portl2.h and use km_kirkwood instead
[U-Boot,v2,06/14] arm/km: enable BOCO2 FPGA download support
[U-Boot,v2,07/14] arm/km: cleanup km_kirkwood boards
[U-Boot,v2,08/14] arm/km: redefine piggy 4 reg names to avoid conflicts
[U-Boot,v2,11/14] arm/km: skip FPGA config when already configured
[U-Boot,v2,12/14] arm/km: support the 2 PCIe fpga resets
[U-Boot,v2,13/14] arm/km: add implementation for read_dip_switch
[U-Boot,v2,14/14] arm/km: remove calls to kw_gpio_* in board_early_init_f

as another patch serie do you accept this?

We already have so many different patch series for this serie on patchwork that
I want to be sure that I don't generate another one which will also be
unacceptable. I think this is already reviewed. But if you have still other
inputs then let me know and refer to the specific patch. Thanks.

Regards
Holger