Re: [PATCH 0/3] CXL updates for v6.19

[Dave Jiang <dave.jiang@intel.com>]

On 11/13/25 9:45 AM, Robert Richter wrote:
> On 13.11.25 08:20:59, Dave Jiang wrote:
>>
>>
>> On 11/13/25 4:01 AM, Robert Richter wrote:
>>> On 12.11.25 14:45:28, Dave Jiang wrote:
>>>>
>>>>
>>>> On 11/12/25 1:51 PM, Robert Richter wrote:
>>>>> Sending optional and rather independent patches from v5 of the CXL
>>>>> address translation series [1] separately in this series. The patches
>>>>> could be applied together with early pick up candidates from the
>>>>> address translation series (namely patch #1 to #4 or #5).
>>>>>
>>>>> [1] https://patchwork.kernel.org/project/cxl/cover/20251112203143.1269944-1-rrichter@amd.com/
>>>>>
>>>>> Robert Richter (3):
>>>>>   cxl: Simplify cxl_rd_ops allocation and handling
>>>>>   cxl/acpi: Group xor arithmetric setup code in a single block
>>>>>   cxl/region: Remove local variable @inc in cxl_port_setup_targets()
>>>>>
>>>>>  drivers/cxl/acpi.c        | 15 ++++-----------
>>>>>  drivers/cxl/core/region.c | 25 +++++++------------------
>>>>>  drivers/cxl/cxl.h         |  2 +-
>>>>>  3 files changed, 12 insertions(+), 30 deletions(-)
>>>>>
>>>>
>>>> Hi Robert, I'm having issues applying to 6.18-rc4.
>>>>
>>>> Applying: cxl: Simplify cxl_rd_ops allocation and handling
>>>> Patch failed at 0001 cxl: Simplify cxl_rd_ops allocation and handling
>>>> error: patch failed: drivers/cxl/core/region.c:2958
>>>> error: drivers/cxl/core/region.c: patch does not apply
>>>
>>> You need to apply it on cxl/next. There are conflicts otherwise.
>>
>> Hi Robert,
> 
>> I actually need a series that cleanly applies to 6.18-rc4. I'll
>> attempt to resolve the conflicts when I merge that branch to
>> cxl/next. Of course a resolved public branch somewhere as guidance
>> would be appreciated as well. Patches should not be based on
>> cxl/next. Otherwise it gets really messy when I have to drop some
>> changes due to issues.
> 
> This conflict resolution was not trivial as code was moved around and
> then modified. It will be error prone and time consuming if someone
> else does the conflict resolution.
> 
> In the cxl tree the conflict resolution is most of the time done in
> merges which causes a headache when rebasing patches again on top of
> each other or when forward-porting patches to that tree. The merges
> basically hide the actual resolution and the patches that are involved
> in the conflict. Recreation of trees with merges is also not trival.
> 
> Compared to conflict resolution when doing a (hopefully rare) rebase
> of the cxl tree, it would be much cleaner if patches are on top of
> each other. There are no conflicts once rebased and you don't carry
> them around any longer. I don't see much benefit else. Also, the
> author should resolve the conflicts who best knows the code.
> 
> If you prefer merges, how about this: Have separate branches as long
> as there are no conflicts with mainline and merge them in. If there is
> a conflict with one or more branches, base new patches on top of that
> branch or create a merge point to port the patches on top of that.
> That branch with the patches in can then be merged into mainline, but
> there are no conflicts then.
> 
>>>
>>> Additionally, patch 3/3 (@inc variable change) of this series also
>>> depends on patch 02/11 of v5 (store root decoder in in struct
>>> cxl_region). If you chose to pickup some patches from v5 first on top
>>> of cxl/next, then all this 3 patches should apply cleanly.
>>>
>>> Since 02/11 is one of the first patches and it sounded to me some of
>>> them will be applied as well, I would prefer that order to avoid
>>> rebasing and resubmitting a v6 for that. Let me know if you want to
>>> handle this differently.
> 
>> Hmmm....maybe I should just take the entire series hopefully next
>> cycle when it's ready given all the dependencies?
> 
> Patches apply cleanly on top of each other, there is nothing that
> blocks.
> 
> Let me know how to move forward.

So currently we want to apply the 3 patches ahead of time right? Can you 1. post the series against 6.18-rc5, 2. provide a public branch (github or kernel.org) that merged this branch with cxl/next (given there are expected complications) that I can reference? That's really my preference.

> 
> Thanks,
> 
> -Robert