manual merge of the cix tree with the arm-soc tree
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.
arch/arm64/configs/defconfig +1 -0
@@ -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
Quoted 8 lines · Thierry Reding
Today's linux-next merge of the cix tree got a conflict in:
arch/arm64/configs/defconfigbetween commit:
f54f7979ff88("arm64: defconfig: Move entries to match savedefconfig")
Quoted 8 lines
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
Quoted 20 lines
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.
arch/arm64/configs/defconfig +1
-0@@ -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
Signature · 2 lines
Best regards, Peter
Quoted 5 lines · Peter Chen
Quoted 3 lines · Thierry Reding
It looks like the patch from the cix tree somehow partially landed in the arm-soc tree, even though it wasn't pulled yet.
Quoted 8 lines
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.
Quoted 5 lines
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 [email protected] 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
Quoted 13 lines · Arnd Bergmann
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.
Quoted 5 lines
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
Quoted 8 lines
Please send it as a normal pull request or patch to [email protected] 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?
Signature · 2 lines
Best regards, Peter
Quoted 14 lines · Peter Chen
Quoted 13 lines · Arnd Bergmann
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.
Quoted 5 lines
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/defconfigPlease send it as a normal pull request or patch to [email protected] so your change gets mered using the patchwork process.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 9 lines
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