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

Holger Brunck holger.brunck at keymile.com
Thu Jul 5 09:15:32 CEST 2012


On 07/05/2012 08:04 AM, Prafulla Wadaskar wrote:
> 
> 
>> -----Original Message-----
>> From: Holger Brunck [mailto:holger.brunck at keymile.com]
>> Sent: 05 July 2012 11:24
>> 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/04/2012 11:21 AM, Prafulla Wadaskar wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Wolfgang Denk [mailto:wd at denx.de]
>>>> Sent: 03 July 2012 23:31
>>>> To: Prafulla Wadaskar
>>>> Cc: Holger Brunck; u-boot at lists.denx.de; Valentin Longchamp
>>>> Subject: Re: [U-Boot] [PATCH v2 03/14] arm/km: convert mgcoge3un
>>>> target to km_kirkwood
>>>>
>>>> Dear Prafulla,
>>>>
>>>> In message <F766E4F80769BD478052FB6533FA745D1A2FE3028D at SC-
>>>> VEXCH4.marvell.com> you wrote:
>>>>>
>>>>> Do you think I should pull this patch series, I hope it applies
>>>> cleanly on the recent master branch.
>>>>> Please confirm.
>>>>
>>>> I have to admit that I neither reviewed the patches in question,
>> nor
>>>> did I follow the whole thread of communication in this patch
>> series.
>>>> But the general rule is that if there are no strong argumentents
>>>> against a patch (like a clear NAK or a specific request for
>> changes)
>>>> we will apply it.
>>>
>>> Hi Wolfgang,
>>> This patch series was too old, I was trying to save my effors ;-D
>>> Finally I pulled these patches and tried to apply, but as I doubted
>> it failed :-(
>>>
>>> Hi Hogler
>>>
>>> I could not apply the said patch series to the latest u-boot-
>> marvell.git master branch
>>>
>>> Pls re-submit it.
>>>
>>> git-am U-Boot-1-9-arm-km-add-board-type-to-boards.cfg.patch
>>>
>>> Applying arm/km: add board type to boards.cfg
>>>
>>> error: patch failed: boards.cfg:138
>>> error: boards.cfg: patch does not apply
>>> error: patch failed: include/configs/km_kirkwood.h:42
>>> error: include/configs/km_kirkwood.h: patch does not apply
>>> Patch failed at 0001.
>>> When you have resolved this problem run "git-am --resolved".
>>> If you would prefer to skip this patch, instead run "git-am --skip"
>>>
>>
>> sorry but now I am completely confused. Here you say you want to apply
>> 01-09
>> which includes
>> [PATCH v2 05/14] arm/km: correct init of 88e6352 switch in the
>> reset_phy function
>> and
>> [PATCH v2 09/14] arm/km: add support for external switch configuration
>>
>> this includes basic infrastructure for the managed switch.
>>
>> In another thread you NAK the whole driver:
>> http://lists.denx.de/pipermail/u-boot/2012-July/127529.html
>>
>> In a further different thread where I asked if I should provide
>> updates which
>> apply cleanly you say no there are general updates needed:
>> http://lists.denx.de/pipermail/u-boot/2012-July/127531.html
>>
>> For me these statements are conflicting.
>>
>> So can you please state clearly which updates you request from myside
>> for which
>> patch and which are from your point of view not acceptable and why?
>> Thanks
> 
> Dear Holger
> 
> 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.

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

Regards
Holger




More information about the U-Boot mailing list