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

["Arnd Bergmann" <arnd@arndb.de>]

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