drivers/cxl/acpi.c | 15 ++++----------- drivers/cxl/core/region.c | 25 +++++++------------------ drivers/cxl/cxl.h | 2 +- 3 files changed, 12 insertions(+), 30 deletions(-)
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(-) -- 2.47.3
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(-) > Series merged to cxl/next 7e71fa6e015e cxl/region: Remove local variable @inc in cxl_port_setup_targets() c42a4d2ee3b2 cxl/acpi: Group xor arithmetric setup code in a single block 6123133ee90f cxl: Simplify cxl_rd_ops allocation and handling
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
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Also:
---
✓ [PATCH 1/3] cxl: Simplify cxl_rd_ops allocation and handling
+ Link: https://patch.msgid.link/20251112205105.1271726-2-rrichter@amd.com
+ Signed-off-by: Dave Jiang <dave.jiang@intel.com>
● checkpatch.pl: 118: WARNING: 'existance' may be misspelled - perhaps 'existence'?
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. 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. > hint: Use 'git am --show-current-patch=diff' to see the failed patch > hint: When you have resolved this problem, run "git am --continue". > hint: If you prefer to skip this patch, run "git am --skip" instead. > hint: To restore the original branch and stop patching, run "git am --abort". > hint: Disable this message with "git config set advice.mergeConflict false" > > Also: > --- > ✓ [PATCH 1/3] cxl: Simplify cxl_rd_ops allocation and handling > + Link: https://patch.msgid.link/20251112205105.1271726-2-rrichter@amd.com > + Signed-off-by: Dave Jiang <dave.jiang@intel.com> > ● checkpatch.pl: 118: WARNING: 'existance' may be misspelled - perhaps 'existence'? Will send an update and also update the sob-chain. Thanks, -Robert
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. > > 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?
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. Thanks, -Robert
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
On 13.11.25 13:10:56, Dave Jiang wrote: > 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: > >>> 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. Ok, thanks. -Robert
On 13.11.25 21:36:16, Robert Richter wrote: > On 13.11.25 13:10:56, Dave Jiang wrote: > > On 11/13/25 9:45 AM, Robert Richter wrote: > > 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. > > Ok, thanks. I sent you a delta patch as I don't have a public git tree at hand right now. -Robert
On 11/14/25 2:09 AM, Robert Richter wrote: > On 13.11.25 21:36:16, Robert Richter wrote: >> On 13.11.25 13:10:56, Dave Jiang wrote: >>> On 11/13/25 9:45 AM, Robert Richter wrote: > >>> 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. >> >> Ok, thanks. > > I sent you a delta patch as I don't have a public git tree at hand > right now. That works. Have you sent it yet? I don't think I've received it. Or I can give you push permission to my github repo if you can give me your github user name. https://github.com/davejiang/linux > > -Robert
On 14.11.25 08:32:00, Dave Jiang wrote: > > > On 11/14/25 2:09 AM, Robert Richter wrote: > > On 13.11.25 21:36:16, Robert Richter wrote: > >> On 13.11.25 13:10:56, Dave Jiang wrote: > >>> On 11/13/25 9:45 AM, Robert Richter wrote: > > > >>> 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. > >> > >> Ok, thanks. > > > > I sent you a delta patch as I don't have a public git tree at hand > > right now. > That works. Have you sent it yet? I don't think I've received it. Or > I can give you push permission to my github repo if you can give me > your github user name. See here: https://patchwork.kernel.org/project/cxl/patch/20251114090532.1323361-1-rrichter@amd.com/ -Robert
On 11/14/25 9:21 AM, Robert Richter wrote: > On 14.11.25 08:32:00, Dave Jiang wrote: >> >> >> On 11/14/25 2:09 AM, Robert Richter wrote: >>> On 13.11.25 21:36:16, Robert Richter wrote: >>>> On 13.11.25 13:10:56, Dave Jiang wrote: >>>>> On 11/13/25 9:45 AM, Robert Richter wrote: >>> >>>>> 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. >>>> >>>> Ok, thanks. >>> >>> I sent you a delta patch as I don't have a public git tree at hand >>> right now. > >> That works. Have you sent it yet? I don't think I've received it. Or >> I can give you push permission to my github repo if you can give me >> your github user name. > > See here: > > https://patchwork.kernel.org/project/cxl/patch/20251114090532.1323361-1-rrichter@amd.com/ > > -Robert Oh this is merge patch for the entire series. I thought it's just the 3 patches since we are merging those ahead of time while waiting for the rest of the series to be ready?
On 11/14/25 9:28 AM, Dave Jiang wrote: > > > On 11/14/25 9:21 AM, Robert Richter wrote: >> On 14.11.25 08:32:00, Dave Jiang wrote: >>> >>> >>> On 11/14/25 2:09 AM, Robert Richter wrote: >>>> On 13.11.25 21:36:16, Robert Richter wrote: >>>>> On 13.11.25 13:10:56, Dave Jiang wrote: >>>>>> On 11/13/25 9:45 AM, Robert Richter wrote: >>>> >>>>>> 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. >>>>> >>>>> Ok, thanks. >>>> >>>> I sent you a delta patch as I don't have a public git tree at hand >>>> right now. >> >>> That works. Have you sent it yet? I don't think I've received it. Or >>> I can give you push permission to my github repo if you can give me >>> your github user name. >> >> See here: >> >> https://patchwork.kernel.org/project/cxl/patch/20251114090532.1323361-1-rrichter@amd.com/ >> >> -Robert > > Oh this is merge patch for the entire series. I thought it's just the 3 patches since we are merging those ahead of time while waiting for the rest of the series to be ready? > > Robert, Can you please verify that this merge looks correct to you? Thanks! https://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl.git/log/?h=next-6.19-merge-prm-prep
On 14.11.25 11:18:23, Dave Jiang wrote: > > > On 11/14/25 9:28 AM, Dave Jiang wrote: > > > > > > On 11/14/25 9:21 AM, Robert Richter wrote: > >> On 14.11.25 08:32:00, Dave Jiang wrote: > >>> > >>> > >>> On 11/14/25 2:09 AM, Robert Richter wrote: > >>>> On 13.11.25 21:36:16, Robert Richter wrote: > >>>>> On 13.11.25 13:10:56, Dave Jiang wrote: > >>>>>> On 11/13/25 9:45 AM, Robert Richter wrote: > >>>> > >>>>>> 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. > >>>>> > >>>>> Ok, thanks. > >>>> > >>>> I sent you a delta patch as I don't have a public git tree at hand > >>>> right now. > >> > >>> That works. Have you sent it yet? I don't think I've received it. Or > >>> I can give you push permission to my github repo if you can give me > >>> your github user name. > >> > >> See here: > >> > >> https://patchwork.kernel.org/project/cxl/patch/20251114090532.1323361-1-rrichter@amd.com/ > >> > >> -Robert > > > > Oh this is merge patch for the entire series. I thought it's just the 3 patches since we are merging those ahead of time while waiting for the rest of the series to be ready? > > > > > Robert, > Can you please verify that this merge looks correct to you? Thanks! > https://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl.git/log/?h=next-6.19-merge-prm-prep > Yes, same what I have. Thanks. I am going to send v7 with an update of the comment of patch 11/11 (decoder lock). -Robert
On 11/14/25 11:25 AM, Robert Richter wrote: > On 14.11.25 11:18:23, Dave Jiang wrote: >> >> >> On 11/14/25 9:28 AM, Dave Jiang wrote: >>> >>> >>> On 11/14/25 9:21 AM, Robert Richter wrote: >>>> On 14.11.25 08:32:00, Dave Jiang wrote: >>>>> >>>>> >>>>> On 11/14/25 2:09 AM, Robert Richter wrote: >>>>>> On 13.11.25 21:36:16, Robert Richter wrote: >>>>>>> On 13.11.25 13:10:56, Dave Jiang wrote: >>>>>>>> On 11/13/25 9:45 AM, Robert Richter wrote: >>>>>> >>>>>>>> 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. >>>>>>> >>>>>>> Ok, thanks. >>>>>> >>>>>> I sent you a delta patch as I don't have a public git tree at hand >>>>>> right now. >>>> >>>>> That works. Have you sent it yet? I don't think I've received it. Or >>>>> I can give you push permission to my github repo if you can give me >>>>> your github user name. >>>> >>>> See here: >>>> >>>> https://patchwork.kernel.org/project/cxl/patch/20251114090532.1323361-1-rrichter@amd.com/ >>>> >>>> -Robert >>> >>> Oh this is merge patch for the entire series. I thought it's just the 3 patches since we are merging those ahead of time while waiting for the rest of the series to be ready? >>> >>> >> Robert, >> Can you please verify that this merge looks correct to you? Thanks! >> https://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl.git/log/?h=next-6.19-merge-prm-prep >> > > Yes, same what I have. Thanks. > > I am going to send v7 with an update of the comment of patch 11/11 > (decoder lock). You can use for-6.19/cxl-prm as base. I have pushed it to the cxl git.> > -Robert
On Thu, Nov 13, 2025 at 08:20:59AM -0700, Dave Jiang wrote: > On 11/13/25 4:01 AM, Robert Richter wrote: > > On 12.11.25 14:45:28, Dave Jiang wrote: > >> > >> > > 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? As an active user of the Zen5 translation patch (I've been carrying backports Zen5 support for over a year), I would greatly prefer not to delay the Zen5 series for the sake of this series. ~Gregory
On 11/13/25 8:32 AM, Gregory Price wrote: > On Thu, Nov 13, 2025 at 08:20:59AM -0700, Dave Jiang wrote: >> On 11/13/25 4:01 AM, Robert Richter wrote: >>> On 12.11.25 14:45:28, Dave Jiang wrote: >>>> >>>> >>> 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? > > As an active user of the Zen5 translation patch (I've been carrying > backports Zen5 support for over a year), I would greatly prefer not > to delay the Zen5 series for the sake of this series. Well if we can have the series applies cleanly on 6.18-rc5 with all the needed review tags and all the outstanding concerns resolved next week, we can go this cycle. I'd like Dan to take a look if he has time though. > > ~Gregory
© 2016 - 2026 Red Hat, Inc.