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

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

[Robert Richter]

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

[PATCH 1/3] cxl: Simplify cxl_rd_ops allocation and handling

[Robert Richter]

A root decoder's callback handlers are collected in struct cxl_rd_ops.
The structure is dynamically allocated, though it contains only a few
pointers in it. This also requires to check two pointes to check for
the existance of a callback.

Simplify the allocation, release and handler check by embedding the
ops statically in struct cxl_root_decoder.

Implementation is equivalent to how struct cxl_root_ops handles the
callbacks.

Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Robert Richter <rrichter@amd.com>
---
 drivers/cxl/acpi.c        |  8 ++------
 drivers/cxl/core/region.c | 20 +++++---------------
 drivers/cxl/cxl.h         |  2 +-
 3 files changed, 8 insertions(+), 22 deletions(-)

diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c
index d5119de7f5a9..fab736aa77dc 100644
--- a/drivers/cxl/acpi.c
+++ b/drivers/cxl/acpi.c
@@ -487,12 +487,8 @@ static int __cxl_parse_cfmws(struct acpi_cedt_cfmws *cfmws,
 	cxlrd->qos_class = cfmws->qtg_id;
 
 	if (cfmws->interleave_arithmetic == ACPI_CEDT_CFMWS_ARITHMETIC_XOR) {
-		cxlrd->ops = kzalloc(sizeof(*cxlrd->ops), GFP_KERNEL);
-		if (!cxlrd->ops)
-			return -ENOMEM;
-
-		cxlrd->ops->hpa_to_spa = cxl_apply_xor_maps;
-		cxlrd->ops->spa_to_hpa = cxl_apply_xor_maps;
+		cxlrd->ops.hpa_to_spa = cxl_apply_xor_maps;
+		cxlrd->ops.spa_to_hpa = cxl_apply_xor_maps;
 	}
 
 	rc = cxl_decoder_add(cxld);
diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
index 451e5492911c..2b5ae5d9a4b6 100644
--- a/drivers/cxl/core/region.c
+++ b/drivers/cxl/core/region.c
@@ -2958,16 +2958,6 @@ static bool cxl_is_hpa_in_chunk(u64 hpa, struct cxl_region *cxlr, int pos)
 	return false;
 }
 
-static bool has_hpa_to_spa(struct cxl_root_decoder *cxlrd)
-{
-	return cxlrd->ops && cxlrd->ops->hpa_to_spa;
-}
-
-static bool has_spa_to_hpa(struct cxl_root_decoder *cxlrd)
-{
-	return cxlrd->ops && cxlrd->ops->spa_to_hpa;
-}
-
 #define CXL_POS_ZERO 0
 /**
  * cxl_validate_translation_params
@@ -3141,8 +3131,8 @@ u64 cxl_dpa_to_hpa(struct cxl_region *cxlr, const struct cxl_memdev *cxlmd,
 	hpa = hpa_offset + p->res->start + p->cache_size;
 
 	/* Root decoder translation overrides typical modulo decode */
-	if (has_hpa_to_spa(cxlrd))
-		hpa = cxlrd->ops->hpa_to_spa(cxlrd, hpa);
+	if (cxlrd->ops.hpa_to_spa)
+		hpa = cxlrd->ops.hpa_to_spa(cxlrd, hpa);
 
 	if (!cxl_resource_contains_addr(p->res, hpa)) {
 		dev_dbg(&cxlr->dev,
@@ -3151,7 +3141,7 @@ u64 cxl_dpa_to_hpa(struct cxl_region *cxlr, const struct cxl_memdev *cxlmd,
 	}
 
 	/* Simple chunk check, by pos & gran, only applies to modulo decodes */
-	if (!has_hpa_to_spa(cxlrd) && (!cxl_is_hpa_in_chunk(hpa, cxlr, pos)))
+	if (!cxlrd->ops.hpa_to_spa && !cxl_is_hpa_in_chunk(hpa, cxlr, pos))
 		return ULLONG_MAX;
 
 	return hpa;
@@ -3184,8 +3174,8 @@ static int region_offset_to_dpa_result(struct cxl_region *cxlr, u64 offset,
 	 * If the root decoder has SPA to CXL HPA callback, use it. Otherwise
 	 * CXL HPA is assumed to equal SPA.
 	 */
-	if (has_spa_to_hpa(cxlrd)) {
-		hpa = cxlrd->ops->spa_to_hpa(cxlrd, p->res->start + offset);
+	if (cxlrd->ops.spa_to_hpa) {
+		hpa = cxlrd->ops.spa_to_hpa(cxlrd, p->res->start + offset);
 		hpa_offset = hpa - p->res->start;
 	} else {
 		hpa_offset = offset;
diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
index 0481679eb109..91ff47382111 100644
--- a/drivers/cxl/cxl.h
+++ b/drivers/cxl/cxl.h
@@ -451,7 +451,7 @@ struct cxl_root_decoder {
 	void *platform_data;
 	struct mutex range_lock;
 	int qos_class;
-	struct cxl_rd_ops *ops;
+	struct cxl_rd_ops ops;
 	struct cxl_switch_decoder cxlsd;
 };
 
-- 
2.47.3

[PATCH 2/3] cxl/acpi: Group xor arithmetric setup code in a single block

[Robert Richter]

Simplify the xor arithmetric setup code by grouping it in a single
block. No need to split the block for QoS setup.

It is safe to reorder the call of cxl_setup_extended_linear_cache()
because there are no dependencies.

Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Robert Richter <rrichter@amd.com>
---
v2: spell fix in descripton (Jonathan),
---
---
 drivers/cxl/acpi.c | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c
index fab736aa77dc..50c2987e0459 100644
--- a/drivers/cxl/acpi.c
+++ b/drivers/cxl/acpi.c
@@ -465,8 +465,6 @@ static int __cxl_parse_cfmws(struct acpi_cedt_cfmws *cfmws,
 		ig = CXL_DECODER_MIN_GRANULARITY;
 	cxld->interleave_granularity = ig;
 
-	cxl_setup_extended_linear_cache(cxlrd);
-
 	if (cfmws->interleave_arithmetic == ACPI_CEDT_CFMWS_ARITHMETIC_XOR) {
 		if (ways != 1 && ways != 3) {
 			cxims_ctx = (struct cxl_cxims_context) {
@@ -482,15 +480,14 @@ static int __cxl_parse_cfmws(struct acpi_cedt_cfmws *cfmws,
 				return -EINVAL;
 			}
 		}
-	}
-
-	cxlrd->qos_class = cfmws->qtg_id;
-
-	if (cfmws->interleave_arithmetic == ACPI_CEDT_CFMWS_ARITHMETIC_XOR) {
 		cxlrd->ops.hpa_to_spa = cxl_apply_xor_maps;
 		cxlrd->ops.spa_to_hpa = cxl_apply_xor_maps;
 	}
 
+	cxl_setup_extended_linear_cache(cxlrd);
+
+	cxlrd->qos_class = cfmws->qtg_id;
+
 	rc = cxl_decoder_add(cxld);
 	if (rc)
 		return rc;
-- 
2.47.3

[PATCH 3/3] cxl/region: Remove local variable @inc in cxl_port_setup_targets()

[Robert Richter]

Simplify the code by removing local variable @inc. The variable is not
used elsewhere, remove it and directly increment the target number.

Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Robert Richter <rrichter@amd.com>
---
 drivers/cxl/core/region.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
index 2b5ae5d9a4b6..e577b11bd889 100644
--- a/drivers/cxl/core/region.c
+++ b/drivers/cxl/core/region.c
@@ -1357,7 +1357,7 @@ static int cxl_port_setup_targets(struct cxl_port *port,
 				  struct cxl_endpoint_decoder *cxled)
 {
 	struct cxl_root_decoder *cxlrd = cxlr->cxlrd;
-	int parent_iw, parent_ig, ig, iw, rc, inc = 0, pos = cxled->pos;
+	int parent_iw, parent_ig, ig, iw, rc, pos = cxled->pos;
 	struct cxl_port *parent_port = to_cxl_port(port->dev.parent);
 	struct cxl_region_ref *cxl_rr = cxl_rr_load(port, cxlr);
 	struct cxl_memdev *cxlmd = cxled_to_memdev(cxled);
@@ -1549,9 +1549,8 @@ static int cxl_port_setup_targets(struct cxl_port *port,
 		cxlsd->target[cxl_rr->nr_targets_set] = ep->dport;
 		cxlsd->cxld.target_map[cxl_rr->nr_targets_set] = ep->dport->port_id;
 	}
-	inc = 1;
+	cxl_rr->nr_targets_set++;
 out_target_set:
-	cxl_rr->nr_targets_set += inc;
 	dev_dbg(&cxlr->dev, "%s:%s target[%d] = %s for %s:%s @ %d\n",
 		dev_name(port->uport_dev), dev_name(&port->dev),
 		cxl_rr->nr_targets_set - 1, dev_name(ep->dport->dport_dev),
-- 
2.47.3

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

[Dave Jiang]

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'?

Re: [PATCH 1/3] cxl: Simplify cxl_rd_ops allocation and handling

[Gregory Price]

On Wed, Nov 12, 2025 at 09:51:02PM +0100, Robert Richter wrote:
> A root decoder's callback handlers are collected in struct cxl_rd_ops.
> The structure is dynamically allocated, though it contains only a few
> pointers in it. This also requires to check two pointes to check for
> the existance of a callback.
> 
> Simplify the allocation, release and handler check by embedding the
> ops statically in struct cxl_root_decoder.
> 
> Implementation is equivalent to how struct cxl_root_ops handles the
> callbacks.
> 
> Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>

Reviewed-by: Gregory Price <gourry@gourry.net>

Re: [PATCH 2/3] cxl/acpi: Group xor arithmetric setup code in a single block

[Gregory Price]

On Wed, Nov 12, 2025 at 09:51:03PM +0100, Robert Richter wrote:
> Simplify the xor arithmetric setup code by grouping it in a single
> block. No need to split the block for QoS setup.
> 
> It is safe to reorder the call of cxl_setup_extended_linear_cache()
> because there are no dependencies.
> 
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: Robert Richter <rrichter@amd.com>

Signed-off-by: Gregory Price <gourry@gourry.net>

Re: [PATCH 2/3] cxl/acpi: Group xor arithmetric setup code in a single block

[Gregory Price]

On Wed, Nov 12, 2025 at 05:36:55PM -0500, Gregory Price wrote:
> On Wed, Nov 12, 2025 at 09:51:03PM +0100, Robert Richter wrote:
> > Simplify the xor arithmetric setup code by grouping it in a single
> > block. No need to split the block for QoS setup.
> > 
> > It is safe to reorder the call of cxl_setup_extended_linear_cache()
> > because there are no dependencies.
> > 
> > Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> > Signed-off-by: Robert Richter <rrichter@amd.com>
> 
> Signed-off-by: Gregory Price <gourry@gourry.net>
>

Sigh, sorry, hit the wrong macro, DJ please drop this SoB

Reviewed-by: Gregory Price <gourry@gourry.net>

Re: [PATCH 3/3] cxl/region: Remove local variable @inc in cxl_port_setup_targets()

[Gregory Price]

On Wed, Nov 12, 2025 at 09:51:04PM +0100, Robert Richter wrote:
> Simplify the code by removing local variable @inc. The variable is not
> used elsewhere, remove it and directly increment the target number.
> 
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: Robert Richter <rrichter@amd.com>

Reviewed-by: Gregory Price <gourry@gourry.net>

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

[Robert Richter]

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

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

[Dave Jiang]

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?

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

[Gregory Price]

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

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

[Dave Jiang]

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

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

[Robert Richter]

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

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

[Dave Jiang]

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

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

[Robert Richter]

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

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

[Robert Richter]

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

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

[Dave Jiang]

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

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

[Robert Richter]

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

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

[Dave Jiang]

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?

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

[Dave Jiang]

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

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

[Robert Richter]

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

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

[Dave Jiang]

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

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

[Dave Jiang]

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