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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
