linux-next: manual merge of the bcm2835 tree with the arm-soc tree

linux-next: manual merge of the bcm2835 tree with the arm-soc tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

Hi Stephen,

Today's linux-next merge of the bcm2835 tree got a conflict in
arch/arm/boot/dts/Makefile between commit 302a5ef29d49 ("ARM: BCM5301X:
Add DT for Netgear R6300 V2") from the arm-soc tree and commit
6298ed17a404 ("ARM: bcm2835: Add device tree for Raspberry Pi model
B+") from the bcm2835 tree.

I fixed it up (the bcm2835 tree patch is also in the arm-soc tree as
commit ba2a1d6959ac ("ARM: bcm2835: Add device tree for Raspberry Pi
model B+"), so I just used the arm-soc version) and can carry the fix
as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: linux-next: manual merge of the bcm2835 tree with the arm-soc tree

[Arnd Bergmann]

On Monday 08 December 2014 12:06:19 Stephen Rothwell wrote:
> Hi Stephen,
> 
> Today's linux-next merge of the bcm2835 tree got a conflict in
> arch/arm/boot/dts/Makefile between commit 302a5ef29d49 ("ARM: BCM5301X:
> Add DT for Netgear R6300 V2") from the arm-soc tree and commit
> 6298ed17a404 ("ARM: bcm2835: Add device tree for Raspberry Pi model
> B+") from the bcm2835 tree.
> 
> I fixed it up (the bcm2835 tree patch is also in the arm-soc tree as
> commit ba2a1d6959ac ("ARM: bcm2835: Add device tree for Raspberry Pi
> model B+"), so I just used the arm-soc version) and can carry the fix
> as necessary (no action is required).

Thanks a lot for the notification!

Lee, do you know what is going on? Did you accidentally rebase a commit
that you already sent for inclusion in arm-soc?

	Arnd

Re: linux-next: manual merge of the bcm2835 tree with the arm-soc tree

[Lee Jones]

On Mon, 08 Dec 2014, Arnd Bergmann wrote:

> On Monday 08 December 2014 12:06:19 Stephen Rothwell wrote:
> > Hi Stephen,
> > 
> > Today's linux-next merge of the bcm2835 tree got a conflict in
> > arch/arm/boot/dts/Makefile between commit 302a5ef29d49 ("ARM: BCM5301X:
> > Add DT for Netgear R6300 V2") from the arm-soc tree and commit
> > 6298ed17a404 ("ARM: bcm2835: Add device tree for Raspberry Pi model
> > B+") from the bcm2835 tree.
> > 
> > I fixed it up (the bcm2835 tree patch is also in the arm-soc tree as
> > commit ba2a1d6959ac ("ARM: bcm2835: Add device tree for Raspberry Pi
> > model B+"), so I just used the arm-soc version) and can carry the fix
> > as necessary (no action is required).
> 
> Thanks a lot for the notification!
> 
> Lee, do you know what is going on? Did you accidentally rebase a commit
> that you already sent for inclusion in arm-soc?

Nope.  The branch hasn't changed at all.

OOI why would a re-base affect anything?  I sent you it in patch form.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: linux-next: manual merge of the bcm2835 tree with the arm-soc tree

[Arnd Bergmann]

On Monday 08 December 2014 13:00:09 Lee Jones wrote:
> On Mon, 08 Dec 2014, Arnd Bergmann wrote:
> 
> > On Monday 08 December 2014 12:06:19 Stephen Rothwell wrote:
> > > Hi Stephen,
> > > 
> > > Today's linux-next merge of the bcm2835 tree got a conflict in
> > > arch/arm/boot/dts/Makefile between commit 302a5ef29d49 ("ARM: BCM5301X:
> > > Add DT for Netgear R6300 V2") from the arm-soc tree and commit
> > > 6298ed17a404 ("ARM: bcm2835: Add device tree for Raspberry Pi model
> > > B+") from the bcm2835 tree.
> > > 
> > > I fixed it up (the bcm2835 tree patch is also in the arm-soc tree as
> > > commit ba2a1d6959ac ("ARM: bcm2835: Add device tree for Raspberry Pi
> > > model B+"), so I just used the arm-soc version) and can carry the fix
> > > as necessary (no action is required).
> > 
> > Thanks a lot for the notification!
> > 
> > Lee, do you know what is going on? Did you accidentally rebase a commit
> > that you already sent for inclusion in arm-soc?
> 
> Nope.  The branch hasn't changed at all.
> 
> OOI why would a re-base affect anything?  I sent you it in patch form.

Ah, I looked at the wrong branch and didn't see that I applied a patch
instead of a pull request. It's all fine then, as long as you never
intend to send any pull requests based on top of your current branch.

You can possibly make Stephen's life a tiny bit simpler if you just
drop all patches from your for-next branch as soon as we've picked
them up into arm-soc.

	Arnd

Re: linux-next: manual merge of the bcm2835 tree with the arm-soc tree

[Lee Jones]

On Mon, 08 Dec 2014, Arnd Bergmann wrote:

> On Monday 08 December 2014 13:00:09 Lee Jones wrote:
> > On Mon, 08 Dec 2014, Arnd Bergmann wrote:
> > 
> > > On Monday 08 December 2014 12:06:19 Stephen Rothwell wrote:
> > > > Hi Stephen,
> > > > 
> > > > Today's linux-next merge of the bcm2835 tree got a conflict in
> > > > arch/arm/boot/dts/Makefile between commit 302a5ef29d49 ("ARM: BCM5301X:
> > > > Add DT for Netgear R6300 V2") from the arm-soc tree and commit
> > > > 6298ed17a404 ("ARM: bcm2835: Add device tree for Raspberry Pi model
> > > > B+") from the bcm2835 tree.
> > > > 
> > > > I fixed it up (the bcm2835 tree patch is also in the arm-soc tree as
> > > > commit ba2a1d6959ac ("ARM: bcm2835: Add device tree for Raspberry Pi
> > > > model B+"), so I just used the arm-soc version) and can carry the fix
> > > > as necessary (no action is required).
> > > 
> > > Thanks a lot for the notification!
> > > 
> > > Lee, do you know what is going on? Did you accidentally rebase a commit
> > > that you already sent for inclusion in arm-soc?
> > 
> > Nope.  The branch hasn't changed at all.
> > 
> > OOI why would a re-base affect anything?  I sent you it in patch form.
> 
> Ah, I looked at the wrong branch and didn't see that I applied a patch
> instead of a pull request. It's all fine then, as long as you never
> intend to send any pull requests based on top of your current branch.
> 
> You can possibly make Stephen's life a tiny bit simpler if you just
> drop all patches from your for-next branch as soon as we've picked
> them up into arm-soc.

That is something I thought about, but I believe we have users of that
branch.  I guess we could always point them to ARM-SoC, or reset the
branch to the aforementioned.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: linux-next: manual merge of the bcm2835 tree with the arm-soc tree

[Arnd Bergmann]

On Monday 08 December 2014 13:49:03 Lee Jones wrote:
> On Mon, 08 Dec 2014, Arnd Bergmann wrote:
> 
> > On Monday 08 December 2014 13:00:09 Lee Jones wrote:
> > > On Mon, 08 Dec 2014, Arnd Bergmann wrote:
> > > 
> > > > On Monday 08 December 2014 12:06:19 Stephen Rothwell wrote:
> > > > > Hi Stephen,
> > > > > 
> > > > > Today's linux-next merge of the bcm2835 tree got a conflict in
> > > > > arch/arm/boot/dts/Makefile between commit 302a5ef29d49 ("ARM: BCM5301X:
> > > > > Add DT for Netgear R6300 V2") from the arm-soc tree and commit
> > > > > 6298ed17a404 ("ARM: bcm2835: Add device tree for Raspberry Pi model
> > > > > B+") from the bcm2835 tree.
> > > > > 
> > > > > I fixed it up (the bcm2835 tree patch is also in the arm-soc tree as
> > > > > commit ba2a1d6959ac ("ARM: bcm2835: Add device tree for Raspberry Pi
> > > > > model B+"), so I just used the arm-soc version) and can carry the fix
> > > > > as necessary (no action is required).
> > > > 
> > > > Thanks a lot for the notification!
> > > > 
> > > > Lee, do you know what is going on? Did you accidentally rebase a commit
> > > > that you already sent for inclusion in arm-soc?
> > > 
> > > Nope.  The branch hasn't changed at all.
> > > 
> > > OOI why would a re-base affect anything?  I sent you it in patch form.
> > 
> > Ah, I looked at the wrong branch and didn't see that I applied a patch
> > instead of a pull request. It's all fine then, as long as you never
> > intend to send any pull requests based on top of your current branch.
> > 
> > You can possibly make Stephen's life a tiny bit simpler if you just
> > drop all patches from your for-next branch as soon as we've picked
> > them up into arm-soc.
> 
> That is something I thought about, but I believe we have users of that
> branch.  I guess we could always point them to ARM-SoC, or reset the
> branch to the aforementioned.

How about adding another branch then, which contains everything you
expect to get merged into the next kernel and that you can provide
to your users but that is potentially separate from the one that Stephen
pulls into linux-next?

	ARnd

Re: linux-next: manual merge of the bcm2835 tree with the arm-soc tree

[Stephen Warren]

On 12/08/2014 06:49 AM, Lee Jones wrote:
> On Mon, 08 Dec 2014, Arnd Bergmann wrote:
>
>> On Monday 08 December 2014 13:00:09 Lee Jones wrote:
>>> On Mon, 08 Dec 2014, Arnd Bergmann wrote:
>>>
>>>> On Monday 08 December 2014 12:06:19 Stephen Rothwell wrote:
>>>>> Hi Stephen,
>>>>>
>>>>> Today's linux-next merge of the bcm2835 tree got a conflict in
>>>>> arch/arm/boot/dts/Makefile between commit 302a5ef29d49 ("ARM: BCM5301X:
>>>>> Add DT for Netgear R6300 V2") from the arm-soc tree and commit
>>>>> 6298ed17a404 ("ARM: bcm2835: Add device tree for Raspberry Pi model
>>>>> B+") from the bcm2835 tree.
>>>>>
>>>>> I fixed it up (the bcm2835 tree patch is also in the arm-soc tree as
>>>>> commit ba2a1d6959ac ("ARM: bcm2835: Add device tree for Raspberry Pi
>>>>> model B+"), so I just used the arm-soc version) and can carry the fix
>>>>> as necessary (no action is required).
>>>>
>>>> Thanks a lot for the notification!
>>>>
>>>> Lee, do you know what is going on? Did you accidentally rebase a commit
>>>> that you already sent for inclusion in arm-soc?
>>>
>>> Nope.  The branch hasn't changed at all.
>>>
>>> OOI why would a re-base affect anything?  I sent you it in patch form.
>>
>> Ah, I looked at the wrong branch and didn't see that I applied a patch
>> instead of a pull request. It's all fine then, as long as you never
>> intend to send any pull requests based on top of your current branch.
>>
>> You can possibly make Stephen's life a tiny bit simpler if you just
>> drop all patches from your for-next branch as soon as we've picked
>> them up into arm-soc.
>
> That is something I thought about, but I believe we have users of that
> branch.  I guess we could always point them to ARM-SoC, or reset the
> branch to the aforementioned.

The primary purpose of the kernel.org linux-rpi.git repo is for staging 
patches into arm-soc/linux-next. As such, just like any other similar 
repo, users should expect at least the for-xxx (e.g. for-next) branches 
to get reset as kernel versions tick over, in order to contain the 
content for the next kernel. Anyone using those branches for anything 
else (e.g. local development) simply has to be prepared to do a rebase 
themselves when that happens.

Equally, and patches that get sent to arm-soc should probably never be 
applied to linux-rpi.git; anything that gets applied to linux-rpi.git 
should get sent to arm-soc as a pull request. That avoids duplicate commits.

Re: linux-next: manual merge of the bcm2835 tree with the arm-soc tree

[Lee Jones]

On Mon, 08 Dec 2014, Stephen Warren wrote:
> On 12/08/2014 06:49 AM, Lee Jones wrote:
> >On Mon, 08 Dec 2014, Arnd Bergmann wrote:
> >
> >>On Monday 08 December 2014 13:00:09 Lee Jones wrote:
> >>>On Mon, 08 Dec 2014, Arnd Bergmann wrote:
> >>>
> >>>>On Monday 08 December 2014 12:06:19 Stephen Rothwell wrote:
> >>>>>Hi Stephen,
> >>>>>
> >>>>>Today's linux-next merge of the bcm2835 tree got a conflict in
> >>>>>arch/arm/boot/dts/Makefile between commit 302a5ef29d49 ("ARM: BCM5301X:
> >>>>>Add DT for Netgear R6300 V2") from the arm-soc tree and commit
> >>>>>6298ed17a404 ("ARM: bcm2835: Add device tree for Raspberry Pi model
> >>>>>B+") from the bcm2835 tree.
> >>>>>
> >>>>>I fixed it up (the bcm2835 tree patch is also in the arm-soc tree as
> >>>>>commit ba2a1d6959ac ("ARM: bcm2835: Add device tree for Raspberry Pi
> >>>>>model B+"), so I just used the arm-soc version) and can carry the fix
> >>>>>as necessary (no action is required).
> >>>>
> >>>>Thanks a lot for the notification!
> >>>>
> >>>>Lee, do you know what is going on? Did you accidentally rebase a commit
> >>>>that you already sent for inclusion in arm-soc?
> >>>
> >>>Nope.  The branch hasn't changed at all.
> >>>
> >>>OOI why would a re-base affect anything?  I sent you it in patch form.
> >>
> >>Ah, I looked at the wrong branch and didn't see that I applied a patch
> >>instead of a pull request. It's all fine then, as long as you never
> >>intend to send any pull requests based on top of your current branch.
> >>
> >>You can possibly make Stephen's life a tiny bit simpler if you just
> >>drop all patches from your for-next branch as soon as we've picked
> >>them up into arm-soc.
> >
> >That is something I thought about, but I believe we have users of that
> >branch.  I guess we could always point them to ARM-SoC, or reset the
> >branch to the aforementioned.
> 
> The primary purpose of the kernel.org linux-rpi.git repo is for
> staging patches into arm-soc/linux-next. As such, just like any
> other similar repo, users should expect at least the for-xxx (e.g.
> for-next) branches to get reset as kernel versions tick over, in
> order to contain the content for the next kernel. Anyone using those
> branches for anything else (e.g. local development) simply has to be
> prepared to do a rebase themselves when that happens.

I agree with this.

> Equally, and patches that get sent to arm-soc should probably never
> be applied to linux-rpi.git; anything that gets applied to
> linux-rpi.git should get sent to arm-soc as a pull request. That
> avoids duplicate commits.

I'm okay to follow this rule if my perception of the tree is changed.
The current view is that this repo can be used by engineers/hobbyists
as a single resource to pick up RPi patches which are yet to complete
their full transition into Mainline.

Arnd and I had a discussion where I flagged my concerns about these
kinds of conflicts.  The outcome was that as long as the patches were
simple enough, then no conflict should arise.  Unfortunately this
turned out not to be quite true.

So I'm happy with whatever.  Stephen, the repo is your concept.  I'll
play it however you want me to play it.  As the merge-window is now
open I'm going to eradicate rpi/for-next in any case.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: linux-next: manual merge of the bcm2835 tree with the arm-soc tree

[Stephen Warren]

On 12/08/2014 09:51 AM, Lee Jones wrote:
> On Mon, 08 Dec 2014, Stephen Warren wrote:
...
>> The primary purpose of the kernel.org linux-rpi.git repo is for
>> staging patches into arm-soc/linux-next. As such, just like any
>> other similar repo, users should expect at least the for-xxx (e.g.
>> for-next) branches to get reset as kernel versions tick over, in
>> order to contain the content for the next kernel. Anyone using those
>> branches for anything else (e.g. local development) simply has to be
>> prepared to do a rebase themselves when that happens.
>
> I agree with this.
>
>> Equally, and patches that get sent to arm-soc should probably never
>> be applied to linux-rpi.git; anything that gets applied to
>> linux-rpi.git should get sent to arm-soc as a pull request. That
>> avoids duplicate commits.
>
> I'm okay to follow this rule if my perception of the tree is changed.
> The current view is that this repo can be used by engineers/hobbyists
> as a single resource to pick up RPi patches which are yet to complete
> their full transition into Mainline.
>
> Arnd and I had a discussion where I flagged my concerns about these
> kinds of conflicts.  The outcome was that as long as the patches were
> simple enough, then no conflict should arise.  Unfortunately this
> turned out not to be quite true.
>
> So I'm happy with whatever.  Stephen, the repo is your concept.  I'll
> play it however you want me to play it.  As the merge-window is now
> open I'm going to eradicate rpi/for-next in any case.

Eradicate or reset? If you delete it, Stephen Rothwell will have a 
problem fetching it when creating linux-next. Usually to empty out the 
for-next branch, you'd reset it to some recent Linus tag; 3.18 seems 
like a good one at present.

Re: linux-next: manual merge of the bcm2835 tree with the arm-soc tree

[Lee Jones]

On Mon, 08 Dec 2014, Stephen Warren wrote:

> On 12/08/2014 09:51 AM, Lee Jones wrote:
> >On Mon, 08 Dec 2014, Stephen Warren wrote:
> ...
> >>The primary purpose of the kernel.org linux-rpi.git repo is for
> >>staging patches into arm-soc/linux-next. As such, just like any
> >>other similar repo, users should expect at least the for-xxx (e.g.
> >>for-next) branches to get reset as kernel versions tick over, in
> >>order to contain the content for the next kernel. Anyone using those
> >>branches for anything else (e.g. local development) simply has to be
> >>prepared to do a rebase themselves when that happens.
> >
> >I agree with this.
> >
> >>Equally, and patches that get sent to arm-soc should probably never
> >>be applied to linux-rpi.git; anything that gets applied to
> >>linux-rpi.git should get sent to arm-soc as a pull request. That
> >>avoids duplicate commits.
> >
> >I'm okay to follow this rule if my perception of the tree is changed.
> >The current view is that this repo can be used by engineers/hobbyists
> >as a single resource to pick up RPi patches which are yet to complete
> >their full transition into Mainline.
> >
> >Arnd and I had a discussion where I flagged my concerns about these
> >kinds of conflicts.  The outcome was that as long as the patches were
> >simple enough, then no conflict should arise.  Unfortunately this
> >turned out not to be quite true.
> >
> >So I'm happy with whatever.  Stephen, the repo is your concept.  I'll
> >play it however you want me to play it.  As the merge-window is now
> >open I'm going to eradicate rpi/for-next in any case.
> 
> Eradicate or reset? If you delete it, Stephen Rothwell will have a
> problem fetching it when creating linux-next. Usually to empty out
> the for-next branch, you'd reset it to some recent Linus tag; 3.18
> seems like a good one at present.

Yes, in this case eradicate == `git reset <blah>`.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

linux-next: manual merge of the bcm2835 tree with the arm-soc tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]

Hi Stephen/Rob,

Today's linux-next merge of the bcm2835 tree got a conflict in  between commit  ddb902cc34593ecb ("ARM: centralize common multi-platform kconfig options") from the arm-soc tree and commit d30fe6272183f3cc8b ("ARM: bcm2835: Move to mach-bcm directory") from the bcm2835 tree. Commit 0676b21fffd17baeff589 ("ARM: bcm2835: enable V6K instead of plain V6") also collided.

I've fixed up as below and can carry:

diff --cc arch/arm/mach-bcm/Kconfig
index af4f2dfda40c,4e466e9eef44..7de3282a8613
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@@ -27,6 -32,22 +27,18 @@@ config ARCH_BCM_MOBIL
  	  BCM11130, BCM11140, BCM11351, BCM28145 and
  	  BCM28155 variants.
  
+ config ARCH_BCM2835
+ 	bool "Broadcom BCM2835 family" if ARCH_MULTI_V6
+ 	select ARCH_REQUIRE_GPIOLIB
+ 	select ARM_AMBA
+ 	select ARM_ERRATA_411920
+ 	select ARM_TIMER_SP804
 -	select CLKDEV_LOOKUP
 -	select CLKSRC_OF
 -	select CPU_V6
 -	select GENERIC_CLOCKEVENTS
+ 	select PINCTRL
+ 	select PINCTRL_BCM2835
+ 	help
+ 	  This enables support for the Broadcom BCM2835 SoC. This SoC is
+ 	  used in the Raspberry Pi and Roku 2 devices.
+ 
  endmenu
  
  endif

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the bcm2835 tree with the arm-soc tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]

Hi Stephen,

Today's linux-next merge of the bcm2835 tree got a conflict in
arch/arm/mach-bcm2835/Kconfig between commits ddb902cc3459 ("ARM:
centralize common multi-platform kconfig options") and 0676b21fffd1
("ARM: bcm2835: enable V6K instead of plain V6") from the arm-soc tree
and commit d30fe6272183 ("ARM: bcm2835: Move to mach-bcm directory") from
the bcm2835 tree.

I fixed it up (I applied the below merge fix patch) and can carry the fix
as necessary (no action is required).

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 3 Mar 2014 12:00:40 +1100
Subject: [PATCH] ARM: bcm2835: merge fix for movement to mach-bcm directory

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm/mach-bcm/Kconfig | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 396d05c8b570..7de3282a8613 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -33,10 +33,6 @@ config ARCH_BCM2835
 	select ARM_AMBA
 	select ARM_ERRATA_411920
 	select ARM_TIMER_SP804
-	select CLKDEV_LOOKUP
-	select CLKSRC_OF
-	select CPU_V6
-	select GENERIC_CLOCKEVENTS
 	select PINCTRL
 	select PINCTRL_BCM2835
 	help
-- 
1.9.0

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the bcm2835 tree with the arm-soc tree

[Stephen Warren]

On 03/02/2014 06:02 PM, Stephen Rothwell wrote:
> Hi Stephen,
> 
> Today's linux-next merge of the bcm2835 tree got a conflict in 
> arch/arm/mach-bcm2835/Kconfig between commits ddb902cc3459 ("ARM: 
> centralize common multi-platform kconfig options") and
> 0676b21fffd1 ("ARM: bcm2835: enable V6K instead of plain V6") from
> the arm-soc tree and commit d30fe6272183 ("ARM: bcm2835: Move to
> mach-bcm directory") from the bcm2835 tree.

Olof, Arnd, Kevin,

Do you want me to rebase the patch that moves
arch/arm/mach-bcm2835/Kconfig into arch/arm/mach-bcm/Kconfig, or even
drop it and take it through arm-soc directly? Or, will you just handle
this when you merge the pull request?

Re: linux-next: manual merge of the bcm2835 tree with the arm-soc tree

[Olof Johansson]

On Sun, Mar 2, 2014 at 9:21 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 03/02/2014 06:02 PM, Stephen Rothwell wrote:
>> Hi Stephen,
>>
>> Today's linux-next merge of the bcm2835 tree got a conflict in
>> arch/arm/mach-bcm2835/Kconfig between commits ddb902cc3459 ("ARM:
>> centralize common multi-platform kconfig options") and
>> 0676b21fffd1 ("ARM: bcm2835: enable V6K instead of plain V6") from
>> the arm-soc tree and commit d30fe6272183 ("ARM: bcm2835: Move to
>> mach-bcm directory") from the bcm2835 tree.
>
> Olof, Arnd, Kevin,
>
> Do you want me to rebase the patch that moves
> arch/arm/mach-bcm2835/Kconfig into arch/arm/mach-bcm/Kconfig, or even
> drop it and take it through arm-soc directly? Or, will you just handle
> this when you merge the pull request?

We should be fine handling it when we merge. Conflicts when we merge
in are just fine unless they are excessive, what we want to avoid for
most silly cases is when it'll be exposed all the way up to Linus.
Even then, some of them are ok since it's just how development works.


-Olof

linux-next: manual merge of the bcm2835 tree with the arm-soc tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

Hi Stephen,

Today's linux-next merge of the bcm2835 tree got a conflict in
arch/arm/Kconfig.debug between commit 29c9b7be7574 ("ARM: cns3xxx: move
debug_ll code to include/debug/") from the arm-soc tree and commit
f1ac922dec7e ("ARM: bcm2835: convert to multi-platform") from the bcm2835
tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/Kconfig.debug
index bce30a8,a877d51..0000000
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@@ -593,7 -583,7 +597,8 @@@ endchoic
  
  config DEBUG_LL_INCLUDE
  	string
+ 	default "debug/bcm2835.S" if DEBUG_BCM2835
 +	default "debug/cns3xxx.S" if DEBUG_CNS3XXX
  	default "debug/icedcc.S" if DEBUG_ICEDCC
  	default "debug/imx.S" if DEBUG_IMX1_UART || \
  				 DEBUG_IMX25_UART || \

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the bcm2835 tree with the arm-soc tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]

Hi Stephen,

Today's linux-next merge of the bcm2835 tree got a conflict in
arch/arm/Kconfig between commit 15bc1fe67f66 ("ARM: cns3xxx: enable
multiplatform support") from the arm-soc tree and commit f1ac922dec7e
("ARM: bcm2835: convert to multi-platform") from the bcm2835 tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/Kconfig
index c63daef,0d3daa6..0000000
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@@ -362,26 -362,17 +362,6 @@@ config ARCH_AT9
  	  This enables support for systems based on Atmel
  	  AT91RM9200 and AT91SAM9* processors.
  
- config ARCH_BCM2835
- 	bool "Broadcom BCM2835 family"
- 	select ARCH_REQUIRE_GPIOLIB
- 	select ARM_AMBA
- 	select ARM_ERRATA_411920
- 	select ARM_TIMER_SP804
- 	select CLKDEV_LOOKUP
- 	select CLKSRC_OF
- 	select COMMON_CLK
- 	select CPU_V6
- 	select GENERIC_CLOCKEVENTS
- 	select MULTI_IRQ_HANDLER
- 	select PINCTRL
- 	select PINCTRL_BCM2835
- 	select SPARSE_IRQ
- 	select USE_OF
- 	help
- 	  This enables support for the Broadcom BCM2835 SoC. This SoC is
- 	  use in the Raspberry Pi, and Roku 2 devices.
- 
 -config ARCH_CNS3XXX
 -	bool "Cavium Networks CNS3XXX family"
 -	select ARM_GIC
 -	select CPU_V6K
 -	select GENERIC_CLOCKEVENTS
 -	select MIGHT_HAVE_CACHE_L2X0
 -	select MIGHT_HAVE_PCI
 -	select PCI_DOMAINS if PCI
 -	help
 -	  Support for Cavium Networks CNS3XXX platform.
 -
  config ARCH_CLPS711X
  	bool "Cirrus Logic CLPS711x/EP721x/EP731x-based"
  	select ARCH_REQUIRE_GPIOLIB

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the bcm2835 tree with the arm-soc tree

[Stephen Warren]

On 03/17/2013 10:04 PM, Stephen Rothwell wrote:
> Hi Stephen,
> 
> Today's linux-next merge of the bcm2835 tree got a conflict in 
> arch/arm/Kconfig between commit 15bc1fe67f66 ("ARM: cns3xxx:
> enable multiplatform support") from the arm-soc tree and commit
> f1ac922dec7e ("ARM: bcm2835: convert to multi-platform") from the
> bcm2835 tree.

Thanks. The resolution for the two bcm2835/arm-soc conflicts looks
fine. These conflicts should go away once I send bcm2835 pull requests
to arm-soc for inclusion in 3.10.