[PATCH AUTOSEL 7.0] i3c: mipi-i3c-hci-pci: Add support for Intel Nova Lake-H I3C

[PATCH AUTOSEL 7.0] i3c: mipi-i3c-hci-pci: Add support for Intel Nova Lake-H I3C

[Sasha Levin]

From: Adrian Hunter <adrian.hunter@intel.com>

[ Upstream commit eaa1d092a4f304415b867b7b74ed74b8f8722b0b ]

Add I3C controller PCI IDs for Intel Nova Lake-H.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260309075045.52344-1-adrian.hunter@intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have a complete picture. Let me write the analysis.

## Analysis

### PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject line parsing**
Record: [i3c/mipi-i3c-hci-pci] [Add] [PCI IDs for Intel Nova Lake-H I3C
controller support]

**Step 1.2: Commit message tags**
Record:
- Signed-off-by: Adrian Hunter (Intel)
- Reviewed-by: Frank Li (NXP) — i3c subsystem reviewer
- Link: patch.msgid.link (lore patch URL)
- Signed-off-by: Alexandre Belloni — the I3C maintainer committed
- No Fixes:, no Cc: stable — expected
- No syzbot / no sanitizer tags

**Step 1.3: Commit body analysis**
Record: Message literally says "Add I3C controller PCI IDs for Intel
Nova Lake-H". No bug description, no failure mode — this is pure
hardware enablement, adding 2 PCI IDs to an existing driver's
`pci_device_id` table.

**Step 1.4: Hidden bug fix detection**
Record: Not a hidden bug fix. The verb is "Add" and the action is
strictly extending the device table. No error-path, locking, refcount,
init, or safety-check changes.

### PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
Record: 1 file changed (`drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci-
pci.c`), +3/-0 lines. Single hunk in the `mipi_i3c_hci_pci_devices[]`
table. No function body modified.

**Step 2.2: Code flow change**
Record:
- Before: The PCI ID table terminates after `Nova Lake-S` entries.
- After: Two additional entries appear before the `{ },` sentinel:
  - `0xd37c → intel_mi_1_info`
  - `0xd36f → intel_mi_2_info`
These IDs reuse existing `intel_mi_1_info`/`intel_mi_2_info` structs
(already used for Nova Lake-S), so no new code paths.

**Step 2.3: Bug mechanism**
Record: No bug mechanism — hardware workaround / device-ID-addition
category (exception (1) from the rubric).

**Step 2.4: Fix quality**
Record: Obviously correct. Pure data addition, reusing existing `info`
objects already validated by Nova Lake-S (same MI-class silicon). Cannot
introduce a regression on any platform without the matching PCI IDs.
Zero regression risk.

### PHASE 3: GIT HISTORY

**Step 3.1: Blame context**
Record: The device table lives in a file introduced in v6.14 (commit
`30bb1ce712156`). Recent siblings in the table added the same way:
- `d515503f3c8a8` Wildcat Lake-U (merged v6.18)
- `ddb37d5b130e1` Nova Lake-S (merged v6.19)

**Step 3.2: Fixes: tag**
Record: N/A — no Fixes tag (not a bug fix).

**Step 3.3: Related file history**
Record: File has steady PCI-ID additions per Intel platform generation.
Pattern is well established and each one is a standalone commit. No
prerequisite commits are needed for this entry — `intel_mi_1_info` and
`intel_mi_2_info` are both already present in mainline.

**Step 3.4: Author context**
Record: Adrian Hunter (Intel) is an established contributor to this
driver and submitted many previous platform-enablement additions
(runtime PM, system suspend, LTR, Nova Lake-S submission chain, etc.).
Maintainer Alexandre Belloni signed off.

**Step 3.5: Prerequisites**
Record: Requires `intel_mi_1_info` and `intel_mi_2_info` symbols. Both
exist since `540a55a5bafd0` ("Define Multi-Bus instances for supported
controllers"), in v7.0. Therefore the patch applies cleanly to 7.0.y.
Older stable trees (≤6.19.y) only define `intel_info` and would require
adaptation (but Nova Lake-S was already backported to 6.19.y using
`&intel_info`).

### PHASE 4: MAILING LIST / EXTERNAL

**Step 4.1–4.5: Lore discussion**
Record: Patch committed with Frank Li's Reviewed-by. Maintainer applied
it to i3c tree. Fetching the msgid mirror (patch.msgid.link) is blocked
by anti-bot challenge, and `b4 dig` isn't required given the small,
trivial diff. No public NAKs or stable nomination in the commit message.
UNVERIFIED: detailed thread content (blocked by Anubis). The patch
subject, reviewer, and single-series character (not part of a multi-
patch series) are clear from the commit metadata.

### PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1–5.5**
Record: No functions modified. The only consumer is the PCI core's
device-ID matching; adding a new entry can only cause the driver to bind
to a new vendor/device tuple. `intel_mi_1_info`/`intel_mi_2_info` are
static-storage structs already initialized and used by at least Nova
Lake-S entries, so impact surface is limited to systems containing
VID:DID `8086:d37c` or `8086:d36f`. On all other systems the new entries
are inert.

### PHASE 6: CROSS-REFERENCING / STABLE

**Step 6.1: Code in stable**
Record: Driver exists in 6.14+. Stable branches currently maintained:
6.17.y (EOL soon), 6.18.y, 6.19.y, 7.0.y. The PCI ID table exists in all
of them.

**Step 6.2: Backport complications**
Record:
- 7.0.y: Clean apply (multi-bus `intel_mi_1/mi_2_info` structs already
  exist in 7.0).
- 6.19.y: Needs trivial adaptation — replace the `info` references with
  `&intel_info` (as was done when Nova Lake-S was backported there;
  verified v6.19.13 has `Nova Lake-S` entries pointing at
  `&intel_info`).
- 6.18.y and older: Similar simple adaptation using `&intel_info`. Note,
  Nova Lake-S was NOT backported to 6.18.y (verified v6.18.23 has only
  Wildcat Lake-U + Panther Lake), so this change may be considered too
  new for 6.18.y at this time; the AUTOSEL/stable maintainer can decide.

**Step 6.3: Existing stable fixes**
Record: Precedent exists — Nova Lake-S (ddb37d5b130e1) was backported to
6.19.y, confirming PCI-ID additions for this driver go to stable when
the driver is present.

### PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1: Subsystem**
Record: `drivers/i3c/master/mipi-i3c-hci/` — MIPI I3C Host Controller
for Intel LPSS. Criticality: PERIPHERAL from a user-population
standpoint, but important for specific Intel client platform users
(sensors, power-delivery ICs, etc. are often on I3C on modern Intel
laptops/desktops).

**Step 7.2: Activity**
Record: Very active (many recent fixes and platform additions). This is
a well-maintained hot area.

### PHASE 8: IMPACT/RISK

**Step 8.1: Who is affected**
Record: Users with Intel Nova Lake-H platforms. Without the patch: I3C
peripheral devices on Nova Lake-H don't bind to this driver. With the
patch: they do.

**Step 8.2: Trigger**
Record: Runs on first PCI probe when matching VID/DID are present. Only
activates on Nova Lake-H hardware.

**Step 8.3: Failure mode (without patch)**
Record: I3C controller not probed → I3C devices unavailable on that
platform. Severity: MEDIUM (functional/enablement limitation, not a
crash or data corruption). Regression risk from adding the IDs:
effectively zero.

**Step 8.4: Risk/benefit**
Record: BENEFIT = hardware enablement for a new platform. RISK = near
zero (3-line data-only patch reusing validated info structs). Classic
positive-ratio stable candidate.

### PHASE 9: SYNTHESIS

**Evidence FOR:**
- Falls squarely into the stable-rules exception category for new device
  IDs in existing drivers.
- 3 lines, pure data, zero logic change.
- Reused `info` structures already in use for Nova Lake-S — same silicon
  family.
- Precedent: sibling commit (Nova Lake-S) was backported to 6.19.y.
- Reviewed by established i3c reviewer; applied by maintainer.

**Evidence AGAINST:**
- Not a bug fix in the traditional sense; no CVE, no crash. But the
  stable rules explicitly permit device-ID additions.
- For pre-7.0 stable trees, a trivial rewrite is needed (swap to
  `&intel_info`). For 7.0.y it's a clean apply.

**Stable rules checklist:**
1. Obviously correct and tested — yes (data-only, matches Nova Lake-S
   pattern)
2. Fixes a real issue affecting users — yes, enables hardware on Nova
   Lake-H
3. Important issue — hardware enablement (exception category)
4. Small and contained — yes (3 lines, one file)
5. No new features/APIs — correct; no new API surface
6. Applies to stable — clean to 7.0.y; trivial adaptation for older

**Exception category:** YES — new PCI device IDs added to an existing,
already-in-stable driver.

### Verification

- [Phase 1] Read full commit message from user query; tags enumerated;
  no syzbot/Fixes.
- [Phase 2] `Read` of `drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci-
  pci.c` at HEAD — confirmed the 3-line addition reuses
  `intel_mi_1_info` and `intel_mi_2_info` already defined in the file
  (lines 185–210).
- [Phase 3] `git log --oneline -20 --
  drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci-pci.c` — verified
  platform-addition pattern (Wildcat Lake-U, Nova Lake-S precedents).
- [Phase 3] `git show ddb37d5b130e1 --stat` — verified Nova Lake-S was a
  3-line PCI-ID addition by the same author/maintainer path, `Reviewed-
  by: Frank Li`.
- [Phase 3] `git describe --contains ddb37d5b130e1` →
  `v6.19-rc1~57^2~23` — Nova Lake-S landed in v6.19.
- [Phase 3] `git describe --contains 30bb1ce712156` → `v6.14-rc1~98^2~7`
  — driver is in stable from v6.14 onward.
- [Phase 4] `WebFetch https://patch.msgid.link/20260309075045.52344-1-
  adrian.hunter@intel.com` — blocked by Anubis; thread content
  UNVERIFIED. Commit metadata (Reviewed-by, subsystem maintainer SoB) is
  sufficient signal.
- [Phase 5] Read `mipi_i3c_hci_pci_devices[]` table in full (lines
  327–341 of current file) — confirmed existing entries use the same
  `intel_mi_1_info` / `intel_mi_2_info` objects the new entries
  reference.
- [Phase 6] `git show
  v6.19.13:drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci-pci.c` —
  confirmed Nova Lake-S entries are present in 6.19.y stable, using
  `&intel_info` (simpler structure).
- [Phase 6] `git show
  v6.18.23:drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci-pci.c` —
  confirmed 6.18.y does NOT have Nova Lake-S; this file is more
  divergent there, so backport to 6.18.y would be an editorial call.
- [Phase 6] `git show v7.0:drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci-
  pci.c` — confirmed 7.0 has
  `intel_mi_1_info`/`intel_mi_2_info`/`intel_si_2_info`, so patch
  applies cleanly to 7.0.y.
- [Phase 6] `git rev-list --count eaa1d092a4f30 ^v7.0` = 3 — the
  mainline commit is 3 commits past v7.0.
- [Phase 8] Confirmed only behavioral change is PCI binding of the new
  VID:DID tuples; no runtime impact on any other system.
- UNVERIFIED: Lore thread contents (Anubis-blocked); whether the
  submitter/maintainer explicitly requested stable inclusion. This does
  not affect the technical assessment given the clear exception
  category.

### Conclusion

This is a textbook "new PCI device IDs for an existing, already-shipping
driver" change. It matches the stable-rules exception exactly, is a
3-line data-only addition that reuses objects already validated by the
sibling Nova Lake-S entries, and has direct backport precedent (Nova
Lake-S) in 6.19.y. Risk is effectively zero; benefit is hardware
enablement for users on stable trees who deploy Nova Lake-H systems.

**YES**

 drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci-pci.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci-pci.c b/drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci-pci.c
index 30302e4d08e2a..22a5ba4ad7460 100644
--- a/drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci-pci.c
+++ b/drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci-pci.c
@@ -337,6 +337,9 @@ static const struct pci_device_id mipi_i3c_hci_pci_devices[] = {
 	/* Nova Lake-S */
 	{ PCI_VDEVICE(INTEL, 0x6e2c), (kernel_ulong_t)&intel_mi_1_info},
 	{ PCI_VDEVICE(INTEL, 0x6e2d), (kernel_ulong_t)&intel_mi_2_info},
+	/* Nova Lake-H */
+	{ PCI_VDEVICE(INTEL, 0xd37c), (kernel_ulong_t)&intel_mi_1_info},
+	{ PCI_VDEVICE(INTEL, 0xd36f), (kernel_ulong_t)&intel_mi_2_info},
 	{ },
 };
 MODULE_DEVICE_TABLE(pci, mipi_i3c_hci_pci_devices);
-- 
2.53.0


-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

[PATCH AUTOSEL 7.0-6.1] i3c: master: Move bus_init error suppression

[Sasha Levin]

From: Jorge Marques <jorge.marques@analog.com>

[ Upstream commit 49775afa983e3e5ce8e7d00ee241791073be214d ]

Prepare to fix improper Mx positive error propagation in later commits
by handling Mx error codes where the i3c_ccc_cmd command is allocated.
The CCC DISEC to broadcast address is invoked with
i3c_master_enec_disec_locked() and yields error I3C_ERROR_M2 if there
are no devices active on the bus. This is expected at the bus
initialization stage, where it is not known yet that there are no active
devices on the bus. Add bool suppress_m2 argument to
i3c_master_enec_disec_locked() and update the call site at
i3c_master_bus_init() with the exact corner case to not require
propagating positive Mx error codes. Other call site should not suppress
the error code, for example, if a driver requests to peripheral to
disable events and the transfer is not acknowledged, this is an error
and should not proceed.

Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Jorge Marques <jorge.marques@analog.com>
Link: https://patch.msgid.link/20260323-ad4062-positive-error-fix-v3-3-30bdc68004be@analog.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

I now have sufficient information. Let me write the complete analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Parse subject line**
Record: Subsystem `i3c: master:`, action verb `Move` (refactoring),
summary: Move bus_init error suppression for DISEC M2 errors.

**Step 1.2: Parse tags**
Record:
- Reviewed-by: Frank Li <Frank.Li@nxp.com>
- Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
- Signed-off-by: Jorge Marques <jorge.marques@analog.com>
- Link: patch.msgid.link/20260323-ad4062-positive-error-fix-v3-3
- Signed-off-by: Alexandre Belloni (maintainer)
- **No Reported-by, no Fixes:, no Cc: stable**

**Step 1.3: Commit body analysis**
Record: Body explicitly states "Prepare to fix improper Mx positive
error propagation in later commits". Describes adding `suppress_m2`
argument to `i3c_master_enec_disec_locked()` so callers don't need to
handle positive Mx codes. No stack traces, no crash description, no
user-visible symptom described. This is author-declared preparation for
a future fix.

**Step 1.4: Hidden bug fixes**
Record: NOT a hidden bug fix - the author explicitly says "Prepare to
fix ... in later commits". Functionally this is a no-op: M2 was
suppressed via `ret != I3C_ERROR_M2` at callsite before, now via
`suppress_m2=true` inside the helper.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
Record: Single file `drivers/i3c/master.c`, 15 insertions / 8 deletions.
Modifies static helper `i3c_master_enec_disec_locked()` signature,
updates 2 static wrappers (`i3c_master_disec_locked`,
`i3c_master_enec_locked`), updates one callsite in
`i3c_master_bus_init()`.

**Step 2.2: Code flow**
Record:
- Before: `i3c_master_bus_init` called `i3c_master_disec_locked` then
  checked `if (ret && ret != I3C_ERROR_M2) goto err`.
- After: `i3c_master_bus_init` calls `i3c_master_enec_disec_locked`
  directly with `suppress_m2=true`; the helper returns 0 when cmd.err ==
  I3C_ERROR_M2; callsite just checks `if (ret) goto err`.
- Net behavior: Functionally identical under the current state of
  `i3c_master_send_ccc_cmd_locked()`.

**Step 2.3: Bug mechanism**
Record: None — this is (h) refactoring moving logic from callsite to
callee. No bug class fixed by this commit alone.

**Step 2.4: Quality**
Record: Small, surgical, reviewed by two maintainers. Risk: low. But by
itself offers no functional benefit — it only matters in conjunction
with patch 4/5 that stops propagating cmd->err.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
Record: `i3c_master_enec_disec_locked()` has been the implementation of
the DISEC helper since the i3c subsystem was introduced in commit
3a379bbcea0a ("i3c: Add core I3C infrastructure"), which is v4.17.

**Step 3.2: Fixes tag**
Record: No Fixes: tag on this commit. The related fix commit in the
series (ef8b5229348f0 "i3c: master: Fix error codes at send_ccc_cmd")
has `Fixes: 3a379bbcea0a` — pointing to the initial i3c commit.

**Step 3.3: File history**
Record: This commit is part of a 5-patch series (v3):
- 1/5 `19a1b61fa6237` "Move rstdaa error suppression" (prep)
- 2/5 `42247fffb3044` "Move entdaa error suppression" (prep)
- **3/5 `49775afa983e3` "Move bus_init error suppression" (THIS COMMIT,
  prep)**
- 4/5 `ef8b5229348f0` "Fix error codes at send_ccc_cmd" (the actual fix)
- 5/5 `0b73da96b6eb6` "adi: Fix error propagation for CCCs" (adi-
  specific follow-up)

The fix commit 4/5 explicitly names this commit as a prerequisite in its
message: "The prerequisite patches for the fix are: ... i3c: master:
Move bus_init error suppression".

**Step 3.4: Author's work**
Record: Jorge Marques (Analog Devices) is contributor of the
adi-i3c-master driver; not the i3c core maintainer. Alexandre Belloni is
the i3c maintainer (provided final SOB). The series was reviewed by
Frank Li (NXP, active i3c reviewer) and Adrian Hunter (Intel).

**Step 3.5: Dependencies**
Record: This commit is a prerequisite for commit 4/5 of the same series.
Without all three prep commits (1/5, 2/5, 3/5), commit 4/5 causes a
regression.

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1: Original submission**
Record: `b4 dig -c 49775afa983e3` found original submission at
https://patch.msgid.link/20260323-ad4062-positive-error-
fix-v3-3-30bdc68004be@analog.com. Patch is the final v3 of 3 revisions
(v1 → v2 → v3). Cover letter explains the series was triggered by a
**Smatch warning on iio/adc/ad4062.c**, not a user-reported runtime
crash.

**Step 4.2: Reviewers**
Record: Recipients = Alexandre Belloni (maintainer), Frank Li (NXP
reviewer), Przemysław Gaj (Cadence). CC: linux-i3c, Dan Carpenter
(Smatch reporter), Jonathan Cameron, Adrian Hunter. Both Reviewed-by
tags (Frank Li, Adrian Hunter) are from credible reviewers.

**Step 4.3: Bug report**
Record: Closes link in the fix commit (patch 4/5) points to
https://lore.kernel.org/linux-iio/aYXvT5FW0hXQwhm_@stanley.mountain/ —
Dan Carpenter's Smatch report. No user-reported crashes, no syzbot, no
KASAN/KMSAN/KCSAN report. The bug is static-analysis-detected API
correctness.

**Step 4.4: Related patches**
Record: Confirmed as part of 5-patch series. Patches 1/5, 2/5, 3/5 are
preparation; patches 4/5, 5/5 are the actual fixes. No Cc: stable in any
version.

**Step 4.5: Stable mailing list**
Record: No stable-specific discussion found in the thread. No reviewer
suggested Cc: stable.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions**
Record: `i3c_master_enec_disec_locked()` (static, signature change),
`i3c_master_disec_locked()` (exported wrapper),
`i3c_master_enec_locked()` (exported wrapper), `i3c_master_bus_init()`
(caller updated).

**Step 5.2: Callers**
Record: `i3c_master_bus_init()` is called from `i3c_master_register()`
during driver probe (common hardware init path).
`i3c_master_disec_locked()`/`i3c_master_enec_locked()` are exported and
called from controller drivers (dw, svc, cdns, mipi-hci, renesas, adi)
for enable/disable ibi operations.

**Step 5.3: Callees**
Record: `i3c_master_send_ccc_cmd_locked()` delegates to
`master->ops->send_ccc_cmd()`. In the current stable pre-fix state, it
still returns positive Mx codes; after the series' patch 4/5, it returns
0/negative only.

**Step 5.4: Reachability**
Record: Bus init path is reachable at every I3C master device probe —
runs on every boot/init with I3C hardware.

**Step 5.5: Similar patterns**
Record: Two sibling preparation commits (1/5 rstdaa, 2/5 entdaa) follow
identical pattern of moving M2 suppression into helper functions.

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

**Step 6.1: Code exists in stable?**
Record: The `i3c_master_enec_disec_locked()` helper and its M2-handling
call site in `i3c_master_bus_init()` exist essentially unchanged since
v4.17. The buggy M2-propagation pattern exists in every active stable
tree.

**Step 6.2: Backport difficulty**
Record: Would apply with minor conflicts to older stables due to
unrelated churn in bus_init.

**Step 6.3: Related fixes in stable**
Record: **Critical observation** — in the stable candidate branch under
evaluation, the series' fix commit (patch 4/5) is present but this
preparation commit (3/5) and the other two preparation commits (1/5,
2/5) are NOT. I verified `i3c_master_bus_init()` in the stable branch
state still has `if (ret && ret != I3C_ERROR_M2)` at the DISEC callsite.
Because the fix 4/5 stops `i3c_master_send_ccc_cmd_locked()` from
returning positive M2, the driver's underlying `-EIO`/`-ETIMEDOUT` now
propagates. That value `!= I3C_ERROR_M2`, so the check fails and
bus_init aborts when no I3C device acks DISEC — this is exactly the "no
active devices on the bus" case that M2 is meant to indicate. This is a
**real regression** that the prep commits prevent.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: Subsystem**
Record: `drivers/i3c/` — I3C bus subsystem. Criticality: PERIPHERAL
(affects systems with I3C hardware only, a relatively niche but growing
bus), but on those systems bus_init is mandatory so impact is 100% of
affected users.

**Step 7.2: Activity**
Record: Active subsystem, moderate churn, new controller drivers being
added.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected users**
Record: Any stable system running an I3C controller driver. Bus init
runs on every probe.

**Step 8.2: Trigger conditions**
Record: This commit alone has no trigger (no behavior change). The
scenario it addresses: bus_init when no active I3C device acknowledges
DISEC broadcast. Very common during early boot of I3C controllers where
devices may be powered off or absent.

**Step 8.3: Failure mode**
Record: In isolation, this commit changes nothing. When taken together
with patch 4/5 (the actual fix), its absence causes bus_init to fail and
the I3C controller to fail to probe. Severity in that combined scenario:
HIGH (boot-time probe failure).

**Step 8.4: Risk-benefit**
Record:
- Standalone benefit: zero (no bug fixed by itself).
- Series-level benefit: Prevents a regression in the fix-for-stable.
  Without it, the fix breaks bus_init.
- Risk: very low (15/8 lines, static helper, functionally equivalent to
  prior code).

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence**
FOR backporting:
- It is an explicit, author-named prerequisite for patch 4/5 ("i3c:
  master: Fix error codes at send_ccc_cmd"), which is itself a real bug
  fix (Smatch-reported, Fixes: the initial i3c core commit, affects an
  exported API contract).
- Without this commit, applying patch 4/5 to stable causes a regression
  at bus_init (verified by inspecting `i3c_master_bus_init()` in the
  stable branch state — the `ret != I3C_ERROR_M2` check still present,
  but `ret` will no longer ever be positive I3C_ERROR_M2, so the check
  always fails into error path).
- Small, contained (23 lines in one file), reviewed by two i3c reviewers
  including Adrian Hunter.
- Touches only a static helper and a single callsite; risk is minimal.

AGAINST backporting:
- By its own commit message, it is explicitly a preparation/refactor
  that "prepares to fix in later commits", with no standalone bug fix —
  a canonical STRONG NO signal per the guidelines.
- No Cc: stable, no Reported-by, no Fixes: tag on this commit itself.
- If autosel selects this but not patch 4/5, it provides zero benefit
  (pure refactoring in stable).
- The original bug's severity is medium (API-contract correctness,
  Smatch-found, no user runtime report).

**Step 9.2: Stable rules checklist**
1. Obviously correct and tested: YES (reviewed, minor refactor,
   mainline-tested)
2. Fixes a real bug: NO on its own. YES only transitively as prereq to
   4/5.
3. Important issue: NO standalone. Medium in series.
4. Small and contained: YES (single file, ~23 lines)
5. No new features/APIs: YES (static helper signature only)
6. Applies cleanly: YES with minor context adjustments

**Step 9.3: Exception categories**
Record: None apply — not a device ID, quirk, DT, build fix, or doc fix.

**Step 9.4: Decision**
This is a genuinely borderline "patch 3/5 is a preparation commit" case.
The strict reading of stable rules marks preparation commits as STRONG
NO. However, the guidelines also explicitly call out incomplete fix
series as borderline cases requiring dependency analysis. My
verification shows:

1. Patch 4/5 of the series is the actual bug fix targeting a real (if
   medium-severity) API-contract bug that has existed since i3c was
   introduced.
2. Patch 4/5 **cannot be backported safely without this prerequisite** —
   I verified the resulting bus_init code would regress (driver-returned
   `-EIO` falls into the error path when the old code relied on positive
   M2 propagation to take the "no devices" happy path).
3. The cost of including this prep commit is negligible (pure refactor,
   reviewed, small scope).
4. The cost of excluding it, if patch 4/5 is selected, is a boot/probe
   regression for I3C-enabled systems.

Given the clear transitive value (preventing a regression in an
accompanying fix) and the minimal risk profile, this should travel with
its fix series rather than be evaluated in isolation.

---

## Verification

- [Phase 1] Parsed tags from commit message: two Reviewed-by (Frank Li
  NXP, Adrian Hunter Intel), two SOB (author + maintainer Belloni), Link
  to lore/patch.msgid. No Fixes:, no Cc: stable, no Reported-by.
- [Phase 1] Commit body explicitly states "Prepare to fix improper Mx
  positive error propagation in later commits" — author-declared
  preparation.
- [Phase 2] Diff inventory: single file, 15+/8-, modifies one static
  helper + 2 static wrappers + 1 callsite. Confirmed functional
  equivalence under current `i3c_master_send_ccc_cmd_locked()` behavior.
- [Phase 3] `git log --oneline -- drivers/i3c/master.c` confirmed
  recent-file history; this commit is not yet visible via HEAD's
  reachable history (only in bus-next).
- [Phase 3] `git branch --contains 49775afa983e3` → `bus-next`; same for
  patches 1/5 and 2/5. `git branch --contains 18db53793d787` → `for-
  greg/7.0-100` (stable candidate branch) — the fix is being prepared
  for stable but the prereqs are NOT in that branch.
- [Phase 3] `git show ef8b5229348f0` confirmed the fix commit explicitly
  names this commit in the prerequisite list inside its body.
- [Phase 4] `b4 dig -c 49775afa983e3` returned the lore URL
  https://patch.msgid.link/20260323-ad4062-positive-error-
  fix-v3-3-30bdc68004be@analog.com.
- [Phase 4] `b4 dig -c 49775afa983e3 -a` showed three series revisions
  (v1 → v2 → v3); the applied version is the latest.
- [Phase 4] `b4 dig -c 49775afa983e3 -m` saved thread; read cover letter
  — series was triggered by Dan Carpenter's Smatch warning on
  iio/adc/ad4062; no Cc: stable requested by author or reviewers.
- [Phase 4] Grepped mbox for `stable@|Cc:.*stable` — no hits related to
  stable nomination.
- [Phase 5] Confirmed by reading the file:
  `i3c_master_enec_disec_locked` is static and only invoked via
  `i3c_master_disec_locked`/`i3c_master_enec_locked`.
- [Phase 6] `git show 18db53793d787:drivers/i3c/master.c` confirmed
  bus_init in the stable-candidate branch still contains `if (ret && ret
  != I3C_ERROR_M2)` at the DISEC call — verifies the regression scenario
  if prereq is omitted.
- [Phase 6] Cross-referenced series cover letter: controllers return
  `-EIO`/`-EINVAL` on M2 NACK — confirms regression path.
- [Phase 8] Severity assessment based on verified dependency: HIGH (boot
  probe failure) if fix 4/5 goes without this; zero impact in isolation.
- UNVERIFIED: Could not fetch the lore thread directly over HTTP (Anubis
  bot-challenge blocked WebFetch), but b4 dig retrieved the full mbox
  for analysis instead.
- UNVERIFIED: Did not test backport apply to specific stable kernels
  (6.1, 6.6, 6.12) — stated "minor conflicts" based on file churn
  observation only.

---

This commit is explicitly a preparation/refactor with no standalone bug
fix — the canonical "STRONG NO" pattern in stable rules. However, it is
a **named, documented prerequisite** for a bug-fix commit in the same
5-patch series, and I have verified that applying that fix without this
preparation would cause a real regression at I3C bus init (a common
boot-path code path). Stable sanity demands the series travels as a unit
or not at all.

**YES**

 drivers/i3c/master.c | 23 +++++++++++++++--------
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index 9e6be49bebb2c..b91dc1e734ed8 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -1051,7 +1051,8 @@ int i3c_master_entdaa_locked(struct i3c_master_controller *master)
 EXPORT_SYMBOL_GPL(i3c_master_entdaa_locked);
 
 static int i3c_master_enec_disec_locked(struct i3c_master_controller *master,
-					u8 addr, bool enable, u8 evts)
+					u8 addr, bool enable, u8 evts,
+					bool suppress_m2)
 {
 	struct i3c_ccc_events *events;
 	struct i3c_ccc_cmd_dest dest;
@@ -1071,6 +1072,9 @@ static int i3c_master_enec_disec_locked(struct i3c_master_controller *master,
 	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
 	i3c_ccc_cmd_dest_cleanup(&dest);
 
+	if (suppress_m2 && ret && cmd.err == I3C_ERROR_M2)
+		ret = 0;
+
 	return ret;
 }
 
@@ -1091,7 +1095,7 @@ static int i3c_master_enec_disec_locked(struct i3c_master_controller *master,
 int i3c_master_disec_locked(struct i3c_master_controller *master, u8 addr,
 			    u8 evts)
 {
-	return i3c_master_enec_disec_locked(master, addr, false, evts);
+	return i3c_master_enec_disec_locked(master, addr, false, evts, false);
 }
 EXPORT_SYMBOL_GPL(i3c_master_disec_locked);
 
@@ -1112,7 +1116,7 @@ EXPORT_SYMBOL_GPL(i3c_master_disec_locked);
 int i3c_master_enec_locked(struct i3c_master_controller *master, u8 addr,
 			   u8 evts)
 {
-	return i3c_master_enec_disec_locked(master, addr, true, evts);
+	return i3c_master_enec_disec_locked(master, addr, true, evts, false);
 }
 EXPORT_SYMBOL_GPL(i3c_master_enec_locked);
 
@@ -2102,11 +2106,14 @@ static int i3c_master_bus_init(struct i3c_master_controller *master)
 			goto err_bus_cleanup;
 	}
 
-	/* Disable all slave events before starting DAA. */
-	ret = i3c_master_disec_locked(master, I3C_BROADCAST_ADDR,
-				      I3C_CCC_EVENT_SIR | I3C_CCC_EVENT_MR |
-				      I3C_CCC_EVENT_HJ);
-	if (ret && ret != I3C_ERROR_M2)
+	/*
+	 * Disable all slave events before starting DAA. When no active device
+	 * is on the bus, returns Mx error code M2, this error is ignored.
+	 */
+	ret = i3c_master_enec_disec_locked(master, I3C_BROADCAST_ADDR, false,
+					   I3C_CCC_EVENT_SIR | I3C_CCC_EVENT_MR |
+					   I3C_CCC_EVENT_HJ, true);
+	if (ret)
 		goto err_bus_cleanup;
 
 	/*
-- 
2.53.0


-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c