On Mon, Jun 17, 2013 at 2:20 AM, Ferre, Nicolas <[email protected]> wrote: > From: Olof Johansson [[email protected]] >>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? -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
