> -----Original Message----- > From: Holger Brunck [mailto:holger.bru...@keymile.com] > Sent: 05 July 2012 19:14 > To: Prafulla Wadaskar > Cc: Wolfgang Denk; u-boot@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 . . . _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
