[PATCH AUTOSEL 6.18-6.6] thunderbolt: Increase timeout for Configuration Ready bit

[Sasha Levin]

From: Gil Fine <gil.fine@xxxxxxxxxxxxxxx>

[ Upstream commit ba2cc385110129d03cd0f18a1b5969a430b67a18 ]

After setting the Configuration Valid bit (ROUTER_CS_5.CV), the USB4
Connection Manager guide specifies a 500 ms timeout for the router to
set the Configuration Ready bit (ROUTER_CS_6.CR). The current timeout
is shorter than specified. While there, fix the kernel-doc typo.

Increase the timeout to match the CM guide recommendation.

Signed-off-by: Gil Fine <gil.fine@xxxxxxxxxxxxxxx>
Signed-off-by: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

**Step 1.1 — Subject line**

Record: `[thunderbolt]` `[Increase]` — Increase timeout for
Configuration Ready bit after setting Configuration Valid on USB4
routers.

**Step 1.2 — Tags**

Record:
- **Fixes:** none
- **Reported-by:** none
- **Tested-by:** none
- **Reviewed-by:** none (in commit)
- **Acked-by:** none
- **Link:** none
- **Cc: stable:** none (expected for manual review)
- **Signed-off-by:** Gil Fine, Mika Westerberg (subsystem maintainer)

No syzbot, no user bug report tags.

**Step 1.3 — Body analysis**

Record:
- **Bug:** After setting `ROUTER_CS_5.CV`, the USB4 Connection Manager
  guide requires up to **500 ms** for the router to set `ROUTER_CS_6.CR`
  (Configuration Ready). The kernel waits only **50 ms**.
- **Symptom:** Premature timeout waiting for Configuration Ready;
  enumeration/tunnel setup may proceed before the router is actually
  ready.
- **Root cause:** Timeout value does not match the CM guide
  specification (present since initial USB4 support).
- **Also:** kernel-doc typo — “does nothing for the latter” should be
  “former” (host router, where `tb_route(sw)` is zero).

**Step 1.4 — Hidden bug fix?**

Record: **Yes.** Although the subject says “Increase timeout,” this is a
real correctness/timing bug, not cosmetic cleanup. The doc fix is
incidental.

---

## Phase 2: Diff Analysis

**Step 2.1 — Inventory**

Record:
- **File:** `drivers/thunderbolt/usb4.c` (+2 / −2 lines)
- **Functions:** `usb4_switch_configuration_valid()` (timeout change);
  kernel-doc for same function (typo)
- **Scope:** Single-file, surgical fix

**Step 2.2 — Code flow change**

Record:
- **Hunk 1 (doc):** “latter” → “former” — documents that the function is
  a no-op on the **host** router (`!tb_route(sw)` early return).
- **Hunk 2 (timeout):** `tb_switch_wait_for_bit(..., ROUTER_CS_6_CR,
  ..., 50)` → `..., 500)`.
- **Before:** Wait at most 50 ms for CR after writing CV.
- **After:** Wait up to 500 ms per USB4 CM guide.
- **Path:** USB4 device-router hotplug enumeration and resume restore
  (via `tb_switch_configuration_valid()`).

**Step 2.3 — Bug mechanism**

Record: **Logic / timing correctness fix.** The wait can expire at 50 ms
while hardware is still within spec (up to 500 ms).
`tb_switch_wait_for_bit()` then returns `-ETIMEDOUT`. Callers currently
ignore that return value, but the function still returns to callers only
after the (too-short) wait completes, so tunnel/retimer work may start
before CR is set.

**Step 2.4 — Fix quality**

Record:
- **Obviously correct:** Aligns with spec; other waits in the same file
  already use 500 ms (e.g. `ROUTER_CS_26` at line 79).
- **Minimal:** Two-line functional change.
- **Regression risk:** Very low — only lengthens a poll loop; worst case
  adds ~450 ms on genuine timeout paths.

---

## Phase 3: Git History Investigation

**Step 3.1 — Blame**

Record: 50 ms timeout introduced in `1639664fb74f30` (Dec 2021, “Move
usb4_switch_wait_for_bit() to switch.c”); originally in `b04079837b209`
(Dec 2019, “Add initial support for USB4”). Bug has existed since USB4
support landed.

**Step 3.2 — Fixes: tag**

Record: N/A — no Fixes: tag.

**Step 3.3 — Related file history**

Record:
- Part of upstream 5-patch series “CM fixes to follow CM guide more
  closely” (Jan 2026).
- Related upstream-only commits on same files: `062023c4364ff` (Router
  Ready wait in `usb4_switch_setup()`), `69a7b98770b7e` (PCIe adapter
  detect check).
- **This patch is standalone** — only changes CR timeout and doc; does
  not depend on RR verification or other series patches.

**Step 3.4 — Author context**

Record: Gil Fine (Intel thunderbolt contributor); committed by Mika
Westerberg (subsystem maintainer).

**Step 3.5 — Dependencies**

Record: **None required.** `ROUTER_CS_6_CR` and
`tb_switch_wait_for_bit()` exist in this tree. Patch applies cleanly
(`git apply --check` passed). `ROUTER_CS_6_RR` from patch 3/5 is **not**
in 6.18.y and is **not** needed for this change.

---

## Phase 4: Mailing List and External Research

**Step 4.1 — Original discussion**

Record:
- **b4 dig:** https://patch.msgid.link/20260126220606.3476657-5-
  gil.fine@xxxxxxxxxxxxxxx
- **Series:** v1 only (5 patches, Jan 27 2026)
- **Stable nomination:** None found in thread
- **NAKs:** None

**Step 4.2 — Reviewers**

Record: **b4 dig -w:** Mika Westerberg, Andreas Noever, Yehezkel
Shapira, linux-usb@xxxxxxxxxxxxxxx, Lukas Wunner. Mika reviewed patches
2/5 and 3/5; **no reply specifically on patch 4/5**.

**Step 4.3 — Bug reports**

Record: No Reported-by, syzbot, or bugzilla links. Spec-compliance fix
without a public user report.

**Step 4.4 — Series context**

Record: Patch 4/5 of 5; independently valuable. Other patches address
separate CM-guide gaps.

**Step 4.5 — Stable list**

Record: Not searched separately; no stable@vger discussion found in mbox
thread.

---

## Phase 5: Code Semantic Analysis

**Step 5.1 — Key functions**

Record: `usb4_switch_configuration_valid()`,
`tb_switch_configuration_valid()`, `tb_switch_wait_for_bit()`.

**Step 5.2 — Callers**

Record:
- `tb_switch_configuration_valid()` →
  `usb4_switch_configuration_valid()` for USB4 switches
  (`switch.c:2673-2677`)
- Called from `tb.c:1407` (hotplug/discovery path after TMU enable)
- Called from `tb.c:3095` (`tb_restore_children()` on resume)
- **Return value not checked** at either call site.

**Step 5.3 — Callees**

Record: `tb_sw_read()`, `tb_sw_write()`, `tb_switch_wait_for_bit()`
(poll loop with `usleep_range(50,100)`).

**Step 5.4 — Reachability**

Record: Triggered on USB4/Thunderbolt device-router hotplug and system
resume — common paths for dock/peripheral users with
`CONFIG_USB4`/`CONFIG_THUNDERBOLT`.

**Step 5.5 — Similar patterns**

Record: Other thunderbolt timeout increases in this tree use 500 ms
(`usb4.c:79`). Stable tree already contains `b6d572aeb58a5` (“Increase
DisplayPort Connection Manager handshake timeout”) — precedent for
backporting thunderbolt timing fixes.

---

## Phase 6: Cross-Reference Against Local Tree (6.18.y)

**Step 6.1 — Buggy code present?**

Record: **Yes.** Local tree is **v6.18.44** (`stable/linux-6.18.y`).
`usb4_switch_configuration_valid()` still uses **50 ms** at
`usb4.c:329-330`. Upstream fix `ba2cc38511012` is **not** an ancestor of
HEAD.

**Step 6.2 — Backport complications**

Record: **Clean apply** — `git format-patch -1 ba2cc38511012 | git apply
--check` succeeded with no conflicts.

**Step 6.3 — Related fixes already present?**

Record: No equivalent timeout change in 6.18.y. Router Ready
verification (`062023c4364ff`) is also absent — separate issue.

---

## Phase 7: Subsystem and Maintainer Context

**Step 7.1 — Subsystem**

Record: **drivers/thunderbolt** — IMPORTANT (USB4/Thunderbolt docks,
peripherals, resume).

**Step 7.2 — Activity**

Record: Actively maintained; recent stable-relevant fixes include dock
connection issues (`bd646c768a934`) and retimer enumeration timing
(`75749d2c1d8ce`).

---

## Phase 8: Impact and Risk Assessment

**Step 8.1 — Who is affected**

Record: USB4/Thunderbolt users with downstream device routers that need
>50 ms to assert Configuration Ready after Configuration Valid — docks,
hubs, chained routers.

**Step 8.2 — Trigger conditions**

Record: Device connect or resume restore on USB4 topology. Not every
router (only those slower than 50 ms). Not a security issue;
unprivileged users cannot directly trigger this register sequence.

**Step 8.3 — Failure mode severity**

Record: **MEDIUM–HIGH** — intermittent enumeration failures, tunnels not
established, peripherals/docks failing to work until replug/reboot. Not
a kernel oops, but a real functional failure on affected hardware.

**Step 8.4 — Risk vs benefit**

Record:
- **Benefit:** Prevents premature proceed-before-ready on slow-but-spec-
  compliant routers; aligns with CM guide.
- **Risk:** Very low (2-line change, longer wait only on this specific
  bit poll).
- **Ratio:** Favorable for stable.

---

## Phase 9: Final Synthesis

**Evidence FOR backport:**
- Real spec mismatch bug since USB4 support (2019/2021)
- Buggy code confirmed in v6.18.44
- Small, obviously correct, applies cleanly
- Standalone (no series dependencies)
- Maintainer-authored/committed
- Precedent: other thunderbolt timeout increases are in 6.18.y
- Can cause user-visible dock/peripheral failures

**Evidence AGAINST:**
- No explicit user bug report or syzbot report
- Callers ignore return value (mitigates crash risk but not functional
  impact)
- Part of broader CM-guide compliance series (though this hunk is
  independent)

**Stable rules checklist:**
1. Obviously correct and tested? **PASS** — spec-aligned; maintainer
   SOB; no Tested-by but change is trivial
2. Fixes a real bug? **PASS** — timeout too short vs USB4 CM guide
3. Important issue? **PASS** — functional failures on USB4 hardware
   (MEDIUM–HIGH)
4. Small and contained? **PASS** — 2 lines functional change, 1 file
5. No new features/APIs? **PASS**
6. Can apply to local tree? **PASS** — verified clean apply

**Exception category:** Hardware timing workaround / spec-compliance fix
for existing USB4 driver (similar to prior thunderbolt timeout
backports).

---

## Problem Summary for Stable Users

On v6.18.44, after marking a USB4 device router’s configuration valid,
the kernel waits only 50 ms for the Configuration Ready bit. The USB4
Connection Manager guide allows up to 500 ms. Routers that need between
50–500 ms can hit a premature timeout; enumeration then continues before
the router is ready, which can manifest as flaky or failed
Thunderbolt/USB4 dock and peripheral bring-up. The fix is a minimal
timeout increase plus a documentation typo correction.

---

## Verification

- [Phase 1] Parsed commit `ba2cc38511012`: subject, body, tags (only
  SOBs)
- [Phase 2] Read diff: 50→500 ms in `usb4_switch_configuration_valid()`,
  doc typo fix
- [Phase 2] Read `tb_switch_wait_for_bit()` at `switch.c:1720-1739`
- [Phase 3] `git blame` lines 329-330: introduced 2021, 50 ms since USB4
  bring-up
- [Phase 3] `git log -S "ROUTER_CS_6_CR, 50"`: original in
  `b04079837b209`
- [Phase 3] `git merge-base --is-ancestor b04079837b209 HEAD`: USB4 code
  in tree
- [Phase 3] `ba2cc38511012` not ancestor of HEAD: fix not yet in 6.18.44
- [Phase 4] `b4 dig -c ba2cc38511012`: lore URL found
- [Phase 4] `b4 dig -a`: v1 series, patch 4/5
- [Phase 4] `b4 dig -w`: maintainers CC’d
- [Phase 4] `b4 dig -m /tmp/tb_timeout.mbx`: no stable Cc, no NAKs, Mika
  replied on patches 2–3 only
- [Phase 5] `grep usb4_switch_configuration_valid`: callers in
  `switch.c`, `tb.c`
- [Phase 5] Read `tb.c:1407`, `tb.c:3095`: return value not checked
- [Phase 5] Read `usb4.c:311-330`: early return for host
  (`!tb_route(sw)`)
- [Phase 5] `usb4.c:79`: other 500 ms timeout precedent in same file
- [Phase 6] `git describe HEAD`: v6.18.44
- [Phase 6] `git format-patch -1 ba2cc38511012 | git apply --check`:
  clean apply
- [Phase 6] `grep ROUTER_CS_6_RR tb_regs.h`: not in 6.18.y (unrelated to
  this patch)
- [Phase 7] `git log --grep="DisplayPort Connection Manager handshake
  timeout" stable/linux-6.18.y`: precedent commit present
- [Phase 8] Assessed severity: functional USB4 enumeration failures, not
  kernel crash

**YES****Verdict: YES** — backport to this tree (v6.18.44 /
`stable/linux-6.18.y`).

The commit fixes a real USB4 timing bug: after setting Configuration
Valid, the kernel waits only **50 ms** for Configuration Ready, but the
USB4 CM guide allows **500 ms**. On slower routers, enumeration can
proceed too early and cause flaky dock/peripheral bring-up. The change
is two lines in `drivers/thunderbolt/usb4.c`, applies cleanly, is
standalone (doesn't need the other patches in the series), and matches
precedent for thunderbolt timeout fixes already in 6.18.y.

 drivers/thunderbolt/usb4.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/thunderbolt/usb4.c b/drivers/thunderbolt/usb4.c
index 276c25c7d37e6..9430bed07c468 100644
--- a/drivers/thunderbolt/usb4.c
+++ b/drivers/thunderbolt/usb4.c
@@ -304,7 +304,7 @@ int usb4_switch_setup(struct tb_switch *sw)
  * Sets configuration valid bit for the router. Must be called before
  * any tunnels can be set through the router and after
  * usb4_switch_setup() has been called. Can be called to host and device
- * routers (does nothing for the latter).
+ * routers (does nothing for the former).
  *
  * Return: %0 on success, negative errno otherwise.
  */
@@ -327,7 +327,7 @@ int usb4_switch_configuration_valid(struct tb_switch *sw)
 		return ret;
 
 	return tb_switch_wait_for_bit(sw, ROUTER_CS_6, ROUTER_CS_6_CR,
-				      ROUTER_CS_6_CR, 50);
+				      ROUTER_CS_6_CR, 500);
 }
 
 /**
-- 
2.53.0