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

From: Olof Johansson
Date: Mon Jun 17 2013 - 12:59:52 EST

On Mon, Jun 17, 2013 at 2:20 AM, Ferre, Nicolas <Nicolas.FERRE@xxxxxxxxx> wrote:
> From: Olof Johansson [olof@xxxxxxxxx]
>>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:// 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
>>> Jean-Christophe PLAGNIOL-VILLARD (1):
>>> ARM: at91: drop rm9200dk board support
>>> Wenyou Yang (1):
>>> ARM: at91: Change the internal SRAM memory type MT_MEMORY_NONCACHED
>>...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?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at