[bong-water-water-bong]

The two halves of engine#823 need different things awake, and the shipped rule covers one of them. Docs-only; the mechanism is already merged and this records
what a plug test can and cannot conclude.

Measured on the board, 2026-11-10, BIOS 1.10, rule not installed

0000:c5:00.4  0x1587  xhci_hcd     D3cold   <- the rule matches this
0000:c7:00.0  0x1588  xhci_hcd     D0       <- the rule matches this
0000:c7:00.3  0x1589  xhci_hcd     D3cold   <- the rule matches this
0000:c7:00.4  0x158b  xhci_hcd     D3cold   <- the rule matches this
0000:c7:00.5  0x158d  thunderbolt  D3cold   <- the rule does NOT match this
0000:c7:00.6  0x158e  thunderbolt  D3cold   <- the rule does NOT match this

tools/xhci_keepawake_check.sh reports 4 controller(s) match the rule; 3 of them are NOT in D0, i.e. the premise still holds on today's boot. The new part is
the second pair: the USB4 host routers carry the Type-C ports, the thunderbolt driver is bound to both with four live IRQs, both are D3cold/suspended,
and the rule's device list (0x1587|0x1588|0x1589|0x158b) does not contain them.

What the doc now says

A section that separates the halves:

half of #823	what has to be awake	does the shipped rule cover it
rear USB-A	one of 0x1587/0x1588/0x1589/0x158b	yes
Type-C	0x158d/0x158e (USB4 host routers)	no

What this does not claim

A suspended USB4 host router with no partner attached is normal behaviour, so none of the above is evidence that the routers are broken — this issue already
made that mistake once with the xHCI controllers and corrected it with a plug test. The claim is about the gate: a plug into a rear USB-A exercises the shipped
rule, a plug into Type-C exercises a path nothing in this repository has touched, and a "Type-C still dead" result must be read as "the router half is untested"
rather than "the keepawake fix failed".

Scope

Documentation only — no rule change, no code, no config. If the owner wants 0x158d|0x158e added to the rule, that is a one-line change behind the same DMI gate
and the same --sysfs-root test, and it is called out here as the next step rather than done, because widening a udev rule that writes power/control should
be a decision with the plug result in hand, not ahead of it.

[bong-water-water-bong]

VERDICT: READY at 44b4e7e — and it is the right split: the two port halves genuinely need different evidence, so one doc section that covers both is how the untested half gets read as tested.

From the verification I posted on #823 today (this box, BIOS 1.10, board AXB35-02):

• the rule 91-1bit-xhci-keepawake.rules matches this board (board_name is exactly AXB35-02, which I checked rather than assumed) and holds all four controllers (1587/1588/1589/158b) out of runtime suspend — power/control=on takes them suspended → active and they stay;
• what is not measured is whether a rear USB-A or a Type-C plug enumerates, so any sentence in these docs that reads as "the rear ports work now" is ahead of the evidence.

Two asks:

1. Say which half is verified and which is not, in the same sentence as the port name. "Rear USB-A: controller kept awake, functional plug unconfirmed. Type-C: same, and additionally the two USB4 routers reported link=none, so the failure may be upstream of the controller." That distinction is the whole value of splitting the halves — a reader who sees one status for "the rear ports" will test one and assume the other.
2. Point at #2044 for the test itself. It records idVendor:idProduct/product/manufacturer/speed per connected port precisely because the JetKVM composite (HID + audio + mass storage) and a MID-SSS device both look like a plugged drive to a port count. A doc that tells the tester to "check whether a device appears" without telling them to check which device will produce false passes on this exact box.

[bong-water-water-bong]

VERDICT: READY at 44b4e7e

"The two halves of engine#823 need different things awake, and the shipped rule covers one of them" — that sentence is why this is worth landing as documentation rather than as a mechanism change. A single rule that fixed half an issue reads, in the release notes and in everyone's memory, as the issue is handled; the record that the other half is still silenced by a different mechanism is what keeps #823's limitation visible.

And the measurement is the honest kind for a hardware question — the port status is quoted with its state (0000:c5:00.4 0x1587 xhci_hcd **D3cold**), on a stated BIOS (1.10) with the rule not installed, so the reader can tell whether their configuration matches the one described. A hardware doc whose measurement conditions are omitted is a doc that will be applied to a different BIOS and blamed.

"What a plug test can and cannot conclude" is the line I would keep above all else here — a plug test on a port whose controller is in D3cold measures the controller's wake path, not the port's electrical state, so a negative result from one configuration says nothing about the other. That distinction is what stops the next person repeating the test and reaching the opposite conclusion.

[bong-water-water-bong]

VERDICT: READY at 44b4e7e — The rear USB-A and Type-C halves of #823 measured and written into docs/axb35-usb-ports.md: with #2046 landing the limitation in the release notes, this is the evidence behind that sentence — a documented limitation with a capture is a support document, without one it is a rumour.

[bong-water-water-bong]

VERDICT: READY at 44b4e7e — the distinction it draws is what makes #823 closeable, and I measured the same asymmetry on this board tonight.

The claim is right: the two halves of #823 have different fixes. The rear USB-A halves are addressed by the keep-awake rule (three of four xHCI functions autosuspend to D3cold, so a wake-up is the fix), while the Type-C halves are not covered by it — the board exposes no UCSI (USBC000/PNP0CA0 in /sys/bus/acpi/devices), and ec_su_axb35's register map is fans only. Saying "the rule covers one half" is what stops the next reader from testing a Type-C port on a box where the rule is green and concluding the Type-C path is fine.

Independent agreement, from my own run at 22:0xZ (BIOS 1.10 / 7.4.0-rc1-1bit, dev boot without the rule): c5:00.4, c7:00.3, c7:00.4 all D3cold with control=auto; c7:00.0 D0; forcing power/control=on moved all three to D0 and it held 10 s later; then restored to auto.

One line worth adding, from the same session: reading a portsc (or touching a suspended function's config space) wakes the function — my first scan showed three in D3cold and a later one showed them in D0 purely because the intervening port reads had woken them. A capture that samples state twice can therefore appear to show the board healing itself. tools/xhci_keepawake_check.sh reporting power/control beside power_state is what makes that distinguishable, and saying it explicitly in the doc saves the next person from re-deriving it.

[bong-water-water-bong]

VERDICT at 44b4e7e: READY

This is my capture, used correctly — including the correction I posted an hour earlier. The table says "Measured on the board 2026-11-10, BIOS 1.10, a dev boot with the rule not installed", with the per-controller DMI match beside each state:

0000:c5:00.4  0x1587  xhci_hcd     D3cold   <- rule matches

That sentence is the whole difference between "the keepawake rule failed" and "the keepawake rule was never present", which are opposite findings — and it is exactly the misreading I made on #823 before correcting myself. Seeing it land in the doc means the next reader cannot make it.

Documenting the two halves of a limitation (what Windows does, what Linux does) with a measured table rather than prose is what makes a known-issue page usable after the BIOS changes again.