[PATCH AUTOSEL 7.0-6.1] memory: brcmstb_memc: Expand LPDDR4 check to cover for LPDDR5

[Sasha Levin <sashal@kernel.org>]

From: Florian Fainelli <florian.fainelli@broadcom.com>

[ Upstream commit a969a0835152984a0f556434eafdee0b84213670 ]

The same limitations that apply to LPDDR4 also apply to LPDDR5. Expand
the check and rename accordingly.

Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20260122003501.1191059-1-florian.fainelli@broadcom.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have enough information to complete the full analysis. Let me
compile my findings.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
- **Subsystem**: `memory: brcmstb_memc:` (Broadcom STB memory controller
  driver)
- **Action verb**: "Expand" (extending an existing check)
- **Summary**: Expand LPDDR4 check to also cover LPDDR5 memory types

Record: [memory/brcmstb_memc] [expand] [Extend existing LPDDR4 hardware
limitation check to also apply to LPDDR5]

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Signed-off-by**: Florian Fainelli <florian.fainelli@broadcom.com>
  (author, Broadcom employee, original driver author)
- **Link**: https://patch.msgid.link/20260122003501.1191059-1-
  florian.fainelli@broadcom.com
- **Signed-off-by**: Krzysztof Kozlowski <krzk@kernel.org> (subsystem
  maintainer who applied it)
- No Fixes: tag, no Cc: stable, no Reported-by, no Tested-by, no
  Reviewed-by

Record: Author is the original driver author (Florian Fainelli at
Broadcom). Applied by memory subsystem maintainer Krzysztof Kozlowski.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The message says: "The same limitations that apply to LPDDR4 also apply
to LPDDR5. Expand the check and rename accordingly."

The limitation in question: On LPDDR4 chips, the inactivity timeout for
Self-Refresh Power Down (SRPD) cannot be changed because the dynamic
tuning process is affected by the inactivity timeout, making it non-
functional. This same limitation applies to LPDDR5.

Without this fix, on LPDDR5 hardware, a user writing to the `srpd` sysfs
attribute would successfully change the SRPD inactivity timeout, which
would break the dynamic tuning process, making the memory controller
non-functional.

Record: [Bug: missing LPDDR5 check allows dangerous SRPD timeout
modification on LPDDR5 hardware] [Symptom: dynamic memory tuning becomes
non-functional on LPDDR5 systems] [Root cause: original code only
checked for LPDDR4, not LPDDR5]

### Step 1.4: DETECT HIDDEN BUG FIXES
This IS a real bug fix disguised as "expand." The keyword "expand" masks
the fact that without this change, LPDDR5 users can corrupt their memory
controller tuning through the sysfs interface.

Record: [Yes, this is a hidden bug fix. It prevents a user from making
the dynamic tuning process non-functional on LPDDR5 hardware.]

---

## PHASE 2: DIFF ANALYSIS - LINE BY LINE

### Step 2.1: INVENTORY THE CHANGES
- **File**: `drivers/memory/brcmstb_memc.c`
- **Lines added**: ~4 (new define, extra condition, rename)
- **Lines removed**: ~3 (old function name, old single condition)
- **Functions modified**: `brcmstb_memc_uses_lpddr4` renamed to
  `brcmstb_memc_uses_lpddr45`, `srpd_store` (caller updated)
- **Scope**: Single-file, surgical fix

Record: [1 file changed, ~4 lines added, ~3 removed] [Functions:
brcmstb_memc_uses_lpddr4→brcmstb_memc_uses_lpddr45, srpd_store] [Single-
file surgical fix]

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Hunk 1** - Define addition:
- Before: Only `CNTRLR_CONFIG_LPDDR4_SHIFT` (value 5) defined
- After: Also defines `CNTRLR_CONFIG_LPDDR5_SHIFT` (value 6)

**Hunk 2** - Function logic change:
- Before: `brcmstb_memc_uses_lpddr4()` returns true only if register
  value == 5 (LPDDR4)
- After: `brcmstb_memc_uses_lpddr45()` returns true if register value ==
  5 (LPDDR4) OR == 6 (LPDDR5)

**Hunk 3** - Caller update:
- Before: `srpd_store()` calls `brcmstb_memc_uses_lpddr4()`
- After: `srpd_store()` calls `brcmstb_memc_uses_lpddr45()`

The change affects the `srpd_store` sysfs path. When a user writes to
`/sys/.../srpd`, the check now correctly blocks the write for both
LPDDR4 and LPDDR5.

Record: [Before: LPDDR5 memory allowed dangerous SRPD timeout change.
After: LPDDR5 correctly blocked like LPDDR4.]

### Step 2.3: IDENTIFY THE BUG MECHANISM
This is a **hardware workaround/limitation enforcement** fix. Category
(h) - Hardware workarounds. The hardware has a limitation (LPDDR5
dynamic tuning breaks with SRPD timeout changes) that wasn't enforced in
software.

Record: [Hardware workaround - extending existing HW limitation check to
cover LPDDR5]

### Step 2.4: ASSESS THE FIX QUALITY
- Obviously correct: Yes. The author is the Broadcom engineer who wrote
  the driver and knows the hardware limitations.
- Minimal/surgical: Yes. Adds one define, one condition, renames a
  function.
- Regression risk: Extremely low. The only change is that LPDDR5 systems
  now return `-EOPNOTSUPP` from `srpd_store`, which is the correct
  behavior. LPDDR4 and other memory types are unaffected.

Record: [Fix is obviously correct, minimal, and low regression risk]

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
From git blame, all the relevant code was introduced by Florian Fainelli
in commit `a4be90ff7a7d2` ("memory: brcmstb_memc: Add Broadcom STB
memory controller driver"), first appearing in v6.1-rc1. The buggy code
(missing LPDDR5 check) has been present since the driver was introduced.

Record: [Buggy code introduced in a4be90ff7a7d2, merged in v6.1-rc1.
Present in all stable trees from 6.1 onward.]

### Step 3.2: FOLLOW THE FIXES TAG
No Fixes: tag present. This is expected.

### Step 3.3: CHECK FILE HISTORY
The file has had minimal changes: initial addition in v6.1, then a few
minor cleanups and build fixes. No major refactoring. The patch should
apply cleanly or with trivial adjustments to stable trees.

Record: [File has minimal history - 6 commits total. No conflicting
changes.]

### Step 3.4: CHECK THE AUTHOR
Florian Fainelli is the original author of this driver and a Broadcom
employee who is the de facto maintainer. His fix carries maximum
authority for this driver.

Record: [Author is the original driver author and de facto maintainer at
Broadcom]

### Step 3.5: CHECK FOR DEPENDENCIES
This is a standalone single-commit fix. No dependencies on other
commits.

Record: [Standalone fix, no dependencies]

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
b4 dig failed to find the commit by message-id (the commit may not be in
the local repo since we're on 7.0 and the commit isn't present in HEAD
yet). Lore is behind a challenge page. The Link tag points to `patch.msg
id.link/20260122003501.1191059-1-florian.fainelli@broadcom.com`.

Record: [Could not access lore discussion due to anti-bot protection.
The patch was accepted by maintainer Krzysztof Kozlowski.]

### Step 4.2-4.5: MAILING LIST RESEARCH
Unable to verify via lore due to access restrictions. However, the patch
was accepted by the memory subsystem maintainer with no modifications.

Record: [UNVERIFIED: Could not access mailing list discussion. Accepted
by maintainer.]

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: KEY FUNCTIONS
- `brcmstb_memc_uses_lpddr4` (renamed to `brcmstb_memc_uses_lpddr45`)
- `srpd_store` (caller)

### Step 5.2: TRACE CALLERS
`brcmstb_memc_uses_lpddr4` is called only from `srpd_store`, which is
the sysfs write handler for the `srpd` attribute. This is user-
accessible.

Record: [Called from srpd_store sysfs handler - user-triggered path]

### Step 5.3-5.4: CALL CHAIN
User writes to `/sys/devices/.../srpd` → `srpd_store()` →
`brcmstb_memc_uses_lpddr45()` reads hardware register → if LPDDR4/5,
returns -EOPNOTSUPP.

Record: [User-triggered via sysfs write. Direct path.]

### Step 5.5: SIMILAR PATTERNS
No similar patterns elsewhere - this is the only LPDDR type check in
this driver.

Record: [Unique check in this driver]

---

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?
The driver was introduced in v6.1-rc1 (commit `a4be90ff7a7d2`). It
exists in:
- 6.1.y (LTS) ✓
- 6.6.y (LTS) ✓
- 6.12.y ✓
- 7.0 ✓

Record: [Buggy code exists in all active stable trees: 6.1.y, 6.6.y,
6.12.y]

### Step 6.2: BACKPORT COMPLICATIONS
The file has had only minor changes across versions. The patch should
apply cleanly or with trivial context adjustments.

Record: [Expected clean apply across all stable trees]

### Step 6.3: RELATED FIXES ALREADY IN STABLE
No related fixes for LPDDR5 exist.

Record: [No prior fix for this issue in stable]

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: IDENTIFY SUBSYSTEM CRITICALITY
- **Subsystem**: drivers/memory - memory controller drivers
- **Criticality**: PERIPHERAL (specific Broadcom STB hardware) but the
  consequences of the bug (making dynamic tuning non-functional) are
  significant for affected users.

Record: [drivers/memory, PERIPHERAL - Broadcom STB specific, but real
hardware impact]

### Step 7.2: SUBSYSTEM ACTIVITY
Only 6 commits to this file over its entire existence (since 6.1).
Mature and stable code.

Record: [Mature, stable codebase with minimal changes]

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: WHO IS AFFECTED
Users of Broadcom STB SoCs with LPDDR5 memory. This is primarily
embedded/set-top-box devices.

Record: [Driver-specific: Broadcom STB users with LPDDR5 memory]

### Step 8.2: TRIGGER CONDITIONS
Triggered when a user (or system script) writes to the `srpd` sysfs
attribute on a system with LPDDR5 memory. On affected systems, the write
succeeds (should fail with -EOPNOTSUPP) and the SRPD configuration
change breaks the dynamic tuning process.

Record: [Triggered by sysfs write on LPDDR5 systems. Could be triggered
by power management scripts.]

### Step 8.3: FAILURE MODE SEVERITY
When triggered, the dynamic tuning process becomes "non-functional" (per
the existing code comment). This affects the memory controller's dynamic
tuning, which could lead to system instability or incorrect memory
timing. Severity: **MEDIUM-HIGH** for affected hardware.

Record: [Memory controller dynamic tuning becomes non-functional.
Severity: MEDIUM-HIGH]

### Step 8.4: RISK-BENEFIT RATIO
- **BENEFIT**: Prevents memory controller misconfiguration on LPDDR5
  Broadcom STB systems. Real hardware fix for real users.
- **RISK**: Extremely low. Only adds one additional condition to an
  existing check. The only behavioral change is that LPDDR5 systems now
  correctly return -EOPNOTSUPP on SRPD write, matching the existing
  LPDDR4 behavior.
- **Ratio**: Very favorable. Minimal risk, meaningful benefit for
  affected hardware.

Record: [High benefit for affected users, minimal risk. Very favorable
ratio.]

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**FOR backporting:**
- Fixes a real hardware limitation enforcement bug on LPDDR5 systems
- Without the fix, users can break dynamic memory tuning on LPDDR5
  Broadcom STB hardware
- Extremely small and surgical (adds 1 define, 1 condition, renames
  function)
- Written by the original driver author (Florian Fainelli at Broadcom)
- Accepted by subsystem maintainer
- Applies cleanly to stable trees (minimal file history)
- Driver exists in all active LTS trees (6.1+)
- Falls into the "hardware quirk/workaround" exception category
- Zero regression risk to existing LPDDR4 or other memory type users

**AGAINST backporting:**
- Affects only Broadcom STB users with LPDDR5 memory (narrow user base)
- No Fixes: tag, no Reported-by (but this is expected for the review
  pipeline)
- The commit message uses "expand" rather than "fix" language

### Step 9.2: STABLE RULES CHECKLIST
1. **Obviously correct and tested?** YES - single condition addition, by
   driver author
2. **Fixes a real bug?** YES - allows dangerous SRPD modification on
   LPDDR5
3. **Important issue?** MEDIUM-HIGH - memory controller misconfiguration
4. **Small and contained?** YES - ~4 lines changed in 1 file
5. **No new features or APIs?** CORRECT - only extends an existing check
6. **Can apply to stable trees?** YES - driver exists since 6.1

### Step 9.3: EXCEPTION CATEGORIES
This falls into the **hardware quirk/workaround** category - extending
an existing hardware limitation check to cover newly-recognized
hardware.

### Step 9.4: DECISION
The fix is small, surgical, obviously correct, written by the driver
author, and prevents real hardware misconfiguration on LPDDR5 Broadcom
STB systems. The risk is negligible and the benefit is real for affected
users.

---

## Verification

- [Phase 1] Parsed tags: Signed-off-by by Florian Fainelli (driver
  author), accepted by Krzysztof Kozlowski (maintainer). No
  Fixes/Reported-by tags.
- [Phase 2] Diff analysis: 1 new #define, 1 additional condition in
  existing check function, 1 function rename, 1 caller update. Total ~4
  lines changed.
- [Phase 3] git blame: All code introduced in commit a4be90ff7a7d2
  (v6.1-rc1) by same author (Florian Fainelli).
- [Phase 3] git describe --contains: confirmed driver first appeared in
  v6.1-rc1.
- [Phase 3] git log v6.1..v6.6..v6.12: confirmed driver exists in all
  active stable trees.
- [Phase 3] git log --author="Florian Fainelli": confirmed author is
  original driver author and active maintainer.
- [Phase 3] File history: only 6 commits total, minimal churn, clean
  backport expected.
- [Phase 5] Code analysis: brcmstb_memc_uses_lpddr4 called only from
  srpd_store (sysfs write handler), user-triggerable path.
- [Phase 6] Driver exists in 6.1.y, 6.6.y, 6.12.y stable trees.
- [Phase 8] Failure mode: dynamic tuning becomes non-functional on
  LPDDR5 systems. Severity MEDIUM-HIGH.
- UNVERIFIED: Could not access lore.kernel.org discussion due to anti-
  bot protection. Relied on maintainer acceptance and commit tags.

**YES**

 drivers/memory/brcmstb_memc.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/memory/brcmstb_memc.c b/drivers/memory/brcmstb_memc.c
index ba73470b1b134..c28fe90936168 100644
--- a/drivers/memory/brcmstb_memc.c
+++ b/drivers/memory/brcmstb_memc.c
@@ -14,6 +14,7 @@
 
 #define REG_MEMC_CNTRLR_CONFIG		0x00
 #define  CNTRLR_CONFIG_LPDDR4_SHIFT	5
+#define  CNTRLR_CONFIG_LPDDR5_SHIFT	6
 #define  CNTRLR_CONFIG_MASK		0xf
 #define REG_MEMC_SRPD_CFG_21		0x20
 #define REG_MEMC_SRPD_CFG_20		0x34
@@ -34,14 +35,15 @@ struct brcmstb_memc {
 	u32 srpd_offset;
 };
 
-static int brcmstb_memc_uses_lpddr4(struct brcmstb_memc *memc)
+static int brcmstb_memc_uses_lpddr45(struct brcmstb_memc *memc)
 {
 	void __iomem *config = memc->ddr_ctrl + REG_MEMC_CNTRLR_CONFIG;
 	u32 reg;
 
 	reg = readl_relaxed(config) & CNTRLR_CONFIG_MASK;
 
-	return reg == CNTRLR_CONFIG_LPDDR4_SHIFT;
+	return reg == CNTRLR_CONFIG_LPDDR4_SHIFT ||
+	       reg == CNTRLR_CONFIG_LPDDR5_SHIFT;
 }
 
 static int brcmstb_memc_srpd_config(struct brcmstb_memc *memc,
@@ -95,7 +97,7 @@ static ssize_t srpd_store(struct device *dev, struct device_attribute *attr,
 	 * dynamic tuning process will also get affected by the inactivity
 	 * timeout, thus making it non functional.
 	 */
-	if (brcmstb_memc_uses_lpddr4(memc))
+	if (brcmstb_memc_uses_lpddr45(memc))
 		return -EOPNOTSUPP;
 
 	ret = kstrtouint(buf, 10, &val);
-- 
2.53.0