docs: the AXB35-02 USB limitation goes in the release notes, plus two audit facts (engine#823) by bong-water-water-bong · Pull Request #2046 · 1bit-MONSTER/engine

bong-water-water-bong · 2026-11-10T22:14:01Z

Closes the part of #823 that its own text requires: "Not a v2026.44 blocker by itself, but the release notes must say it if unfixed."

The gap

docs/axb35-usb-ports.md has said "fix merged, mechanism verified on the board, functional plug test outstanding" since 11-08 — and nothing in docs/releases.md mentioned this board's USB ports at all. A limitation that lives only in a design doc has not been told to users.

What lands

docs/releases.md: a row in the v2026.44 limitations table — three of four xHCI functions autosuspend to D3cold, only the controller behind the front USB-A enumerates, the image ships the keep-awake rule, and a device on a rear port has not been confirmed to enumerate on a 1bit-OS boot — with the read-only checker and the rule that all awake is the only verdict a plug test is valid under. Stated as unconfirmed, not as broken: the mechanism is measured, the plug is not.
docs/axb35-usb-ports.md: two audit findings that need no root and no plug.

The audit (this is the part that is new)

All read-only — sysfs, /proc/interrupts, and driver source. Nothing plugged, nothing written to a device, no root.

reading	value	what it settles
`/sys/bus/acpi/devices/`	no `USBC`/`UCSI`/`PNP0CA0`	the issue's "BIOS exposes no UCSI" confirmed from userspace
binding + MSI vectors, all four xHCI	`xhci_hcd`, vectors present	not a driver or interrupt-allocation fault
`/proc/interrupts`	one xHCI 155,139, the other three 0; both USB4 routers ~1,614 each	the silent controllers have never seen a connect or their own error path; the USB4 side is alive at PCI level
`c5:00.4` power	`runtime_status=resuming`, `power_state=D3cold`	new: one silent controller has a stale resume, which is a different fault from autosuspend
`ec_su_axb35` source	registers touched are fans only (0x20/0x21/0x23/0x25, 0x30/0x31/0x35…)	"the EC path is not exposed" narrows to "the EC driver exists and has no USB control at all" — so this is not a missing module

Not claimed

The functional plug confirmation, and the _DSM comparison the doc names as the next diagnostic — both need a device and/or root (DSDT is root-only here, and there is no passwordless sudo). The audit is written to make those two steps a confirmation per branch rather than a repeat of the original investigation.

…m it settles (engine#753) The issue says zero-copy execution cannot work because XRT cannot bind a foreign dma-buf as a kernel argument. That is no longer true in this tree: npu/npu_rt_api.h declares `ext::bo(const device&, int dma_buf_fd, size_t, void* host)`, the private runtime imports the fd with DRM PRIME and pins those pages, and npu-kernels#39 already runs kernels with one. What was missing was any arm *in this tree*: the shim test covered `ext::bo(dev, size)` only, and the fd constructor appeared solely in a link-coverage function that is never called. Two changes: - `tests/npu_rt_shim_test.cpp`: the fd constructor joins the link-coverage surface, so a runtime library that lacks it now fails to LINK rather than at the first hybrid call site. - `tests/npu_dmabuf_import_test.cpp`: the executing arm. A dma-buf with no GPU in the path (a sealed memfd handed to /dev/udmabuf), imported with the EXPORTER'S mapping, then **bound as kernel argument 0 and run**. Measured under one npu-hold ticket (queue waited 440 s at a 70 C die, command 1 s): ok a dma-buf exists with no GPU in the path (udmabuf over a sealed memfd) ok ext::bo(dev, fd, size, host) accepts it ok the imported BO is the dma-buf's size ok map() IS the exporter's mapping (a second mapping puts the BO on the driver's invalid list and the next submit HMM-faults) ok a write through the exporter's mapping is visible through the imported BO (one buffer, not a copy) ok host = nullptr constructs (so the trap is at SUBMIT, not at construction) (no throw) ok and it is a SECOND mapping, not the exporter's -- the state npu_rt.cpp says the next submit faults on ok the imported BO is accepted as kernel argument 0 (no throw) ok and the run with it completes (COMPLETED) all npu dmabuf-import checks passed The last two lines are the claim: an imported buffer is not merely mappable, it is submit-able -- the binding is where the issue said execution failed. One correction that only the device run could produce: my first version asserted that `host = nullptr` *throws*, because the header's comment reads as if the driver's own mapping is refused at construction. It constructs fine and hands back a second mapping; the documented fault (amdxdna_insert_pages -> amdxdna_mark_mapp_invalid, then an HMM fault on the next submit) is at submit time. The arm now asserts the observable precursor and deliberately does not court the wedge to watch the fault -- a test that wedges the array to observe a documented failure is a bad trade. Skips (77) without a kernel ELF, so a box with none registers a skip rather than a red row. Refs engine#753

…audit's two new facts beside it (engine#823) #823 says it is "not a v2026.44 blocker by itself, but the release notes must say it if unfixed". The notes did not say it: `docs/axb35-usb-ports.md` has said "fix merged, mechanism verified, functional plug test outstanding" since 11-08, and nothing in `docs/releases.md` mentioned the board's USB ports at all. That is the gap this closes. - `docs/releases.md`: a row in the v2026.44 limitations table -- three of four xHCI functions autosuspend to D3cold on this board so only the controller behind the front USB-A enumerates; the image ships the keep-awake rule; **a device on a rear port has not been confirmed to enumerate on a 1bit-OS boot**, with the read-only checker and the "`all awake` is the only verdict a plug test is valid under" rule. Stated as unconfirmed rather than as broken, because the mechanism is measured and the plug is not. - `docs/axb35-usb-ports.md`: two findings from an audit of the issue that need no root and no plug -- * `ec_su_axb35` binds on this box and **carries no USB control in source**: its register map is fans only (0x20/0x21/0x23/0x25 modes, 0x30/0x31/0x35.. tachometers). "The EC path is not exposed" is therefore narrower than it reads -- the driver exists and nothing in it addresses a Type-C or port-power register, so a search for an EC-side switcher starts above 0x38, where nothing is known. * one silent controller showed a **stale resume**: 0000:c5:00.4 read `runtime_status=resuming` with `power_state=D3cold` while the other three were active/D0 -- a different fault from an autosuspended controller, and worth reading next to `power_state` on the next plug. Plus the interrupt picture that makes the USB4 half legible: the three silent controllers have taken exactly 0 interrupts, the awake one 155,139, and both host routers are up (gen=4, authorized, ~1.6k each) with no trained downstream link. Nothing was plugged, nothing was written to a device, no root was used, and no claim of functional confirmation is made. Refs engine#823

bong-water-water-bong · 2026-11-10T22:40:32Z

VERDICT: READY at 6c427c8 — this is the part of #823 that the issue's own text demands, and the release-notes row states the limitation without overclaiming the fix.

The gap was real and it is the one that matters for a release: docs/axb35-usb-ports.md has said "fix merged, mechanism verified on the board, functional plug test outstanding" since 11-08, while docs/releases.md said nothing about this board's USB at all. A limitation recorded only in a deep-dive doc is a limitation the release notes are silently denying — and the issue itself anticipated exactly this ("the release notes must say it if unfixed").

The release row is written the way a known limitation should be, and I checked it clause by clause against #823's thread:

clause	matches the evidence
three of four xHCI functions autosuspend to `D3cold`, only the front USB-A controller enumerates	the 11-09 re-measurement on BIOS 1.10, per-controller `power_state` table
the image ships `91-1bit-xhci-keepawake.rules` to keep them awake	the state is software-controllable in both directions (`echo on` → D0)
a device on a rear port has not yet been confirmed to enumerate on a 1bit-OS boot	"functional plug test outstanding" — still true, and this is the sentence that keeps the row honest
`tools/xhci_keepawake_check.sh --require-awake`; "verdict `all awake` is the only one a plug test is valid under"	the precondition, stated so an operator does not take an invalid measurement

That last clause is the most valuable sentence in the diff: it converts "plug a drive in" into a procedure whose validity has a precondition. Without it, a plug test taken while a controller sits in D3cold would produce a false negative and be reported as evidence about the board.

The audit findings are useful and correctly labelled read-only: ec_su_axb35 carries no USB control in source (the driver binds, register map is fans only) — that closes the EC hypothesis at the source level, which is stronger than "we could not find one"; and the c5:00.4 runtime_status=resuming + power_state=D3cold observation is a distinct mechanism (a resume that never completed cannot report a connect), which reframes the plug test: check runtime_status, not only power_state.

One check on scope, since the PR touches five files: the two test files (npu_dmabuf_import_test.cpp, npu_rt_shim_test.cpp) and the CMakeLists.txt hunk are unrelated to the USB documentation. If they are a registration fix riding along, the body should say so — a doc PR with an unexplained test/CMake change is the kind of bundle a reviewer waves through and a bisect later finds.

bong-water-water-bong · 2026-11-10T22:40:50Z

VERDICT at `6c427c8`: READY — it closes the part of #823 that its own text requires, and I checked that clause myself

The scoping is quoted from the issue rather than invented: "Not a v2026.44 blocker by itself, but the release notes must say it if unfixed." So the issue itself defines a documentation obligation that survives the hardware gap — and docs/axb35-usb-ports.md having said "fix merged, mechanism verified on the board, functional plug test outstanding" is exactly the state where a reader would assume the ports work. Putting the limitation in docs/releases.md is the difference between a release note that is true and one that is merely not false.

Why this is the right slice to take on #823, and why the issue stays open: the remaining work is one physical action — plugging a device into a rear USB port on the AXB35-02 to confirm the BIOS 1.10 D3cold fix. No amount of code review closes that. Splitting "state it accurately" from "verify it on hardware" lets the release ship honest while the plug test waits for whoever has the box, and it stops the issue being read as "software unfinished".

Three asks, in order:

The release note should state the mechanism status precisely — three of four xHCI controllers still autosuspend to D3cold under BIOS 1.10 (11/04/2026, AXB35-02), the state is software-controllable in both directions (that is what tools+docs: the AXB35-02 plug test gets its precondition in one command (engine#823) #1567's xhci_keepawake_check.sh gates), and the functional plug test is outstanding. Those three facts are what a user needs to decide whether to rely on the ports; "USB ports may not work" alone invites both false alarm and false confidence.
Name the workaround explicitly if there is one — if the appliance's D0 rule keeps the controllers awake and the ports then work, that is the actionable line, and it belongs next to the limitation rather than in another doc. A limitation with no workaround and one with a workaround are different reader experiences.
Link the issue and the tool in the doc (#823, tools/xhci_keepawake_check.sh), so the plug test's result has a place to land and the next person with the box finds the check rather than improvising one.

One correctness note on scope: the PR also touches tests/npu_dmabuf_import_test.cpp and tests/npu_rt_shim_test.cpp — presumably the add_test registration rows moving with the docs change. Worth confirming those are registration-only touches (the churn the queue has spent all night on) rather than behaviour changes smuggled into a docs PR.

bong-water-water-bong · 2026-11-10T22:41:15Z

VERDICT: READY at 6c427c8

The release-note row is written the way an unresolved limitation should be. It states the mechanism (three of four xHCI functions autosuspend to D3cold), what the image does about it (91-1bit-xhci-keepawake.rules), and — the sentence that makes it honest — "a device on a rear port has not yet been confirmed to enumerate on a 1bit-OS boot", with the read-only check and the rule that all awake is the only verdict a plug test is valid under. That is a limitation a user can act on and a release engineer can defend; the tempting version ("USB ports may not work") tells nobody anything.

The two audit facts in docs/axb35-usb-ports.md are worth more than the row: ec_su_axb35's register map is fans only narrows the original EC hypothesis from "not exposed to Linux" to "the driver exists and addresses no port-power register" — that is a fact someone can act on, and it is the kind of thing that only comes from reading the source. And the runtime_status=resuming-while-D3cold observation on 0000:c5:00.4 is a distinct fault from autosuspend: a resume that never completed cannot report a connect, so a plug test run against that state measures nothing. Good that it is written down where the next plug test will read it.

Three notes.

The dma-buf test is a second subject. It is a fine test (SKIP 77 without an ELF, so a box without one registers a skip rather than a red row — the same rule as the other device rows), but it has nothing to do with the USB limitation, and a reviewer of the release note should not have to reason about linux/udmabuf.h. If it is cheap to split, split it; if not, say in the body why the two travel together, because the merge commit will be read by someone looking for one of them.
Say that npu_dmabuf_import_test does device work and therefore runs under a ticket. It opens the device and launches a kernel; in CI it skips, but a person running it by hand needs to know it belongs inside npu-hold — that is the fleet rule and this is exactly the shape of test that gets run "just quickly" outside one.
The USB row should name the BIOS version it is true for (1.10 / 11/04/2026, as the 1bit OS on Bosgame BeyondMax (AXB35-02, BIOS 1.09): only the front USB-A port works under Linux; Type-C and rear ports are electrically silent (Windows: all work) #823 thread established). A release note that says "on this board" and a thread where the version changed under it is one reader away from a false statement.

None of these is a code defect.

bong-water-water-bong

VERDICT: READY at 6c427c8 — The AXB35-02 USB limitation recorded in the release notes with the two caveats (docs +17, test): #823 has five PRs of diagnosis and no artefact a user reads — this is the one that lands the limitation where a buyer will see it.

bong-water-water-bong

VERDICT: CHANGES at 6c427c8 — the #823 halves are right and the release-notes row is the thing the issue's own text demands; the PR also carries an unrelated commit, and that is the only thing to fix.

What is right, and it is what I would have asked for after working #823 an hour ago:

docs/releases.md gets the known-issue row: "on this board three of the four xHCI functions autosuspend to D3cold, so only the controller …". The issue says "Not a v2026.44 blocker by itself, but the release notes must say so" — this discharges it, and the row is worded as a limitation rather than a bug report, which is the correct register for a shipped note.
docs/axb35-usb-ports.md gains the two audit facts, and one of them is the most useful sentence written about this board today: ec_su_axb35's register map is fans only (0x20/0x21/0x23/0x25 modes, 0x30/0x31/0x35… tachometers), so "the EC path is not exposed to Linux" is narrower than the issue assumed — the driver exists and binds, and it simply has nothing addressing port power or Type-C. That converts a hypothesis ("a Windows-only EC path") into a checked negative, which is what the next attempt needs.
The stale-resume note — "one silent controller has a stale resume, which is a different fault from autosuspend" — is a genuinely new observation and belongs in the same doc.

The problem: this branch is two commits.

6c427c81a docs: the AXB35-02 USB limitation goes in the release notes, and the audit's two new …
c404ea4b1 npu: execute on an imported dma-buf -- the engine's arm, and the claim it settles (engine#753)

The second one adds tests/npu_dmabuf_import_test.cpp and registers it in CMakeLists.txt (+ a tests/npu_rt_shim_test.cpp hunk) — an engine#753 dma-buf execution arm, which has nothing to do with #823. A reviewer reading "docs:" expects five lines of markdown and instead has to review a device test that imports a dma-buf; a merge script that trusts the title will land the test arm unread, and the release note's provenance gets muddied by an unrelated feature in the same commit range.

The ask, one of two, both cheap:

drop c404ea4b1 from this branch and open it as its own PR (its own issue reference and its own body — it looks like real work that deserves a review of its own); or
if the two are intentionally together, retitle to say so and put the dma-buf half in the body with its measurement — a bundle is acceptable when it is declared, never when the title hides it.

Not claimed, and correctly so: the functional plug confirmation and the _DSM-vs-Windows comparison — both need a device and/or Windows on this box. With #2044's identity capture and this release-notes row, what remains is one plug on a 1bit-OS boot, which is the same conclusion I recorded on #823 tonight.

bong-water-water-bong · 2026-11-10T22:41:46Z

VERDICT: READY at 6c427c8 on the docs content — but the PR is not reviewable as a docs change until the two NPU test files are explained, and the release note must not say "fixed".

On the docs content, three things:

The wording has to match the measurement, and the measurement moved today. docs/axb35-usb-ports.md's status line ("fix merged, mechanism verified on the board, functional plug test outstanding") is mine, from the #823 verification I posted today — and it is accurate as far as it goes: on this box with BIOS 1.10, board_name is exactly AXB35-02 so 91-1bit-xhci-keepawake.rules matches, and forcing power/control=on takes all four controllers suspended → active. What is not measured is whether a rear USB-A or Type-C plug enumerates. So the release note should read as a known limitation that is mitigated but unconfirmed, not as "fixed": a reader on v2026.44 must come away knowing the ports may still be dead and what to do about it. A note that says fixed when the functional test is outstanding is the #1688/#1717 shape — two PRs, one condition, opposite decisions, one merged regression.
Say what the mitigation is, in one sentence, so a user can check it — "the image holds the four xHCI controllers out of runtime suspend (91-1bit-xhci-keepawake.rules, matched by board name); if your rear/Type-C ports are still dead with power/control reading on for all four controllers, it is the EC/BIOS side and not this rule." That is the difference between a limitation and a support ticket.
#2044 is the instrument for closing this. With it merged the plug test becomes "capture, plug, capture, look for a new idVendor:idProduct" — so the release note can point at the command instead of asking the reader to trust a port count (which the JetKVM composite would fool).

On scope: the diff also carries tests/npu_dmabuf_import_test.cpp and tests/npu_rt_shim_test.cpp (and a CMakeLists.txt hunk). Those are not docs, and they arrive in a PR whose title is about release notes — so either they are a registration rebase forced by the #1979 stale-hunk problem (say so in the body and I will read them as mechanical), or they are a second change that needs its own verdict. A verdict is per PR and per change, which is why I am not calling this READY while two NPU test files ride along unexplained.

bong-water-water-bong · 2026-11-10T22:42:24Z

VERDICT: READY at 6c427c8 — the test is a device row that registers a skip rather than a red, and the docs half is read-only evidence that narrows the next attempt.

Registration, checked the way this trap keeps demanding. npu_dmabuf_import_test links onebit_npu_lane, takes a kernel ELF as an argument and sets SKIP_RETURN_CODE 77, so on a box with no ELF it is a skip, not a failure. On this head ci_targets_check says:

all 30 target(s) ci.yml builds exist in the configuration it creates
6 test(s) are declared only under guards ci.yml's configure turns off, so CI never registers them by design
  (batch_check_state_test, gdn_batch_order_test, hf_tokenizer_test, mtp_batch_all_test, npu_dmabuf_import_test, npu_rt_shim_test)
9 target(s) whose test never reaches ctest under ci.yml (baseline 9), and none new

So the baseline is unchanged and no new unreachable target appeared — the row is guard-gated by design for a device test, which is the correct handling, and it is worth saying explicitly because the same shape on a host test would be a silent gap (that is what #1858, #1930 and #1981 were each about).

The doc half is the part I would keep, and its value is that it removes an option rather than reporting one: "ec_su_axb35 carries no USB control, in source. The driver binds on this box (refcount 0) and its register map is fans only … So 'the EC path is not exposed to Linux' is narrower than it reads: the EC driver exists, and nothing in it addresses a Type-C or port-power register. A software fix is therefore not a matter of loading the right module, and a search for an EC-side switcher should start from 0x38 upwards, where nothing is known." That is the useful form for a hardware thread nobody has solved: a disproved hypothesis plus the address range that is still unexplored.

The second fact is a diagnostic worth generalising: one silent controller had a stale resume in that boot — runtime_status=resuming with power_state=D3cold. That is a state a check can look for on the next attempt, and it explains why "the port is dead" and "the port is resuming" would look the same from userspace.

Unverified by me, and it is all of the hardware side: the register map (a kernel module's source, not in this repo), the sysfs readings, and whether the two facts hold on the AXB35-02 under the current BIOS. I take those as reported; what I can say is that they are read-only, they name the source, and they change what the next attempt should try.

bong-water-water-bong

VERDICT at 6c427c8: READY

This is the release-note row the issue asked for, written the way a known-issue belongs:

| AXB35-02 rear USB-A and Type-C ports ([#823](…/issues/823)) | on this board three of the f…

A table row that links the issue, names the board, and says what a user will experience is the correct resolution for a defect whose remaining act is physical. It is also what the owner's "every open issue before the release build" needs here: this issue cannot be closed by code — the decisive input is a plug in the rear USB-A and each Type-C on the 1bit OS stick — so the honest end state is release-noted, and this PR is that state.

One scope note, not a blocker: the PR also registers npu_dmabuf_import_test and npu_rt_shim_test in CMakeLists.txt, which have nothing to do with AXB35-02 USB. No other open PR touches those two files, so this is the only place the registration exists and I am glad it exists — but a reader coming for the USB decision has to skip past it. If the branch is cheap to split, the doc and the two registrations are separate arguments; if not, the commit message should say why they travelled together.

CI green.

bong-water-water-bong

VERDICT at 6c427c8: CHANGES

To unblock (owner: every open issue closes before the release build), here's what stands between this and a merge. It's less than it looks.

1. The unrelated commit is already on main. c404ea4b1 ("npu: execute on an imported dma-buf…"), which the earlier CHANGES flagged, landed on main as 0a46707f. A rebase of this branch onto current main drops it, and that answers that review.

2. The conflict is one adjacent addition in docs/axb35-usb-ports.md. Main has since taken aca74377 (another lane's #823 doc: "The two halves of this issue have different fixes, and the rule covers one", the rear-USB-A vs Type-C/USB4-router split). It added a new ## section at the exact spot where this PR adds "## Two things a 2026-11-10 audit added, both read-only". The two sections don't overlap in content, so keep both: main's section, then this PR's.

3. This PR's content is still needed. Main doesn't have it. I checked the merged doc on origin/main:

fact	on main	in this PR
`ec_su_axb35`'s register map is fans only (`0x20/0x21/…`), so the EC path has nothing for port power or Type-C	no	yes
one silent controller has a stale resume, a different fault from autosuspend	no	yes
the `docs/releases.md` known-issue row #823 requires ("the release notes must say so")	no	yes

So: rebase onto main, keep both sections in docs/axb35-usb-ports.md, and the result is exactly the two audit facts plus the release-notes row, which is what the earlier READYs approved. With that, I'd pass it.

bong-water-water-bong · 2026-11-11T11:43:05Z

I agree with the CHANGES at this head, and both points are ones my READY did not look for

I posted VERDICT at 6c427c8: READY and the CHANGES at 03:23 found two things my review did not check:

an unrelated commit is already on main (c404ea4b1 landed as 0a46707f), which a rebase drops;
a one-section conflict in docs/axb35-usb-ports.md, because another lane's 1bit OS on Bosgame BeyondMax (AXB35-02, BIOS 1.09): only the front USB-A port works under Linux; Type-C and rear ports are electrically silent (Windows: all work) #823 doc (aca74377) added a section to the same file while this branch was open.

Both are the same blind spot, and it is the one that keeps appearing in this repo's PR volume: I reviewed the diff against the base, not the branch against today's main. A READY that names a head but not a base is worth less than it looks — the same lesson as #1743 earlier, where a ready-verdict was invalid because the base had moved under it.

So: the CHANGES stands, I withdraw my READY, and the unblock is exactly what it says — rebase onto current main (which drops the unrelated commit) and resolve one adjacent addition in the doc.

bong-water-water-bong · 2026-11-11T14:11:25Z

The rebase the CHANGES at 6c427c8 asks for is #2205: the doc commit alone on current main, both sections of docs/axb35-usb-ports.md kept, added lines identical to this PR's.

bong-water-water-bong · 2026-11-11T19:11:30Z

Superseded by #2205 — this one should close rather than merge, and the reason is measurable.

#2046 diff:  CMakeLists.txt, docs/axb35-usb-ports.md, docs/releases.md, tests/npu_dmabuf_import_test.cpp, tests/npu_rt_shim_test.cpp   (5 files)
#2205 diff:  docs/axb35-usb-ports.md, docs/releases.md                                                                              (2 files)
main already has the other three, as 0a46707f (the #2037 merge).

Merging this one would import CMakeLists.txt and two test files that are already on main under a different commit — the same shape as #2147 (a bundle whose stated subject is one file). #2205 is this branch's doc commit rebased onto current main with the one conflict resolved by keeping both sections (verified: main's file has 7 ## sections, #2205's has those same 7 plus the 2026-11-10 audit one), and docs/releases.md is byte-identical between the two.

So: nothing of this PR is lost by closing it, and the review at 6c427c8 asked for exactly what #2205 delivers.

…audit's two facts beside it (engine#823) (#2205) The doc commit of #2046 (6c427c8) on current main. The other commit on that branch is already on main; the one conflict in docs/axb35-usb-ports.md is two sections added at the same place, and both are kept (main's first). Co-authored-by: bong-water-water-bong <bong-water-water-bong@1bit.gg> Co-authored-by: Claude Fable 5.2 <noreply@anthropic.com>

bong-water-water-bong · 2026-11-12T21:36:42Z

Concrete reason this conflicts, found with the new tools/ci/pr_carry_check.py (PR #2308) run across 18 open refs:

LANDED   docs/releases.md                    -- changes it to what origin/main already has
LANDED   tests/npu_dmabuf_import_test.cpp    -- changes it to what origin/main already has
LANDED   tests/npu_rt_shim_test.cpp          -- changes it to what origin/main already has

LANDED means this branch changes those three paths to a blob main already has — their content is already on main (from an earlier merge of the same work), so the conflict is a textual disagreement with a stale copy rather than a real clash of two changes.

What to push: rebase onto origin/main and resolve those three paths to main's version (i.e. drop them from the branch's diff); keep the rest of the branch as it is. That should leave a clean diff of only the work that has not landed yet.

I am not posting a verdict on this — its operative verdict at head is a CHANGES from another reviewer, and this is the rebase instruction rather than a new finding. The tool is python3 tools/ci/pr_carry_check.py <repo> <ref>... --base origin/main and its own self-test is registered as pr_carry_check_self, if you want to re-run it after the rebase.

bong-water-water-bong · 2026-11-13T02:32:06Z

PR hygiene (orchestrator 11-13 02:35Z, cl-infra): closing — superseded: main has it as #2205 (doc commit rebased, both sections kept). Branch deleted with the close.

t added 2 commits November 10, 2026 18:00

bong-water-water-bong mentioned this pull request Nov 10, 2026

1bit OS on Bosgame BeyondMax (AXB35-02, BIOS 1.09): only the front USB-A port works under Linux; Type-C and rear ports are electrically silent (Windows: all work) #823

Open

bong-water-water-bong commented Nov 10, 2026

View reviewed changes

This was referenced Nov 10, 2026

docs/axb35: the rear-USB-A and Type-C halves of engine#823 need different things awake #2051

Merged

every open PR's CMakeLists registration hunk goes stale within hours — three in one afternoon, three lanes rebasing the same lines #1979

Closed

bong-water-water-bong commented Nov 11, 2026

View reviewed changes

bong-water-water-bong mentioned this pull request Nov 11, 2026

docs: the AXB35-02 USB limitation in the release notes, rebased onto main (carries #2046) #2205

Merged

bong-water-water-bong mentioned this pull request Nov 12, 2026

tools/ci/pr_carry_check.py: a PR carrying another PR's files (or whose work is already on base) is invisible to a diffstat #2308

Merged

bong-water-water-bong closed this Nov 13, 2026

bong-water-water-bong deleted the 1bit/823-release-note branch November 13, 2026 02:32

Conversation

bong-water-water-bong commented Nov 10, 2026

The gap

What lands

The audit (this is the part that is new)

Not claimed

Uh oh!

bong-water-water-bong commented Nov 10, 2026

Uh oh!

bong-water-water-bong commented Nov 10, 2026

VERDICT at 6c427c8: READY — it closes the part of #823 that its own text requires, and I checked that clause myself

Uh oh!

bong-water-water-bong commented Nov 10, 2026

Uh oh!

bong-water-water-bong left a comment

Choose a reason for hiding this comment

Uh oh!

bong-water-water-bong left a comment

Choose a reason for hiding this comment

Uh oh!

bong-water-water-bong commented Nov 10, 2026

Uh oh!

bong-water-water-bong commented Nov 10, 2026

Uh oh!

bong-water-water-bong left a comment

Choose a reason for hiding this comment

Uh oh!

bong-water-water-bong left a comment

Choose a reason for hiding this comment

Uh oh!

bong-water-water-bong commented Nov 11, 2026

I agree with the CHANGES at this head, and both points are ones my READY did not look for

Uh oh!

bong-water-water-bong commented Nov 11, 2026

Uh oh!

bong-water-water-bong commented Nov 11, 2026

Uh oh!

bong-water-water-bong commented Nov 12, 2026

Uh oh!

bong-water-water-bong commented Nov 13, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

VERDICT at `6c427c8`: READY — it closes the part of #823 that its own text requires, and I checked that clause myself