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

[Prafulla Wadaskar]

> -----Original Message-----
> From: Holger Brunck [mailto:holger.brunck at keymile.com]
> Sent: 05 July 2012 19:14
> To: Prafulla Wadaskar
> Cc: Wolfgang Denk; u-boot at lists.denx.de; Valentin Longchamp
> Subject: Re: [U-Boot] [PATCH v2 03/14] arm/km: convert mgcoge3un
> target to km_kirkwood
> 
> 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?

YES.

> 
> 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.

I don't have any further inputs.

Regards..
Prafulla . . .