[PATCH AUTOSEL 6.15 19/21] cxl: core/region - ignore interleave granularity when ways=1

[Sasha Levin <sashal@kernel.org>]

From: Gregory Price <gourry@gourry.net>

[ Upstream commit ce32b0c9c522e5a69ef9c62a56d6ca08fb036d67 ]

When validating decoder IW/IG when setting up regions, the granularity
is irrelevant when iw=1 - all accesses will always route to the only
target anyway - so all ig values are "correct". Loosen the requirement
that `ig = (parent_iw * parent_ig)` when iw=1.

On some Zen5 platforms, the platform BIOS specifies a 256-byte
interleave granularity window for host bridges when there is only
one target downstream.  This leads to Linux rejecting the configuration
of a region with a x2 root with two x1 hostbridges.

Decoder Programming:
   root - iw:2 ig:256
   hb1  - iw:1 ig:256  (Linux expects 512)
   hb2  - iw:1 ig:256  (Linux expects 512)
   ep1  - iw:2 ig:256
   ep2  - iw:2 ig:256

This change allows all decoders downstream of a passthrough decoder to
also be configured as passthrough (iw:1 ig:X), but still disallows
downstream decoders from applying subsequent interleaves.

e.g. in the above example if there was another decoder south of hb1
attempting to interleave 2 endpoints - Linux would enforce hb1.ig=512
because the southern decoder would have iw:2 and require ig=pig*piw.

[DJ: Fixed up against 6.15-rc1]

Signed-off-by: Gregory Price <gourry@gourry.net>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Tested-by: Li Zhijian <lizhijian@fujitsu.com>
Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Link: https://patch.msgid.link/20250402232552.999634-1-gourry@gourry.net
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

Based on my comprehensive analysis of the commit and the surrounding
codebase, here is my assessment:

**YES**

This commit should be backported to stable kernel trees. Here's my
extensive analysis:

## Nature of the Fix

This is a **bug fix** that addresses a platform compatibility issue
where valid CXL configurations are incorrectly rejected by Linux. The
fix is for a specific scenario affecting **Zen5 BIOS implementations**
that specify 256-byte interleave granularity for host bridges with
single targets.

## Technical Analysis of the Change

The commit modifies line 1449 in `drivers/cxl/core/region.c`, changing:
```c
cxld->interleave_granularity != ig ||
```
to:
```c
(iw > 1 && cxld->interleave_granularity != ig) ||
```

This change **relaxes the granularity validation** specifically when `iw
== 1` (single interleave way/passthrough decoder). The logic is sound
because:

1. **When iw=1**: All memory accesses route to the single target
   regardless of granularity, making granularity irrelevant for
   addressing
2. **When iw>1**: The granularity validation remains strict to ensure
   correct interleave routing

## Why This Qualifies for Stable Backporting

### 1. **Fixes User-Affecting Bug**
- Affects real hardware platforms (Zen5-based systems)
- Prevents legitimate CXL region configurations from working
- Users experience functional failures, not just degraded performance

### 2. **Minimal and Contained Change**
- Single line modification with clear conditional logic
- No architectural changes or new features
- Focused on a specific validation path in region setup

### 3. **Low Regression Risk**
- Only relaxes validation when it's mathematically unnecessary (iw=1)
- Maintains strict validation for interleaved configurations (iw>1)
- The change aligns with the fundamental CXL addressing principles

### 4. **Clear Stable Tree Criteria Match**
- **Important bugfix**: ✅ Enables CXL functionality on affected
  platforms
- **Minimal risk**: ✅ Highly targeted change with clear conditions
- **Contained to subsystem**: ✅ Only affects CXL region validation logic

## Evidence from Similar Commits

Looking at the historical examples:
- **Similar Commit #2** was marked "YES" and had `Cc:
  <stable@vger.kernel.org>` for a related granularity calculation fix
- The current commit follows the same pattern: targeted fix for
  granularity validation issues
- No architectural changes or new feature introductions

## Platform Impact Assessment

The commit specifically mentions **Zen5 platforms** where BIOS specifies
problematic configurations that should be valid but are currently
rejected. This affects:
- Real shipping hardware
- Valid CXL memory configurations
- System functionality rather than optimization

## Code Quality and Safety

The fix:
- Preserves existing validation for interleaved cases (iw > 1)
- Only bypasses granularity checks when they're logically unnecessary
  (iw = 1)
- Includes comprehensive review signatures from CXL subsystem
  maintainers
- Has been tested according to the commit message

The change is mathematically correct: when there's only one target
(iw=1), granularity is irrelevant because all addresses map to the same
target regardless of the granularity value.

Therefore, this commit represents a **low-risk, high-value bugfix** that
enables proper CXL functionality on affected hardware platforms and
should be backported to stable trees to ensure users don't encounter
functional regressions on valid hardware configurations.

 drivers/cxl/core/region.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
index 24b161c7749f9..7585f0302f3a2 100644
--- a/drivers/cxl/core/region.c
+++ b/drivers/cxl/core/region.c
@@ -1446,7 +1446,7 @@ static int cxl_port_setup_targets(struct cxl_port *port,
 
 	if (test_bit(CXL_REGION_F_AUTO, &cxlr->flags)) {
 		if (cxld->interleave_ways != iw ||
-		    cxld->interleave_granularity != ig ||
+		    (iw > 1 && cxld->interleave_granularity != ig) ||
 		    !region_res_match_cxl_range(p, &cxld->hpa_range) ||
 		    ((cxld->flags & CXL_DECODER_F_ENABLE) == 0)) {
 			dev_err(&cxlr->dev,
-- 
2.39.5