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

login
register
mail settings
Submitter Nicolas Ferre
Date June 14, 2013, 9:42 p.m.
Message ID <1371246138-22207-1-git-send-email-nicolas.ferre@atmel.com>
Download mbox
Permalink /patch/251543/
State New
Headers show

Pull-request

git://github.com/at91linux/linux-at91.git tags/at91-soc

Comments

Nicolas Ferre - June 14, 2013, 9:42 p.m.
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

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

 arch/arm/configs/at91rm9200_defconfig |   1 -
 arch/arm/mach-at91/Kconfig            |   1 +
 arch/arm/mach-at91/Kconfig.non_dt     |   7 --
 arch/arm/mach-at91/Makefile           |   1 -
 arch/arm/mach-at91/board-dt-sama5.c   |   3 +-
 arch/arm/mach-at91/board-rm9200dk.c   | 228 ----------------------------------
 arch/arm/mach-at91/setup.c            |   2 +-
 7 files changed, 4 insertions(+), 239 deletions(-)
 delete mode 100644 arch/arm/mach-at91/board-rm9200dk.c
Olof Johansson - June 15, 2013, 2:37 a.m.
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.


-Olof
Nicolas Ferre - June 17, 2013, 9:20 a.m.
From: Olof Johansson [olof@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
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.

But, tell me if you think that it is too cautious...

Bye,
Jean-Christophe PLAGNIOL-VILLARD - June 17, 2013, 9:27 a.m.
On Jun 17, 2013, at 11:20 AM, "Ferre, Nicolas" <Nicolas.FERRE@atmel.com> wrote:

> From: Olof Johansson [olof@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
> 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.
I do agree with Nico on this as the cleanup this time was done early to avoid nightmare conflict so I prefer we do not touch it

Best Regards,
J.
> 
> But, tell me if you think that it is too cautious...
> 
> Bye,
> -- 
> Nicolas Ferre
Olof Johansson - June 17, 2013, 4:59 p.m.
On Mon, Jun 17, 2013 at 2:20 AM, Ferre, Nicolas <Nicolas.FERRE@atmel.com> wrote:
> From: Olof Johansson [olof@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?


-Olof
Nicolas Ferre - June 18, 2013, 8:45 a.m.
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@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,