[GIT PULL] mvl-dove branch sync'ed to Marvell Dove LSP 5.3.2

Tim Gardner tim.gardner at canonical.com
Mon Aug 2 17:15:40 UTC 2010


On 08/02/2010 11:01 AM, Stefan Bader wrote:
> On 08/02/2010 05:50 PM, Eric Miao wrote:
>> On Mon, Aug 2, 2010 at 11:36 PM, Tim Gardner<tim.gardner at canonical.com>  wrote:
>>> On 08/02/2010 09:05 AM, Eric Miao wrote:
>>>>
>>>> git://kernel.ubuntu.com/ycmiao/ubuntu-lucid.git mvl-dove
>>>
>>
>> The original LSP 5.3.2 branch for reference is at:
>>
>> http://kernel.ubuntu.com/git?p=leali/ubuntu-lucid.git;a=summary
>>
>>> Did anyone notice that the patch 'Make some BT modules and ACL support for
>>> File System as defautl in dove_defconfig' doesn't actually do anything?
>>>
>>
>> Grrr... the original change modified only dove_defconfig, and the change
>> was actually merged in a previous commit syncing the dove_defconfig,
>> leaving an almost empty commit after rebasing. We can safely remove
>> this.
>>
>>> Nor does 'dove: fix SPI flash model and size found on db board'
>>>
>>
>> The original patch also does nothing except for changing the comment.
>> Not really sure for its specific purpose, but simply merged here so to
>> avoid possible merge conflict in the future.
>>
>>> So, what exactly are we supposed to do with this enormous pile of patches?
>>> They certainly don't pass SRU qualifications.
>>>
>>
>> Hrm.... then I guess we need to figure out those we do need or
>> are simply fixing patches, and leave out those irrelevant. Yet I'm
>> afraid we'll be more and more difficult to merge further LSP syncs
>> from Marvell?
>>
>
> Would this mean I should hold back with pulling anything?
>

Not necessarily. I just wanted to confirm that we don't consider 
mvl-dove to be subject to SRU policies. As far as I know there has not 
been stable working HW, so I guess it makes sense that there would be 
some BSP updates. As soon as mvl-dove is used for a real project, then 
we'll have to change our opinion wrt SRU.

rtg
-- 
Tim Gardner tim.gardner at canonical.com




More information about the kernel-team mailing list