manual merge of the cix tree with the arm-soc tree

manual merge of the cix tree with the arm-soc tree

[Thierry Reding]

Today's linux-next merge of the cix tree got a conflict in:

  arch/arm64/configs/defconfig

between commit:

  f54f7979ff88 ("arm64: defconfig: Move entries to match savedefconfig")

from the arm-soc trees and commit:

  f4f1e3bdb5f9 ("arm64: defconfig: Enable CIX Sky1 pinctrl, PCIe host, and Cadence GPIO")

from the cix tree.

It looks like the patch from the cix tree somehow partially landed in
the arm-soc tree, even though it wasn't pulled yet.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 094bb9cd8764..e5f1901ee408 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -701,6 +701,7 @@ CONFIG_PINCTRL_SM8550_LPASS_LPI=m
 CONFIG_PINCTRL_SM8650_LPASS_LPI=m
 CONFIG_PINCTRL_SOPHGO_SG2000=y
 CONFIG_GPIO_ALTERA=m
+CONFIG_GPIO_CADENCE=m
 CONFIG_GPIO_DAVINCI=y
 CONFIG_GPIO_DWAPB=y
 CONFIG_GPIO_MB86S7X=y

Re: manual merge of the cix tree with the arm-soc tree

[Peter Chen]

On 26-05-08 11:12:23, Thierry Reding wrote:
> Today's linux-next merge of the cix tree got a conflict in:
> 
>   arch/arm64/configs/defconfig
> 
> between commit:
> 
>   f54f7979ff88 ("arm64: defconfig: Move entries to match savedefconfig")
> 
> from the arm-soc trees and commit:
> 
>   f4f1e3bdb5f9 ("arm64: defconfig: Enable CIX Sky1 pinctrl, PCIe host, and Cadence GPIO")
> 
> from the cix tree.
> 
> It looks like the patch from the cix tree somehow partially landed in
> the arm-soc tree, even though it wasn't pulled yet.

Hi Thierry,

Sorry for about it.

The above CIX things defconfig changes have reviewed near to Arm64 v7.1-rc1
merge window close, so I have not sent pull-request for it, and it left
at cix's for-next tree. These two days, I rebased cix's for-next tree to
v7.1-rc2, and this patch is on top of it.

Arnd, I deleted this patch at CIX next-tree. Would you please help queue it
in your soc/defconfig:

https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/cix.git/
branch: cix/defconfig

Thanks,
Peter

> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 094bb9cd8764..e5f1901ee408 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -701,6 +701,7 @@ CONFIG_PINCTRL_SM8550_LPASS_LPI=m
>  CONFIG_PINCTRL_SM8650_LPASS_LPI=m
>  CONFIG_PINCTRL_SOPHGO_SG2000=y
>  CONFIG_GPIO_ALTERA=m
> +CONFIG_GPIO_CADENCE=m
>  CONFIG_GPIO_DAVINCI=y
>  CONFIG_GPIO_DWAPB=y
>  CONFIG_GPIO_MB86S7X=y

-- 

Best regards,
Peter

Re: manual merge of the cix tree with the arm-soc tree

[Arnd Bergmann]

On Fri, May 8, 2026, at 12:52, Peter Chen wrote:
> On 26-05-08 11:12:23, Thierry Reding wrote:
>> 
>> It looks like the patch from the cix tree somehow partially landed in
>> the arm-soc tree, even though it wasn't pulled yet.
>
> Hi Thierry,
>
> Sorry for about it.
>
> The above CIX things defconfig changes have reviewed near to Arm64 v7.1-rc1
> merge window close, so I have not sent pull-request for it, and it left
> at cix's for-next tree. These two days, I rebased cix's for-next tree to
> v7.1-rc2, and this patch is on top of it.

Hi Peter,

this is not a problem you caused, just something to be aware of
when you send the pull request, and to check that Thierry made
the right choice in resolving it.

> Arnd, I deleted this patch at CIX next-tree. Would you please help queue it
> in your soc/defconfig:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/cix.git/
> branch: cix/defconfig

Please send it as a normal pull request or patch to soc@lists.linux.dev
so your change gets mered using the patchwork process.

If you send it as a standalone patch, please make sure it applies
on top of the soc/defconfig branch. A pull request is also fine,
and that would normally be based on -rc1. Obviously this causes
a merge conflict, which we will resolve during the merge.

     Arnd

Re: manual merge of the cix tree with the arm-soc tree

[Peter Chen]

On 26-05-08 13:06:02, Arnd Bergmann wrote:
> 
> Hi Peter,
> 
> this is not a problem you caused, just something to be aware of
> when you send the pull request, and to check that Thierry made
> the right choice in resolving it.
> 
> > Arnd, I deleted this patch at CIX next-tree. Would you please help queue it
> > in your soc/defconfig:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/cix.git/
> > branch: cix/defconfig
> 
> Please send it as a normal pull request or patch to soc@lists.linux.dev
> so your change gets mered using the patchwork process.
> 
> If you send it as a standalone patch, please make sure it applies
> on top of the soc/defconfig branch. A pull request is also fine,
> and that would normally be based on -rc1. Obviously this causes
> a merge conflict, which we will resolve during the merge.
> 

Hi Arnd,

Thanks for explaining it. So, for linux-next merge confliction patch,
how to handle it better?
Option 1:
Send pull-request to SoC maintainer once linux-next merge conflict happens, and
depends on SoC maintainer's tree at linux-next for testing
Option 2:
Rebase on SoC maintainer's tree, and still keep patches on SoC submaintainer's tree
at linux-next for testing
Other options?

-- 

Best regards,
Peter

Re: manual merge of the cix tree with the arm-soc tree

[Arnd Bergmann]

On Sat, May 9, 2026, at 03:16, Peter Chen wrote:
> On 26-05-08 13:06:02, Arnd Bergmann wrote:
>> this is not a problem you caused, just something to be aware of
>> when you send the pull request, and to check that Thierry made
>> the right choice in resolving it.
>> 
>> > Arnd, I deleted this patch at CIX next-tree. Would you please help queue it
>> > in your soc/defconfig:
>> >
>> > https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/cix.git/
>> > branch: cix/defconfig
>> 
>> Please send it as a normal pull request or patch to soc@lists.linux.dev
>> so your change gets mered using the patchwork process.
>> 
>> If you send it as a standalone patch, please make sure it applies
>> on top of the soc/defconfig branch. A pull request is also fine,
>> and that would normally be based on -rc1. Obviously this causes
>> a merge conflict, which we will resolve during the merge.
>
> Thanks for explaining it. So, for linux-next merge confliction patch,
> how to handle it better?

You have to look at each case separately. My comment above was about
the defconfig conflict, which will be resolved as soon as the
conflicting patches are both on the soc/defconfig branch.

> Option 1:
> Send pull-request to SoC maintainer once linux-next merge conflict 
> happens, and
> depends on SoC maintainer's tree at linux-next for testing
> Option 2:
> Rebase on SoC maintainer's tree, and still keep patches on SoC 
> submaintainer's tree
> at linux-next for testing
> Other options?

Neither of those really.

You should send the pull requests for the SoC tree as soon
as it makes sense for the contents to be merged. If you know that
there is a conflict (because you got a message about it
for linux-next), put that information into the pull request
text so we know about it.

If the conflict is against a change in some other tree,
we still need to know about it, in order to plan the upstream
submission.

Most conflicts are entirely trivial to resolve, so
upstream maintainers are usually ok with them. If you
encounter something that does not look trivial, that usually
means we need to talk about it and come up with a solution
for that specific case.

     Arnd