Wi-Fi is a track: the accepted AX2xx design's stages with owners and exits, and the issues it owes

issues/a-platform-with-no-transmit-power-table-joins-no-wifi-network.md

@@ -0,0 +1,31 @@
+---
+status: open
+kind: defect
+opened: 2026-10-12
+---
+
+# A platform with no transmit power table joins no Wi-Fi network
+
+The accepted Wi-Fi design (#876 §4) sets each channel's transmit limit to the
+tighter of two values:
+
+- the platform's per-device power table, which its ACPI namespace carries
+  under the radio's device;
+- the access point's country element.
+
+The design gives no limit at all where the platform has no table. There,
+`ax2xx` joins no network and says so: "no transmit limits for this
+platform". Its passive scan still runs.
+
+What such a platform may transmit at is unknown. So is what the firmware
+enforces where the platform gives no limit (#876 §11). From W6's landing, a
+machine whose firmware carries no table has no Wi-Fi.
+
+Owner: W6 of `issues/there-is-no-wifi.md`.
+
+**Exit**:
+- the specification or a measurement says what the firmware enforces and
+  what such a platform may transmit at;
+- the owner rules on it;
+- a platform with no table joins under that ruling, with a host test of the
+  limit it uses.

issues/acpiserver-serves-no-client.md

@@ -0,0 +1,27 @@
+---
+status: open
+kind: defect
+opened: 2026-10-12
+---
+
+# acpiserver serves no client, so no driver can read its own device's ACPI methods
+
+`[programs.acpiserver]` in `images/system.toml` serves nothing: it holds the
+`acpi` claim and receives `power`. Its module doc (`system/acpiserver/src/main.rs`)
+names everything it evaluates: the fixed hardware, the embedded controller,
+and the batteries and AC adapters.
+
+A userland driver whose device keeps something in the ACPI namespace has no
+way to reach it. The Wi-Fi driver needs the per-device transmit power table
+that the platform keeps under the radio's ACPI device, before it sends its
+first frame (#876 §4, P8).
+
+Owner: P8 of `issues/there-is-no-wifi.md`.
+
+**Exit**:
+- acpiserver evaluates the methods under one PCI function's ACPI device for
+  that function's driver alone, over a connection the supervisor opens for
+  that binding;
+- nothing names another device's scope;
+- host tests hold the binding's refusals;
+- a T14 row reads the AX210's tables.

issues/netstack-drives-one-card.md

@@ -0,0 +1,36 @@
+---
+status: open
+kind: defect
+opened: 2026-10-12
+---
+
+# netstack drives one card
+
+netstack opens the first of `CARDS` the supervisor endowed, and no other
+(`system/netstack/src/main.rs`, `main`). It opens it behind `Card`, an enum
+of its in-process drivers (`system/netstack/src/card.rs`). Its node is one
+interface with one DHCP client (`system/netstack/node/src/lib.rs`). So a
+machine with a wired and a wireless link uses only one of them. [ip] already
+routes over several interfaces, the lower index winning a tie
+(`system/netstack/ip/src/lib.rs`).
+
+The owner ruled for several interfaces over one chosen by the manifest. He
+also ruled that "netstack runs every link a driver brings, wired first, with
+failover" (#876, issuecomment-6120490125, ruling 3).
+
+That reverses part of `issues/first-match-selection-that-remains.md`
+(`kind: rejected`), whose virtio bullet says a second virtio NIC "would be
+dropped" and that "Neither is a defect today". Under ruling 3 a second NIC
+dropped is this defect.
+
+Owner: P5 of `issues/there-is-no-wifi.md`, after the LAN track's stage 3
+moves the drivers out (`issues/the-lan-is-not-yet-production-grade.md`).
+
+**Exit**:
+- one interface per link, each with its own DHCP client, lease and mDNS
+  responder, under one host name;
+- links ranked wired before wireless, then by arrival;
+- a guest with two virtio NICs in which the first's link is set off over
+  QMP, and traffic leaves on the second;
+- the NIC taken out of the virtio bullet of
+  `issues/first-match-selection-that-remains.md`.

issues/no-access-point-answers-to-the-harness.md

@@ -0,0 +1,30 @@
+---
+status: open
+kind: tooling
+opened: 2026-10-12
+---
+
+# No access point answers to the harness
+
+Four Wi-Fi behaviours have no instrument (#876 §9, item 9, and W8 of
+`issues/there-is-no-wifi.md`):
+
+- an access point deauthenticating the station;
+- an access point rekeying its group on demand;
+- beacon loss: an access point the harness silences;
+- roaming: two access points of one network, the harness silencing the one
+  the station is on.
+
+Each needs access points that the harness commands. Nothing in the tree
+names one: `git grep -i 'access point' ab655a115 -- tests build system lib
+kernel` finds nothing and exits 1. A host program that runs one is declared
+under Arrivals, in
+`issues/the-build-runs-host-tools-outside-rust-and-qemu.md`.
+
+Owner: the orchestrator, whose benches they are.
+
+**Exit**: a T14 row, and once W7 has landed an AMD bench row, in which the
+harness makes an access point deauthenticate the station, rekey its group and
+fall silent, and silences one of two access points of one network. In it the
+station rejoins, installs the new group key, recovers from the silence as W8
+decides, and roams to the other access point.

issues/pcidev-moves-a-bar-behind-a-bridge-out-of-the-range-the-bridge-forwards.md

@@ -0,0 +1,61 @@
+---
+status: open
+kind: defect
+opened: 2026-10-12
+---
+
+# pcidev moves a BAR behind a bridge out of the range the bridge forwards
+
+Before a hand-over, `kernel/src/pcidev/mod.rs` re-places each BAR onto a
+2 MiB boundary of its own (`place_bar`). The candidates come from
+`placement::reserve` (`kernel/pci/src/placement.rs`), and a candidate is one
+of the free runs: a gap left by everything the machine decodes, inside a
+root bridge's window.
+
+The range every bridge forwards to its secondary bus is part of that
+"everything" (the `forwarded()` loop that feeds `placement::free_runs`). So no
+candidate ever lies inside the range a function's own bridge forwards. A
+function on a secondary bus decodes at none of the `MAX_CANDIDATES` (8)
+addresses it is offered, and its claim is refused.
+
+Both benches put their radio there:
+
+- **The AMD bench**, as `main`'s kernel logged it in #884's metal run (E13 §1,
+  https://github.com/ToyOSOrg/evidence/blob/2eb315326d1b4d0363b4c918da8dd2bfaabd1234/e13-amd-ax200-bar.log):
+  the AX200 at 01:00.0 has BAR 0 at 0xd0600000, behind bridge 00:02.2, which
+  forwards 0xd0600000..0xd0700000; no free run reaches into that range.
+- **The T14**, as S1 read it (lines 111 to 116,
+  https://github.com/ToyOSOrg/evidence/blob/cd368b25b2259a76b80dc31f4219dac1c91d84dc/s1/wifi-s1-a-kernel.log):
+  the AX210 at 09:00.0 has BAR 0 at 0xbc300000, 16 KiB, behind root port
+  00:1c.4, which forwards 0xbc300000..0xbc400000.
+
+The Wi-Fi demo's run on the AMD bench took this path, as its commit messages
+record (E13 §2): pcidev moved the AX200's BAR 0 onto eight 2 MiB windows from
+0x450200000, all outside the 1 MiB that 00:02.2 forwards; every moved BAR read
+0xffffffff, and the claim was refused. The demo then kept the BAR in place,
+untranslated and unremapped, which `main` never does.
+
+Two placement issues rest on placement as it is, and P1 takes them up with
+this one:
+
+- `issues/nothing-reds-when-the-bar-survey-drops-an-assigned-bar.md` asks for
+  a guest that reds when the forwarded-range push is deleted. That push is
+  what puts every candidate outside its bridge. Its "No machine in reach puts
+  a BAR it hands over behind a bridge" holds only until a radio is handed
+  over: both benches put theirs behind one.
+- `issues/no-boot-reaches-the-retry-that-undoes-a-placement-nothing-answered.md`
+  wants a function behind a `pcie-root-port` to settle at a later candidate.
+  Under this issue no candidate lies inside a port's window, so none ever
+  answers there.
+
+Owner: P1 of `issues/there-is-no-wifi.md`.
+
+**Exit**:
+- a BAR inside every window on its path to the root is mapped in place, in
+  4 KiB pages;
+- a BAR that shares a 4 KiB page with another function's is moved within
+  those windows, never out of them, or is refused by name;
+- a host test places a BAR behind a bridge;
+- the T14's AX210 is claimed with its BAR in place;
+- each of the two placement issues above closed, or its exit rewritten to the
+  placement P1 lands.

issues/the-wifi-demos-commits-still-resolve-on-origin.md

@@ -0,0 +1,60 @@
+---
+status: open
+kind: defect
+opened: 2026-10-12
+---
+
+# The Wi-Fi demo's commits still resolve on origin
+
+The Wi-Fi demo ran on the AMD bench and never lands. Its branches are gone
+from `origin`, a public repository. Read at `origin/main` `ab655a115` (E12 §1,
+https://github.com/ToyOSOrg/evidence/blob/2eb315326d1b4d0363b4c918da8dd2bfaabd1234/e12-demo-on-origin.log):
+
+- no ref on `origin` carries the AMD bench's model name;
+- the two refs that still hold the demo's first commit, `a8e1c96`, touch no
+  Wi-Fi-named path and carry no line with that name past `origin/main`.
+
+At `c0cdddf4e` E10 had counted 11 branches holding it that touched a
+Wi-Fi-named path
+(https://github.com/ToyOSOrg/evidence/blob/5d27b8209199228ccc1e133b69ad4c3758f18510/e10-demo-branches-on-origin.log).
+
+Their commits still resolve there by hash. Over the 12 tips E10 prints past
+`wt/toyos-survey`, `git rev-list <tips> --not --remotes=origin` prints 52
+commits. No ref on `origin` holds any of them, pull requests' refs included,
+`origin` has no fork, and GitHub's commit API for `origin` answers all 52
+(E15,
+https://github.com/ToyOSOrg/evidence/blob/6196aad98a0bf5eff937a25b9dad4ec10e59376f/e15-demo-commits-on-origin.log).
+The API's answer for each of the 12 tips carries the model name (E12 §2).
+
+Three logs on `ToyOSOrg/evidence`, whose branches only grow, print hashes
+that resolve there:
+
+- E10 and E11 print the 12 tips in full;
+- E13 §2 quotes a build by its hash, abbreviated to nine hex digits (its
+  line 80). Nine of the tips hold that commit, and it is one of the 52.
+
+What the demo's commits carry:
+
+- the model name, which E10 to E13 mask: in commit subjects (E13 §2 quotes
+  two,
+  https://github.com/ToyOSOrg/evidence/blob/2eb315326d1b4d0363b4c918da8dd2bfaabd1234/e13-amd-ax200-bar.log),
+  and in the heading of the firmware entry they add to `NOTICE` (E11,
+  https://github.com/ToyOSOrg/evidence/blob/de051da9eaff0cfae26a16695b478f0d6f46648d/e11-demo-notice-entries.log);
+- a driver written against a reference rather than from a specification: the
+  message of E10 line 52's tip says its `netstack/src/wifi.rs` was "written
+  against OpenBSD's ISC-licensed if_iwx (22000 family)" (E12 §3), and no
+  demo branch adds a `NOTICE` line naming a reference (E10). The owner's
+  ruling admits a reference only as clean-room information, which takes no
+  notice (#876 §0); code written against one is not that, and carries none
+  [I].
+
+Owner: the orchestrator. The owner, whose call the demo's branches were,
+ruled to leave the commits on GitHub: "leave it". Nothing asks GitHub to
+remove them, so the exit waits for GitHub's garbage collection of commits no
+ref holds.
+
+**Exit**: no ref on `origin` carries the model name, which E12 §1 already
+reads; and GitHub's commit API for `origin` answers none of the commits
+`git rev-list <tips> --not --remotes=origin` prints over those 12 tips, where
+E15 reads 52 of 52. The local branches are kept for readers' scouts, and
+every reader's scout stays off `origin` (#876 §7).