[GIT PULL] at91: soc updates for 3.11 #1

[nicolas.ferre@atmel.com (Nicolas Ferre)]

On 17/06/2013 18:59, Olof Johansson :
> On Mon, Jun 17, 2013 at 2:20 AM, Ferre, Nicolas <Nicolas.FERRE@atmel.com> wrote:
>> From: Olof Johansson [olof at lixom.net]
>>> Hi,
>>>
>>> On Fri, Jun 14, 2013 at 11:42:18PM +0200, Nicolas Ferre wrote:
>>>> Arnd, Olof,
>>>>
>>>> A little AT91 pull-request for patches that are more targeted to SoC/boards
>>>> modifications. It is prepared on top of the arm-soc/at91/cleanup branch.
>>>>
>>>> Thanks, best regards,
>>>>
>>>> The following changes since commit b3f442b0eedbc20b5ce3f4a96530588d14901199:
>>>>
>>>>    ARM: at91: udpate defconfigs (2013-05-17 15:05:08 +0200)
>>>>
>>>> are available in the git repository at:
>>>>
>>>>    git://github.com/at91linux/linux-at91.git tags/at91-soc
>>>>
>>>> for you to fetch changes up to 7e75545ea7fb972c3da759f92c3d0be84d1cee72:
>>>>
>>>>    ARM: at91: drop rm9200dk board support (2013-06-14 23:34:11 +0200)
>>>>
>>>> ----------------------------------------------------------------
>>>> Two non critical fixes that can go in 3.11.
>>>> An old board removed.
>>>>
>>>> ----------------------------------------------------------------
>>>> Alexandre Belloni (1):
>>>>        ARM: at91: Fix link breakage when !CONFIG_PHYLIB
>>>
>>> Fix
>>>
>>>> Jean-Christophe PLAGNIOL-VILLARD (1):
>>>>        ARM: at91: drop rm9200dk board support
>>>
>>> Cleanup
>>>
>>>> Wenyou Yang (1):
>>>>        ARM: at91: Change the internal SRAM memory type MT_MEMORY_NONCACHED
>>>
>>> Fix
>>>
>>> ...assuming, of course, that none of the fixes are for errors introduced in
>>> some branch we already pulled, since then they should go on top of that branch.
>>
>> I do agree with you but:
>> 1/ the fixes are non-critical ones, so I do not see the need for another branch
>
> We're happy to take branches with fixes that are not needed for
> current release and queue them for the next one. We tend to merge
> those into next/fixes-non-critical.
>
>> 2/ I didn't feel like touching the "cleanup" branch because we want to base all our 3.11 material on top of it, without adding new patches on top.
>
> Adding new patches on top of a branch that is a base for something
> else is just fine, and is the way you're supposed to do things. You
> don't have to rebase the dependent branches just because they're not
> based on the tip of the cleanup tree any more. I.e. just send another
> pull request for "cleanups2" or whatever, that's based on the old
> cleanups branch/tag. After that, cleanups3 would be based on
> cleanups2. Etc. Some platforms do this a lot.
>
> Of course, that assumes that the additional cleanups don't conflict
> heavy with the later dependent branches like I already said. I don't
> think that was the case this time?

Fair enough, I have just sent 2 pull-requests:
- a fixes-non-critical one
- a cleanup one

Bye,
-- 
Nicolas Ferre