diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 04a3df4e..0095a910 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -52,11 +52,11 @@ jobs: env: DEBIAN_FRONTEND: noninteractive STOCK_RELEASE_URL: >- - https://raw.githubusercontent.com/MiSTer-devel/SD-Installer-Win64_MiSTer/76fd6f4ced6350b0ad56a7013b41526f47e3a2fb/release_20260907.7z.001 - https://raw.githubusercontent.com/MiSTer-devel/SD-Installer-Win64_MiSTer/76fd6f4ced6350b0ad56a7013b41526f47e3a2fb/release_20260907.7z.002 - STOCK_RELEASE_MD5: 8cd4edca838fdc226390e3fb04f3ca79 - STOCK_RELEASE_SHA256: e5bea8413adc249f420e08a48e5cdab9b8c5da04bf52d81dc5261f0f350adf66 - STOCK_RELEASE_SIZE: "117936766" + https://raw.githubusercontent.com/MiSTer-devel/SD-Installer-Win64_MiSTer/cd80db9c0ab64ba38be95071a090a80c367d63cf/release_20260912.7z.001 + https://raw.githubusercontent.com/MiSTer-devel/SD-Installer-Win64_MiSTer/cd80db9c0ab64ba38be95071a090a80c367d63cf/release_20260912.7z.002 + STOCK_RELEASE_MD5: 7cec2206e2a1133aa307c541219aa08f + STOCK_RELEASE_SHA256: 35fcbaca57cd2471b1d353f3dd4bae7c7e67256f8c5c8b2d6d5cbcc78269a7ea + STOCK_RELEASE_SIZE: "126546478" STOCK_UBOOT_SHA256: e2d46cf9fe1ec40ca2c9c7409870249f267e06f70e5736dc6d30b4e21fe62a64 STOCK_UBOOT_SIZE: "515141" STOCK_UPDATEBOOT_SHA256: 6ff2d50a080e26d7173b61c52083e9cc42ca658db0c5031b4da1c45c74a562f2 diff --git a/README.md b/README.md index 33f2cde5..296c00a7 100644 --- a/README.md +++ b/README.md @@ -7,7 +7,10 @@ with every MiSTer kernel patch carried in-tree as a plain `.patch` file applied pristine, hash-verified kernel.org tarball. It is a **drop-in replacement**: the unmodified, stock `MiSTer` binary and every existing -core run on it unchanged. +core run on it unchanged. (Since 2026-09-12 that means **Main_MiSTer Release 20260912 or +newer**: the Switch controller's IMU/LED naming fix moved from our kernel to Main_MiSTer +#1307/#1308, so an older `MiSTer` binary on this image sees a phantom IMU pad and dark +Switch player/home LEDs.) ## What ships @@ -87,7 +90,7 @@ mainline can hold it. | | Stock MiSTer | This project | |---|---|---| | **Kernel** | 5.15.1 from Nov 2021 to 2026-09-07 with **zero** `5.15.y` stable updates ever merged; **6.18.38 since Release 20260907**, pinned the same way — 12 `6.18.y` releases behind our pin at the time of writing | **6.18 LTS**, on a live `.y` line with security backports | -| **Kernel delta** | 5.15: 110 commits on a squashed-import fork with no shared ancestry with mainline — so no `merge-base`, and no per-commit disposition. 6.18: a fresh ~70-commit re-port onto a squashed `v6.18.38` import, same shape | **40 patch files** against a pristine tarball, each with provenance, upstream status, and an evidence-backed record | +| **Kernel delta** | 5.15: 110 commits on a squashed-import fork with no shared ancestry with mainline — so no `merge-base`, and no per-commit disposition. 6.18: a fresh ~70-commit re-port onto a squashed `v6.18.38` import, same shape | **38 patch files** against a pristine tarball, each with provenance, upstream status, and an evidence-backed record | | **Buildroot** | 2021.02.4 — **unchanged by Release 20260907** (`/etc/os-release` `PRETTY_NAME`, both releases) | **2026.08** (~5 years of upstream work) | | **glibc / gcc** | 2.31 / gcc 10-era — **unchanged by Release 20260907** (`libc.so.6 → libc-2.31.so`; `strings` shows `GNU C Library (GNU) stable release version 2.31`) | **2.44 / 15.3.0** | | **OpenSSL** | **1.1.1k — EOL since 2023-09-11**, no upstream fixes since; **unchanged by Release 20260907** (`strings usr/lib/libssl.so.1.1`, both releases → `OpenSSL 1.1.1k 25 Mar 2021`) | **3.6.4** | @@ -157,7 +160,7 @@ document records what changed and which rows here it dates). | Phase | State | What that means | |---|---|---| | **0 — Recon & decisions** | ✅ Complete | Patch triage, ABI-contract verification, five open questions decided (ADRs 0010–0014) | -| **1 — Kernel & initramfs** | ✅ Complete | 6.18 LTS pinned; all 40 patches apply cleanly (re-measured 2026-09-11 at `patch -p1 -F0`, 40/40, zero fuzz); `zImage_dtb` builds warning-free, boots under QEMU **and on real hardware** — from the **CI-built artifact**, not a local build | +| **1 — Kernel & initramfs** | ✅ Complete | 6.18 LTS pinned; all 38 patches apply cleanly (40/40 re-measured 2026-09-11 at `patch -p1 -F0`, zero fuzz; `0040`/`0041` retired 2026-09-12 and the surviving hid-nintendo stack re-measured 7/7 on 6.18.51); `zImage_dtb` builds warning-free, boots under QEMU **and on real hardware** — from the **CI-built artifact**, not a local build | | **2 — Rootfs & testing** | ✅ Complete | Buildroot 2026.08, glibc 2.44, reproducible ext4 image with full SBOM; menu and cores load on hardware — the ABI contract holds *in practice*, not just on paper | | **3 — Module packages & HW matrix** | ✅ Complete | Wi-Fi, Bluetooth, controllers and special devices packaged; hardware-validated **for the chips actually present on the one test board**. The v10/v10.1/v10.2 driver + firmware expansion (Broadcom, Wi-Fi 6/6E, MediaTek, Atheros USB, Redpine) is packaged and mostly CI-asserted but **not** hardware-validated — see the [ledger](#hardware-validation-ledger) and the [chipset table](#wi-fi-and-bluetooth-hardware-support). The remaining matrix rows (Samba, MIDI) are build/CI-verified only | | **4 — Release & sustainability** | 🔄 In progress | CI/CD, `db.json` distribution, beta program, governance, publication gate | @@ -337,14 +340,16 @@ The interesting part is not the version number — it's the **shape of the delta fork's **136 reconciled commits** (110 on the `MiSTer-v5.15` branch stock shipped until 2026-09-07, 10 on upstream's own `MiSTer-v6.18` branch — which stock ships *now* — one still-open pull-request head carried ahead of its merge, plus 15 residue commits that -existed only on the older v5.14/v5.13.12 branches) are down to **40 carried patch +existed only on the older v5.14/v5.13.12 branches) are down to **38 carried patch files**. The bulk of that reconciliation was performed against the **5.15** stock kernel and left **36** files; the nine commits and one open PR stock's 6.18 branch has taken since have now been reconciled too — executed, not just planned — in [`docs/kernel-recon/fork-sync-2026-09.md`](docs/kernel-recon/fork-sync-2026-09.md) (plan: [`fork-sync-2026-09/PLAN.md`](docs/kernel-recon/fork-sync-2026-09/PLAN.md)), adding `0048` (Stadia-FF device IDs), `0049` (an 8BitDo adapter fix carried ahead of its -upstream PR merging) and `0050` (an exFAT read-ahead plug, 6.18-series only). Every +upstream PR merging) and `0050` (an exFAT read-ahead plug, 6.18-series only); on +2026-09-12 `0040`/`0041` (Switch IMU and LED names) were retired when upstream chose the +Main_MiSTer-side fix instead (36 + 3 + `0047` − 2 = 38). Every remaining drop is either verifiably in mainline 6.18, replaced by a maintained package, or recorded as a deliberate decision. `0047` is not part of that delta at all — it backports a mainline commit (`ce21a5cf3d1f`, first released in 7.2) that the 6.18.y line @@ -663,9 +668,9 @@ linux/ Config.ext.in + linux-ext-mister-initramfs.mk: the kern extension that embeds package/mister-initramfs's cpio (ADR 0002/0030) board/mister/de10nano/ linux.config minimal kernel defconfig (an absent CONFIG_X is NOT "off") - linux-patches/ 37 carried patches: 36 MiSTer + 1 mainline backport (0047) - linux-patches-beta/ 36 of those (32 symlinks + 4 re-anchored 7.x copies; 0047 is - already in 7.2) + 4 beta-local = the 40-entry series + linux-patches/ 38 carried patches: 37 MiSTer + 1 mainline backport (0047) + linux-patches-beta/ 36 of those (31 symlinks + 5 re-anchored 7.x copies; 0047 and + 0050 are already in 7.2) + 4 beta-local = the 40-entry series linux-patches-upstream/what the exported tree carries but our image must not rootfs-overlay/ init scripts, sshd wiring, MiSTer-specific files post-build.sh /MiSTer.version stamping, parity fixups diff --git a/board/mister/common/linux-mister.fragment b/board/mister/common/linux-mister.fragment index c8a8fb99..093e3702 100644 --- a/board/mister/common/linux-mister.fragment +++ b/board/mister/common/linux-mister.fragment @@ -614,7 +614,8 @@ CONFIG_REGULATOR_FIXED_VOLTAGE=y # LEDs. LEDS_BRIGHTNESS_HW_CHANGED is what linux-patches/0029 teaches leds-gpio # to report; LEDS_USER is /dev/uleds, used by the controller LED tooling; the # multicolour class is what hid-playstation and hid-nintendo register their -# player/lightbar LEDs through (patches 0032/0033/0041/0042). +# player/lightbar LEDs through (patches 0032/0033/0042; hid-nintendo's own +# player LEDs keep mainline's names since 0041 was retired on 2026-09-12). CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y CONFIG_LEDS_CLASS_MULTICOLOR=y diff --git a/board/mister/de10nano/installer-overlay/init b/board/mister/de10nano/installer-overlay/init index a568af78..335155b5 100755 --- a/board/mister/de10nano/installer-overlay/init +++ b/board/mister/de10nano/installer-overlay/init @@ -261,7 +261,8 @@ splash_elapsed() { # Find the HPS LED and take it off its DTS default trigger so brightness writes # stick. Restricted to hps_led* on purpose: other /sys/class/leds entries on a -# MiSTer belong to USB gamepads (patches 0032/0033/0041/0042) and blinking a +# MiSTer belong to USB gamepads (patches 0032/0033/0042, plus hid-nintendo's +# mainline-named player LEDs) and blinking a # user's controller to report SD-card progress would be nonsense. splash_led_init() { splash_led="" diff --git a/board/mister/de10nano/linux-patches-beta/0040-hid-nintendo-imu-name-suffix.patch b/board/mister/de10nano/linux-patches-beta/0040-hid-nintendo-imu-name-suffix.patch deleted file mode 120000 index 79a31b48..00000000 --- a/board/mister/de10nano/linux-patches-beta/0040-hid-nintendo-imu-name-suffix.patch +++ /dev/null @@ -1 +0,0 @@ -../linux-patches/0040-hid-nintendo-imu-name-suffix.patch \ No newline at end of file diff --git a/board/mister/de10nano/linux-patches-beta/0041-hid-nintendo-stock-led-classdev-names.patch b/board/mister/de10nano/linux-patches-beta/0041-hid-nintendo-stock-led-classdev-names.patch deleted file mode 120000 index 4595a415..00000000 --- a/board/mister/de10nano/linux-patches-beta/0041-hid-nintendo-stock-led-classdev-names.patch +++ /dev/null @@ -1 +0,0 @@ -../linux-patches/0041-hid-nintendo-stock-led-classdev-names.patch \ No newline at end of file diff --git a/board/mister/de10nano/linux-patches-beta/series b/board/mister/de10nano/linux-patches-beta/series index 43b4f4e6..52d0416c 100644 --- a/board/mister/de10nano/linux-patches-beta/series +++ b/board/mister/de10nano/linux-patches-beta/series @@ -29,17 +29,23 @@ # mainline commit; 0050 is excluded because 7.x already has mainline's OWN # DIFFERENT solution to the same problem. Retires from linux-patches/ # outright the moment the 6.18.y pin leaves 6.18.y, exactly like 0047. -# The beta series therefore carries 38 of the 40 shared patches plus the 4 -# beta-local ones below — 42 entries — so within the carried set the 7.x +# The beta series therefore carries 36 of the 38 shared patches plus the 4 +# beta-local ones below — 40 entries — so within the carried set the 7.x # and 6.18 kernels diverge only where an upstream API forced a re-anchor. +# (0040 and 0041 are NOT exclusions: they were RETIRED from linux-patches/ +# outright on 2026-09-12 -- upstream chose the userspace fix, Main_MiSTer +# #1307/#1308, shipped in Release 20260912 -- so the count fell from 42.) # 0038-0042 were the last gap: they landed in the shared dir on 2026-07-24, # went unlisted here for three weeks, and were closed on 2026-08-17 once # measured rather than assumed. They needed NO re-anchor — plain symlinks, # applied on 7.2 final at -F0 with offsets only (0038 1, 0039 1, 0040 1, # 0041 2, 0042 5 hunks at an offset, zero fuzz), and `make rt` was green on the -# whole 40-entry series of that date from a clean tree (the list is 42 entries -# now; the 2026-09-11 addition of 0048/0049 was re-verified apply-only at -F0 -# against v7.2.3, 42/42, zero fuzz — `make rt` has not been re-run on 42). +# whole 40-entry series of that date from a clean tree (the list reached 42 +# entries with the 2026-09-11 addition of 0048/0049, re-verified apply-only at +# -F0 against v7.2.3, 42/42, zero fuzz, and is 40 again since the 0040/0041 +# retirement — the surviving hid-nintendo stack re-verified at -F0 on v7.2.5, +# 7/7, zero fuzz, and hid-nintendo.o cross-compiled W=1 clean on the 7.2.5 +# tree; `make linux-rt` has not been re-run on either). # See docs/rt-beta-kernel.md §6. # Keep it that way. The rule is unchanged and the 0047 exclusion above does not # soften it: if a patch will not apply to a newer 7.x release, RE-ANCHOR it here @@ -198,8 +204,6 @@ 0037-hid-playstation-dualsense-mute-btn-z.patch 0038-hid-nintendo-nso-genesis-bt-pid.patch 0039-hid-nintendo-nso-n64-genesis-stock-button-mapping.patch -0040-hid-nintendo-imu-name-suffix.patch -0041-hid-nintendo-stock-led-classdev-names.patch 0042-hid-playstation-stock-lightbar-led-names.patch 0043-dts-uio-doorbells.patch 0044-dts-uio-fpga-regions.patch diff --git a/board/mister/de10nano/linux-patches/0040-hid-nintendo-imu-name-suffix.patch b/board/mister/de10nano/linux-patches/0040-hid-nintendo-imu-name-suffix.patch deleted file mode 100644 index cabad2f3..00000000 --- a/board/mister/de10nano/linux-patches/0040-hid-nintendo-imu-name-suffix.patch +++ /dev/null @@ -1,70 +0,0 @@ -From a6b7e36668f60fee6d2cd8dd142db5237c3b3f1f Mon Sep 17 00:00:00 2001 -From: Sorgelig -Date: Sat, 14 Aug 2021 12:00:00 +0800 -Subject: [PATCH 1/1] hid-nintendo: keep the " IMU" suffix userspace filters on - -The Joy-Con/Pro Controller registers a second input device for the -accelerometer and gyro. Main_MiSTer excludes it from its controller pool -with strstr(name, " IMU") (input.cpp), and that string test is its ONLY -hook -- there is no INPUT_PROP or capability check behind it. - -Stock's names are fixed literals ending in " IMU" / " IMU (Grip)". -Mainline builds the name as "%s (IMU)", which puts '(' immediately after -the space, so strstr(name, " IMU") does not match. The IMU node is then -opened as an ordinary controller: it consumes a device-pool slot, streams -ABS_X/Y/Z/RX/RY/RZ at IMU rate into the input loop, and can be -auto-assigned as a player. - -Silent -- nothing errors, a phantom controller simply appears. - -Dropping the parentheses restores the substring while keeping mainline's -derived-from-the-HID-name form. Restoring stock's fixed literals would -also work, but stock derives the MAIN input device's name from the same -place, and that name is itself gamecontrollerdb-visible -- so the -minimal change is the safer one. - -Provenance ----------- -Origin: Behavioural requirement of stock hid-nintendo.c, whose - imu_name literals ("Nintendo Switch Pro Controller IMU", - "Nintendo Switch Left Joy-Con IMU", ...) all end in " IMU". - Consumers: Main_MiSTer input.cpp:6103, - strstr(input[n].name, " IMU") under a vid == 0x057e gate, AND - SDL2's SDL_gamecontroller.c, SDL_strstr(name, " IMU"). - Nothing in the built rootfs matches the "(IMU)" form. -Author: Daniel J. Ogorchock -- the " IMU" - literals are his, from mainline 4ff5b10840a8 ("HID: nintendo: - add IMU support"). Stock 5.15 simply predates their removal; - it is not a MiSTer-authored delta. -Upstream: Partial revert of 94f18bb19945 (Ryan McClelland, "HID: nintendo: - add support for nso controllers"), which replaced the fixed - literals with "%s (IMU)". Current mainline still uses that. -Forward-port: 5.15 -> 6.18.39, Michael C. Ferguson, 2026-07-24, parity audit - (docs/kernel-recon/fork-sync-2026-07.md §8). One-token change. - -Signed-off-by: Sorgelig -Signed-off-by: Michael C. Ferguson ---- -diff --git a/drivers/hid/hid-nintendo.c b/drivers/hid/hid-nintendo.c -index 624b57c0ffb9..6782abc449f1 100644 ---- a/drivers/hid/hid-nintendo.c -+++ b/drivers/hid/hid-nintendo.c -@@ -2127,7 +2127,17 @@ static int joycon_imu_input_create(struct joycon_ctlr *ctlr) - ctlr->imu_input->uniq = ctlr->mac_addr_str; - ctlr->imu_input->phys = hdev->phys; - -- imu_name = devm_kasprintf(&hdev->dev, GFP_KERNEL, "%s (IMU)", ctlr->input->name); -+ /* -+ * MiSTer: the name must end in the substring " IMU". Main_MiSTer filters -+ * this device out of its controller pool with strstr(name, " IMU") -+ * (input.cpp), which is its ONLY hook -- there is no INPUT_PROP or -+ * capability check behind it. Stock's names are fixed literals ending in -+ * " IMU" / " IMU (Grip)"; mainline's "%s (IMU)" puts a '(' after the -+ * space, so the match fails and the accelerometer/gyro node is opened as -+ * an ordinary controller: it takes a device-pool slot, streams ABS_* at -+ * IMU rate into the input loop, and can be auto-assigned as a player. -+ */ -+ imu_name = devm_kasprintf(&hdev->dev, GFP_KERNEL, "%s IMU", ctlr->input->name); - if (!imu_name) - return -ENOMEM; - diff --git a/board/mister/de10nano/linux-patches/0041-hid-nintendo-stock-led-classdev-names.patch b/board/mister/de10nano/linux-patches/0041-hid-nintendo-stock-led-classdev-names.patch deleted file mode 100644 index 75acf378..00000000 --- a/board/mister/de10nano/linux-patches/0041-hid-nintendo-stock-led-classdev-names.patch +++ /dev/null @@ -1,97 +0,0 @@ -From 60821059c0d3b28b26729fdbe2719e7b4186aaba Mon Sep 17 00:00:00 2001 -From: Sorgelig -Date: Thu, 12 Aug 2021 12:00:00 +0800 -Subject: [PATCH 1/1] hid-nintendo: stock LED classdev names (player1-4, home) - -Every Nintendo Switch controller silently loses userspace control of its -player-number LED row and its home LED. - -Stock registers ":player1"..":player4" (max_brightness 1) -and ":home" (max_brightness 0xF). Mainline moved both to the LED -class naming spec, giving ":green:player-1".."-4" and -- not just a -colour prefix but a different function entirely -- ":blue:player-5" -for the home LED, which is not a player indicator at all. - -Main_MiSTer opens these by exact path (input.cpp, update_num_hw(): -set_led(led_path, ":home", num ? 1 : 15) and ":player1"..":player4"), and -its set_led() treats a failed fopen() as a silent no-op. So under the -mainline names all five writes are discarded with nothing logged: the -player row keeps whatever connect-order pattern the driver picked at probe -and never follows the MiSTer player slot, and the home LED is never lit or -dimmed. Reached on every assign/restore, for 057e:2006/2007/2009/200E and -every NSO pad. - -The ":combo" node added by 0032 is the control case: registered by the same -function about 40 lines away, using stock's naming, and it demonstrably -works. Only the two mainline-renamed nodes were lost, which is why the -breakage went unnoticed. - -max_brightness is left as-is: ours already matches stock (1 and 0xF), and -stock's `num ? 1 : 15` write depends on the 0xF range. - -Provenance ----------- -Origin: Stock hid-nintendo.c: joycon_player_led_names[] = { "player1", - ... } with devm_kasprintf(dev, GFP_KERNEL, "%s:%s", d_name, - joycon_player_led_names[i]), and devm_kasprintf(dev, - GFP_KERNEL, "%s:home", d_name) for the home LED. - Consumer: Main_MiSTer input.cpp update_num_hw()/set_led(). -Author: Sorgelig (stock naming) -Upstream: No -- mainline deliberately moved to the LED class spec. - This is the ABI stock's userspace was written against. -Forward-port: 5.15 -> 6.18.39, Michael C. Ferguson, 2026-07-24, parity audit - (docs/kernel-recon/fork-sync-2026-07.md §8). Expressed as a - direct "%s:player%d" format rather than restoring the string - table, since JC_NUM_LEDS still derives from that table's size. - NOT bench-verified -- needs a Switch pad. - -Signed-off-by: Sorgelig -Signed-off-by: Michael C. Ferguson ---- -diff --git a/drivers/hid/hid-nintendo.c b/drivers/hid/hid-nintendo.c -index 6782abc449f1..a08ccb159874 100644 ---- a/drivers/hid/hid-nintendo.c -+++ b/drivers/hid/hid-nintendo.c -@@ -2355,10 +2355,13 @@ static int joycon_leds_create(struct joycon_ctlr *ctlr) - hid_info(ctlr->hdev, "assigned player %d led pattern", player_led_pattern + 1); - - for (i = 0; i < JC_NUM_LEDS; i++) { -- name = devm_kasprintf(dev, GFP_KERNEL, "%s:%s:%s", -- d_name, -- "green", -- joycon_player_led_names[i]); -+ /* -+ * MiSTer: stock names these ":player1"..":player4". -+ * Mainline moved them to the LED-class spec ("::", -+ * i.e. ":green:player-1"), which Main_MiSTer cannot find -- -+ * see the home-LED comment further down this function. -+ */ -+ name = devm_kasprintf(dev, GFP_KERNEL, "%s:player%d", d_name, i + 1); - if (!name) - return -ENOMEM; - -@@ -2417,10 +2420,20 @@ static int joycon_leds_create(struct joycon_ctlr *ctlr) - - /* configure the home LED */ - if (jc_type_has_right(ctlr)) { -- name = devm_kasprintf(dev, GFP_KERNEL, "%s:%s:%s", -- d_name, -- "blue", -- LED_FUNCTION_PLAYER5); -+ /* -+ * MiSTer: stock names this ":home". Mainline renamed it to -+ * ":blue:player-5" -- not just a colour prefix but a different -+ * function entirely, since the home LED is not a player indicator. -+ * -+ * Main_MiSTer opens these by exact path (input.cpp update_num_hw(): -+ * set_led(led_path, ":home", ...) and ":player1"..":player4"), and -+ * set_led() treats a failed fopen() as a silent no-op -- so under the -+ * mainline names every write is discarded with nothing logged: the -+ * player row never follows the MiSTer player slot and the home LED -+ * never lights. The ":combo" node added by 0032 is the control case: -+ * it uses stock's naming and works. -+ */ -+ name = devm_kasprintf(dev, GFP_KERNEL, "%s:home", d_name); - if (!name) - return -ENOMEM; - diff --git a/board/mister/de10nano/linux-patches/0049-hid-nintendo-8bitdo-adapter-skip-baudrate.patch b/board/mister/de10nano/linux-patches/0049-hid-nintendo-8bitdo-adapter-skip-baudrate.patch index 408d51c8..29502e55 100644 --- a/board/mister/de10nano/linux-patches/0049-hid-nintendo-8bitdo-adapter-skip-baudrate.patch +++ b/board/mister/de10nano/linux-patches/0049-hid-nintendo-8bitdo-adapter-skip-baudrate.patch @@ -115,10 +115,12 @@ Rebased: Re-anchored against our own hid-nintendo.c stack rather from THAT stacked, already-patched tree against our own corrected joycon_init() (see "Deviation from PR #92" below), not from the raw PR #92 diff, so their @@ line - numbers are exact for our 6.18.49-plus-eight-patches - series and this patch applies at -F0 with zero offset when - it runs in its correct series position (immediately after - 0041). + numbers were exact for the 6.18.49-plus-eight-patches + series. 0040 and 0041 were RETIRED on 2026-09-12 (their + fix moved to Main_MiSTer #1307/#1308), so this patch now + runs directly after 0039 and lands at -F0 with a -23 line + offset on 6.18.51 (offsets only, zero fuzz) -- that offset + is the two missing patches, not rot. Deviation from PR #92: PR #92's own reorder, applied verbatim, regresses a case vanilla handles correctly. Vanilla 6.18.49 @@ -183,7 +185,9 @@ Forward-port: Verified at -F0 against 6.18.49 as described above (zero stack) on v7.2.3 after the beta versions of 0015, 0032, 0034, 0035, 0038, 0039, 0040, 0041 (0015 is a real re-anchored copy in linux-patches-beta/, the other seven - are symlinks to these de10nano originals). Both apply + were symlinks to these de10nano originals; 0040/0041 are + gone since 2026-09-12 and the six-patch stack re-verified + at -F0 on v7.2.5, zero fuzz). Both apply proofs, and the deviation described above, were re-measured in Wave 4 (code-review 2026-09-11) against the regenerated diff in this patch, not the original Wave 3 diff --git a/board/mister/de25nano/linux-patches/0040-hid-nintendo-imu-name-suffix.patch b/board/mister/de25nano/linux-patches/0040-hid-nintendo-imu-name-suffix.patch deleted file mode 120000 index e769b139..00000000 --- a/board/mister/de25nano/linux-patches/0040-hid-nintendo-imu-name-suffix.patch +++ /dev/null @@ -1 +0,0 @@ -../../de10nano/linux-patches/0040-hid-nintendo-imu-name-suffix.patch \ No newline at end of file diff --git a/board/mister/de25nano/linux-patches/0041-hid-nintendo-stock-led-classdev-names.patch b/board/mister/de25nano/linux-patches/0041-hid-nintendo-stock-led-classdev-names.patch deleted file mode 120000 index d8f33260..00000000 --- a/board/mister/de25nano/linux-patches/0041-hid-nintendo-stock-led-classdev-names.patch +++ /dev/null @@ -1 +0,0 @@ -../../de10nano/linux-patches/0041-hid-nintendo-stock-led-classdev-names.patch \ No newline at end of file diff --git a/board/mister/de25nano/linux-patches/README.md b/board/mister/de25nano/linux-patches/README.md index 50221f3f..ed34eede 100644 --- a/board/mister/de25nano/linux-patches/README.md +++ b/board/mister/de25nano/linux-patches/README.md @@ -71,8 +71,8 @@ Source of the verdicts: [`docs/de25-patch-portability.md`](../../../../docs/de25 | 31 | `0037-hid-playstation-dualsense-mute-btn-z` | portable-as-is / shared | **included (beta copy)** | **Functional, not cosmetic**: `BTN_Z` shifts every higher `EV_KEY` ordinal, so the shipped `gamecontrollerdb` `platform:MiSTer` rows depend on it. Beta copy differs by hunk offsets only. | | 32 | `0038-hid-nintendo-nso-genesis-bt-pid` | portable-as-is / shared | **included** | `hdev->product` rewrite before `devm_input_allocate_device()`. | | 33 | `0039-hid-nintendo-nso-n64-genesis-stock-button-mapping` | portable-as-is / shared | **included** | Static mapping-table reassignment (userspace ABI). | -| 34 | `0040-hid-nintendo-imu-name-suffix` | portable-as-is / shared | **included** | One format-string token Main_MiSTer filters on. | -| 35 | `0041-hid-nintendo-stock-led-classdev-names` | portable-as-is / shared | **included** | `devm_kasprintf()` format restoring stock LED names. | +| 34 | `0040-hid-nintendo-imu-name-suffix` | portable-as-is / shared | **retired 2026-09-12** | Was: one format-string token Main_MiSTer filters on. Upstream closed our kernel PR (Linux-Kernel_MiSTer #96) in favour of the userspace fix, Main_MiSTer #1307 (Release 20260912 onward), so the patch was deleted from the shared series and this link with it. | +| 35 | `0041-hid-nintendo-stock-led-classdev-names` | portable-as-is / shared | **retired 2026-09-12** | Was: `devm_kasprintf()` format restoring stock LED names. Same outcome as `0040`: Linux-Kernel_MiSTer #97 closed, Main_MiSTer #1308 falls back to the mainline `:green:player-N`/`:blue:player-5` names. | | 36 | `0042-hid-playstation-stock-lightbar-led-names` | portable-as-is / shared | **included** | LED-class/HID only. | | 37 | `0043-dts-uio-doorbells` | board-specific / de10-only *(beta)* | **excluded** | Eight `generic-uio` nodes on Cyclone V GIC SPI 48–55; DP-9 adopts Agilex-native idioms instead. `CONFIG_CMDLINE_EXTEND` does not exist on arm64. | | 38 | `0044-dts-uio-fpga-regions` | board-specific / de10-only *(beta)* | **excluded** | Cyclone V lwhps2fpga/f2sdram apertures; depends on the `mem=511M` bootarg. | @@ -81,7 +81,7 @@ Source of the verdicts: [`docs/de25-patch-portability.md`](../../../../docs/de25 | — | `0047-btusb-mercusys-ma530-2c4e-0115` | *post-audit (added 2026-09-02)* | **excluded** | Not in the audit; it is a **backport of a mainline commit that is already in v7.2**. Its own header says "DELETE THIS PATCH the moment the kernel pin leaves 6.18.y for 7.2 or newer — at that point the ID is in-tree and re-adding it would collide." This board is on 7.2.3 (7.2.2 when this row was written), so the ID is already present. (It is likewise absent from `linux-patches-beta/series`.) | | — | `0021` | — | n/a | No such patch; the DE10 series has never had one. | | — | `0048-hid-google-stadiaff-classic2usb-retrozord` | *post-audit (added 2026-09-11)* | **included** | Not in the audit; two `hid_device_id` rows (Classic2USB `16d0:1460`, RetroZord `1209:595a`) in `drivers/hid/hid-google-stadiaff.c`, matched with `HID_GROUP_GENERIC` — a USB ID table has no architecture. Main_MiSTer-coupled (`input.cpp:52-53`, `:4176-4177`, `:5102`, `:5349`, `:5496`), so it must not drop silently. Applies clean at `-F0` on 7.2.3 (offset 0). | -| — | `0049-hid-nintendo-8bitdo-adapter-skip-baudrate` | *post-audit (added 2026-09-11)* | **included** | Not in the audit; carried from open PR #92 ahead of merge (owner decision D3) — reorders `joycon_init()`'s USB handshake/baudrate block after `joycon_read_info()` and skips it for 8BitDo-adapter MACs (`E4:17:D8` OUI). USB-generic HID probe-path logic, no architecture exposure. Applies clean at `-F0` on 7.2.3 (offsets only, zero fuzz) after this board's own `0015`/`0032`/`0034`/`0035`/`0038`-`0041` hid-nintendo stack. | +| — | `0049-hid-nintendo-8bitdo-adapter-skip-baudrate` | *post-audit (added 2026-09-11)* | **included** | Not in the audit; carried from open PR #92 ahead of merge (owner decision D3) — reorders `joycon_init()`'s USB handshake/baudrate block after `joycon_read_info()` and skips it for 8BitDo-adapter MACs (`E4:17:D8` OUI). USB-generic HID probe-path logic, no architecture exposure. Applies clean at `-F0` on 7.2.3 (offsets only, zero fuzz) after this board's own `0015`/`0032`/`0034`/`0035`/`0038`/`0039` hid-nintendo stack (`0040`/`0041` were in that stack until their 2026-09-12 retirement; the remaining seven re-verified at `-F0` on v7.2.5, zero fuzz). | | — | `0050-exfat-dir-readahead-plug` | *post-audit (added 2026-09-11)* | **excluded** — 7.2.3 already carries mainline's plugged read-ahead (`fs/exfat/fatent.c` `exfat_blk_readahead`); the 6.18 hunk fails at `-F0` there | A 4-line `blk_start_plug`/`blk_finish_plug` wrap of `exfat_dir_readahead()`'s `sb_breadahead()` loop — but that function does not exist on 7.x at all. `git show v7.2.3:fs/exfat/dir.c` has no `exfat_dir_readahead` and no `blk_start_plug`; the equivalent batching already lives in `exfat_get_dentry()` + `exfat_blk_readahead()` (`fs/exfat/fatent.c:159-183`). Measured: `patch -p1 -F0 --dry-run` against pristine v7.2.3 `fs/exfat/dir.c` reports "Hunk #1 FAILED at 6. Hunk #2 FAILED at 682. 2 out of 2 hunks FAILED". 6.18-series-only per this board's own `linux-patches-beta/series` exclusion (same reasoning, mirror image of `0047`); retires from `linux-patches/` outright when the 6.18.y pin leaves 6.18.y. | ### DE25-local patches (not in the audit — new work) @@ -96,11 +96,11 @@ Source of the verdicts: [`docs/de25-patch-portability.md`](../../../../docs/de25 | | | |---|---| | Audit rows | 40 | -| Included from the audit | **32** (all 32 `portable-as-is` + `shared` rows) | +| Included from the audit | **30** (32 `portable-as-is` + `shared` rows, minus the two retired on 2026-09-12 — `0040`, `0041`) | | Excluded from the audit | **8** — 7 `de10-only` (`0001` `0003` `0004` `0043` `0044` `0045` `0046`) + `0002` (`portable-with-rework`, deferred) | | Post-audit patches considered | 3 (`0047` excluded — already upstream at 7.2; `0048`, `0049` included — 2026-09-11; `0050` excluded — 7.2.3 already carries mainline's own plugged read-ahead, 2026-09-11) | | DE25-local patches | **2** (`0101`, `0102`) | -| **Total applied here** | **36** | +| **Total applied here** | **34** | ## Note for the DE25 DTS diff --git a/docs/buildroot-config.md b/docs/buildroot-config.md index bd432aa2..76088a6d 100644 --- a/docs/buildroot-config.md +++ b/docs/buildroot-config.md @@ -2810,10 +2810,12 @@ function does not exist on 7.x at all — mainline's own differently-shaped fix (exfat_get_dentry() + exfat_blk_readahead() in fs/exfat/fatent.c) is already in v7.2.3, and at -F0 against pristine v7.2.3 both hunks FAIL. Both go away on their own the day the stock pin leaves 6.18.y. Nothing else is dropped: -all 42 entries (the other 38 shared + the four beta-local +all 40 entries (the other 36 shared + the four beta-local patches 0043/0044/0045 — the UIO set — and 0046, the ramoops crash-record reservation) apply at -F0 — verified 2026-09-11 against v7.2.3 with the two -newly-shared patches 0048/0049 symlinked in (42/42, zero fuzz), and before +newly-shared patches 0048/0049 symlinked in (42/42, zero fuzz; 40 since the +2026-09-12 retirement of 0040/0041, which are deleted, not excluded — the +userspace side took the fix, Main_MiSTer #1307/#1308), and before that on the then-40-entry series on 7.2 FINAL, verified 2026-08-17 through Buildroot's own `apply-patches.sh` against a freshly extracted pristine `linux-7.2.tar.xz` whose sha256 matched the signed manifest: 40/40 applied, diff --git a/docs/ci.md b/docs/ci.md index 238e3185..7ebc4a1b 100644 --- a/docs/ci.md +++ b/docs/ci.md @@ -1311,16 +1311,18 @@ commit-pinned stock archive `docs/reference-materials.md` / ``` https://raw.githubusercontent.com/MiSTer-devel/SD-Installer-Win64_MiSTer/ - 76fd6f4ced6350b0ad56a7013b41526f47e3a2fb/release_20260907.7z.001 (83,886,080 bytes) + cd80db9c0ab64ba38be95071a090a80c367d63cf/release_20260912.7z.001 (83,886,080 bytes) https://raw.githubusercontent.com/MiSTer-devel/SD-Installer-Win64_MiSTer/ - 76fd6f4ced6350b0ad56a7013b41526f47e3a2fb/release_20260907.7z.002 (34,050,686 bytes) + cd80db9c0ab64ba38be95071a090a80c367d63cf/release_20260912.7z.002 (42,660,398 bytes) joined, in that order, into stock_release.7z: -MD5 8cd4edca838fdc226390e3fb04f3ca79 -SHA-256 e5bea8413adc249f420e08a48e5cdab9b8c5da04bf52d81dc5261f0f350adf66 -117,936,766 bytes +MD5 7cec2206e2a1133aa307c541219aa08f +SHA-256 35fcbaca57cd2471b1d353f3dd4bae7c7e67256f8c5c8b2d6d5cbcc78269a7ea +126,546,478 bytes ``` -**Two URLs, one archive (since the 2026-09 bump to `release_20260907`).** +**Two URLs, one archive (since the 2026-09 bump to `release_20260907`; the +pin moved on to `release_20260912` on 2026-09-12 — see +`docs/verification/stock-release-20260912.md`).** Upstream now commits each release as split 7z volumes — consecutive byte slices of a single archive, not two archives — so `STOCK_RELEASE_URL` is a whitespace-separated list in volume order and `fetch-stock` concatenates @@ -1329,15 +1331,20 @@ three pins are those of the **joined** file: they cover every byte of every volume, so a missing, truncated or reordered volume fails them just as loudly as a wrong single file did, and they are exactly what the on-device `7za` sees. `Distribution_MiSTer` does the same join on its side and mirrors -the result as `linux_release_20260907.7z` on its `all_releases` release; that -mirror was fetched and is byte-identical to our join -(`docs/verification/stock-release-20260907.md` §1/§6). The previous pin, -`release_20250402.7z` at `b8531c78…` (MD5 `8dc3acae…`, 93,727,644 bytes), -differs from this one in `files/linux/` in three members — `linux.img` and -`zImage_dtb`, which we replace with our own and never ship, and `MidiLink.INI`, -the **one shipped file** that changed; `uboot.img` and `updateboot` are -byte-identical across the two, so the `STOCK_UBOOT_*`/`STOCK_UPDATEBOOT_*` pins -did not move. +the result as `linux_release_.7z` on its `all_releases` release; the +20260907 mirror was fetched and is byte-identical to our join +(`docs/verification/stock-release-20260907.md` §1/§6), while no mirror of +20260912 existed yet when the pin moved. The previous pin, +`release_20260907.7z` at `76fd6f4c…` (MD5 `8cd4edca…`, 117,936,766 bytes), +differs from this one in exactly three members — `files/linux/linux.img` and +`files/linux/zImage_dtb`, which we replace with our own and never ship, and +`files/MiSTer`, the **one shipped file** that changed (the Main_MiSTer +20260912 build, which carries the Switch IMU/LED name fallbacks our kernel +stopped patching in the same PR); nothing else in `files/linux/` moved, and +`uboot.img` and `updateboot` are byte-identical across the two, so the +`STOCK_UBOOT_*`/`STOCK_UPDATEBOOT_*` pins did not move. (The bump before +that, 20250402 → 20260907, changed `MidiLink.INI` and the same two kernel +files.) All three (MD5, SHA-256, size) are checked BEFORE anything is extracted from it. Individual `uboot.img`/`updateboot` hashes are re-checked too diff --git a/docs/de25-kernel-config.md b/docs/de25-kernel-config.md index 3c72de33..51f94898 100644 --- a/docs/de25-kernel-config.md +++ b/docs/de25-kernel-config.md @@ -295,7 +295,7 @@ Cores and userland ABIs only: `I2C` + `I2C_CHARDEV` + `I2C_SMBUS` + `I2C_GPIO` (with `# CONFIG_I2C_HELPER_AUTO is not set`), `GPIOLIB` + `GPIO_SYSFS`, `WATCHDOG`, `REGULATOR` + `REGULATOR_FIXED_VOLTAGE`, `HW_RANDOM`, the LED class set (`LEDS_CLASS_MULTICOLOR` is what hid-playstation and hid-nintendo register -player/lightbar LEDs through — patches 0032/0033/0041/0042; +player/lightbar LEDs through — patches 0032/0033/0042 (0041 retired 2026-09-12); `LEDS_BRIGHTNESS_HW_CHANGED` is what 0029 teaches leds-gpio to report; `LEDS_USER` is `/dev/uleds`), and the three I2C RTC parts MiSTer add-on boards fit ([`rtc-parity.md`](rtc-parity.md)). diff --git a/docs/de25-patch-portability.md b/docs/de25-patch-portability.md index 5cd59961..ebb90927 100644 --- a/docs/de25-patch-portability.md +++ b/docs/de25-patch-portability.md @@ -154,8 +154,8 @@ construction. ⚠ marks a row where the deep dive overturned or materially corre | 31 | `0037-hid-playstation-dualsense-mute-btn-z` | hid | 🟢 | portable-as-is | shared | **Functional, not cosmetic.** `BTN_Z` (0x135) sits between `BTN_WEST` and `BTN_TL` and shifts every higher `EV_KEY` ordinal, so the shipped `gamecontrollerdb` `platform:MiSTer` rows depend on it. The RT beta drops it; that is a **known divergence, not a precedent**. Beta copy differs by hunk offsets only. | `patch-provenance.md:370`, `:1222`, `:1537` | | 32 | `0038-hid-nintendo-nso-genesis-bt-pid` | hid | 🟢 | portable-as-is | shared | 20-line `hdev->product` rewrite keyed off a controller-reported type byte, before `devm_input_allocate_device()`. | — | | 33 | `0039-hid-nintendo-nso-n64-genesis-stock-button-mapping` | hid | 🟢 | portable-as-is | shared | Reassigns evdev codes in two static mapping tables to stock's order. Not bench-verified against real pads — a testing gap, **not** a portability risk. | — | -| 34 | `0040-hid-nintendo-imu-name-suffix` | hid | 🟢 | portable-as-is | shared | One format-string token (`"%s (IMU)"` → `"%s IMU"`) restoring the substring Main_MiSTer filters on. | — | -| 35 | `0041-hid-nintendo-stock-led-classdev-names` | hid | 🟢 | portable-as-is | shared | `devm_kasprintf()` format change restoring stock's flat LED names so Main_MiSTer's hardcoded `fopen()` paths resolve. | — | +| 34 | `0040-hid-nintendo-imu-name-suffix` | hid | 🟢 | portable-as-is | shared | One format-string token (`"%s (IMU)"` → `"%s IMU"`) restoring the substring Main_MiSTer filters on. **Retired 2026-09-12** — fixed in userspace instead (Main_MiSTer #1307, Release 20260912); no longer in any series. | — | +| 35 | `0041-hid-nintendo-stock-led-classdev-names` | hid | 🟢 | portable-as-is | shared | `devm_kasprintf()` format change restoring stock's flat LED names so Main_MiSTer's hardcoded `fopen()` paths resolve. **Retired 2026-09-12** — fixed in userspace instead (Main_MiSTer #1308, Release 20260912); no longer in any series. | — | | 36 | `0042-hid-playstation-stock-lightbar-led-names` | hid | 🟢 | portable-as-is | shared | Adds stock-compatible R/G/B LED classdevs alongside mainline's multicolor device, using an explicit back-pointer+index instead of `container_of()`. LED-class/HID only. | — | | 37 | `0043-dts-uio-doorbells` ⚠ | dts (uio) | 🔴 | board-specific | de10-only *(beta)* | Eight interrupt-only `generic-uio` nodes on Cyclone V GIC SPI 48–55 (`f2h_irq8..15`). Triage said `drop`; **overturned — it ships on DE10.** Deep dive added: **`CONFIG_CMDLINE_EXTEND` does not exist on arm64**, so the DE10 binding recipe has no arm64 counterpart. Not ported to DE25 per DP-9. | **none exists** (see §1); `de25-nano-plan.md:211-218`; `de25-fpga-reconfig.md` §8 | | 38 | `0044-dts-uio-fpga-regions` ⚠ | dts (uio) | 🔴 | board-specific | de10-only *(beta)* | Two reg-bearing UIO nodes: the 2 MiB lwhps2fpga window at `0xff200000` (never write-combined) and the 512 MiB f2sdram DDR aperture at `0x20000000` (WC-capable). Triage said `drop`; **overturned.** Depends on the `mem=511M` bootarg. Not ported per DP-9. | **none exists**; `de25-nano-plan.md:213-219` | @@ -602,6 +602,9 @@ sense — but it is the project's known trap for a *different* reason: `BTN_Z` ( precedent.** It must be in the shared series on both boards, because the same Main_MiSTer userspace reads the same database on both. The same reasoning applies to `0034`, `0039`, `0040`, `0041` and `0042`: they *look* cosmetic (table swaps, format strings) and are **userspace ABI**. +(`0040` and `0041` have since been retired, 2026-09-12: the ABI mismatch was closed from the +other side, Main_MiSTer #1307/#1308 accepting the mainline names, which is the same argument +resolved the other way — the stakes were real, the fix just did not have to be in the kernel.) An arch audit that filed them as "trivially portable, low value" would be right about the arch and wrong about the stakes. diff --git a/docs/downloader-contract.md b/docs/downloader-contract.md index 81701b51..9774682a 100644 --- a/docs/downloader-contract.md +++ b/docs/downloader-contract.md @@ -1046,6 +1046,10 @@ prevent. > (`release.yml`'s `STOCK_RELEASE_URL`, now a two-URL list that `verify-stock-payload.sh` > joins) — see `docs/verification/stock-release-20260907.md` §6. Full analysis of the > release itself is in that document; the entry below is kept as the verified record. +> +> **2026-09-12:** stock released `release_20260912` (joined MD5 `7cec2206…`, 126,546,478 B — +> now our `STOCK_RELEASE_*` pin, `docs/verification/stock-release-20260912.md`); no +> `linux_release_20260912.7z` mirror asset existed and db.json still had `"linux": null`. As a cross-check that every field above is understood correctly (not just asserted), here is the `Distribution_MiSTer` `linux` entry that was **live until 2026-09**, reproduced from diff --git a/docs/kernel-export.md b/docs/kernel-export.md index afd7bbb8..5549b931 100644 --- a/docs/kernel-export.md +++ b/docs/kernel-export.md @@ -68,12 +68,14 @@ alone broke his `make` target). Now it is yes, modulo the review-thread items in Recorded so nobody "fixes" them backwards (details and evidence in `docs/kernel-recon/fork-sync-2026-07.md` §3 and `fork-sync-2026-09/STATUS.md`): -- Our `0039`–`0042` (N64/Genesis button maps, IMU name suffix, LED classdev names, lightbar - names) restore **stock 5.15** behaviour that his 6.18 port does not carry. (`0038`, the NSO - Genesis Bluetooth PID normalization, he *does* have — measured in Wave 5, correcting the - Wave 4 tree-diff's first reading.) Ready-to-send patches for the four, plus the `BTN_Z` - scoping and the framebuffer `memremap()` check, are prepared under - `docs/kernel-recon/fork-sync-2026-09/upstream-candidates/` — **prepared, not sent**. +- Our `0039` and `0042` (N64/Genesis button maps, lightbar names) restore **stock 5.15** + behaviour his 6.18 port did not carry. (`0038`, the NSO Genesis Bluetooth PID normalization, + he *does* have — measured in Wave 5, correcting the Wave 4 tree-diff's first reading.) + Sent 2026-09-12: `0039` merged as Linux-Kernel_MiSTer #95 and the `memremap()` check as #98; + the IMU-name and LED-name patches (#96/#97) were **closed** for the Main_MiSTer-side fix + (#1307/#1308), and our `0040`/`0041` were retired the same day — so those two no longer + differ. `0042` and the `BTN_Z` scoping are still under + `docs/kernel-recon/fork-sync-2026-09/upstream-candidates/`, unsent. - `BTN_Z` is DualSense-only in ours (as in stock 5.15); his port declares it for DualShock 4 too. - His `spidev` `altspi` compatible and `vt.h` `MAX_NR_CONSOLES 63→9` are dropped in ours. - His cpufreq port (#85) is not adopted; we keep `0003` (decision D1) and carry only its OCRAM @@ -86,14 +88,15 @@ Recorded so nobody "fixes" them backwards (details and evidence in Measured against `MiSTer-v6.18` @ `c129b0fac` and Release 20260907 during the 2026-09 increment. "Prepared" means a ready-to-send patch or comment exists under -`docs/kernel-recon/fork-sync-2026-09/upstream-candidates/`; nothing has been sent (owner decision). +`docs/kernel-recon/fork-sync-2026-09/upstream-candidates/`. Rows 2, 4 (in part) and 5 were sent +on 2026-09-12 — see each row's status. | # | Deficiency | Evidence | Status upstream | Our artefact / suggested action | |---|---|---|---|---| | 1 | **Shipped release regressions.** Release 20260907 (= `aec7dc3aa`) ships with `mmap(/dev/fb0)` returning `-ENODEV` (Console Mode / SDL fbcon cannot start), no driver for RTL8811AU/8821AU (`CONFIG_RTW88_8821AU` off), and no cpufreq/overclock driver at all | shipped config + module list (`fork-sync-2026-09/evidence/`) | all three fixed on the branch after the release (#83, #81, #85) but **not yet in any shipped release** | nothing to submit; worth asking for a point release. Users on stock are affected until then | | 2 | `MiSTer_fb.c` tests a `memremap()` result with `IS_ERR()`; `memremap()` returns NULL, so a failed mapping falls through to an oops with a stale `devm_ioremap_resource` message | `tree-diff-2026-09.md` F1; our `0001` has the correct check (README bug B2) | open | **prepared: `07-fbdev-mister-fb-memremap-null-check.patch`** | | 3 | **PR #92 (open) regresses USB controllers that do not answer the first handshake**: the moved baudrate block is gated on `using_usb && !8bitdo` instead of on the first handshake having succeeded, so vanilla's "assume BLE pro controller, run at default baud" fallback becomes a fatal second handshake | code review of our `0049` (2026-09-11); vanilla `joycon_init()` quoted in the note | open PR | **prepared: `08-hid-nintendo-pr92-handshake-fallback.NOTE.md`** (review comment + one-variable fix); our `0049` carries the corrected form | -| 4 | Stock-5.15 controller behaviour the 6.18 port lost, all Main_MiSTer-coupled: NSO N64/Genesis button maps differ from stock (SDL `gamecontrollerdb` rows shift), IMU input device not named `" IMU"` (Main_MiSTer opens it as a phantom pad), LED classdevs not named `player1..4`/`home`, lightbar LEDs not named `:red/:green/:blue` | records `b00a72159`, `45283785a`, `60821059c`, `f84543926`; `tree-diff-2026-09.md` §b | open | **prepared: patches `02`–`05`** | +| 4 | Stock-5.15 controller behaviour the 6.18 port lost, all Main_MiSTer-coupled: NSO N64/Genesis button maps differ from stock (SDL `gamecontrollerdb` rows shift), IMU input device not named `" IMU"` (Main_MiSTer opens it as a phantom pad), LED classdevs not named `player1..4`/`home`, lightbar LEDs not named `:red/:green/:blue` | records `b00a72159`, `45283785a`, `60821059c`, `f84543926`; `tree-diff-2026-09.md` §b | button maps **merged** (#95); IMU/LED names **closed** (#96/#97) — fixed in Main_MiSTer #1307/#1308 instead, our `0040`/`0041` retired; lightbar names open | `02` sent+merged; `03`/`04` sent+closed; **`05` still prepared, unsent** | | 5 | `BTN_Z` declared in the shared PlayStation button table, so DualShock 4 gains a button stock 5.15 never exposed on it | `fork-sync-2026-07.md` §3 | open | **prepared: `06-hid-playstation-dualsense-btn-z-scoping.patch`** (behaviour change for DS4 users stated in the draft) | | 6 | **AIC8800 driver vendored without a licence**: 139 files, 85 with a bare copyright line and no grant, 51 with nothing, 2 Apache-2.0 (`aic_br_ext.{c,h}`, GPLv2-incompatible), no `LICENSE`/`README`; needs ~60 firmware blobs that no shipped `firmware.tar.gz` contains; a `wext` shim; SDK snapshot `rwnx v6.4.3.0 - 1a4b0054d2M` | `memo-Q9-aic8800.md` §1.3, §2 | landed 2026-09-11 | not a patch: raise as an issue — name the upstream repo/commit, add its licence text, ship the firmware (or say where it comes from), consider out-of-tree packaging | | 7 | cpufreq port (#85) open items by its own author: 1200 MHz long-duration untested, MiSTer Pi/SuperStation untested, "OSD movement during scripts" unexplained, boost-off harness not re-run; and its OCRAM `flags-sram` rationale is wrong (Main_MiSTer's flags are in DDR at `0x1FFFF000`) | `memo-Q4-cpufreq.md` §2, §6 | landed | none to submit; worth a note that the reservation is hygiene, not a Main_MiSTer requirement | diff --git a/docs/kernel-recon/device-support.md b/docs/kernel-recon/device-support.md index 4ace1609..86dd7d28 100644 --- a/docs/kernel-recon/device-support.md +++ b/docs/kernel-recon/device-support.md @@ -1,6 +1,6 @@ # Device-ID inventory -Generated 2026-09-11 03:37 UTC. VID:PID → commits and dispositions (how each device's support is covered in the 6.18 build). +Generated 2026-09-12 17:05 UTC. VID:PID → commits and dispositions (how each device's support is covered in the 6.18 build). | Device | Commits (disposition) | |---|---| diff --git a/docs/kernel-recon/disagreements-with-provenance.md b/docs/kernel-recon/disagreements-with-provenance.md index 14863be1..d360f172 100644 --- a/docs/kernel-recon/disagreements-with-provenance.md +++ b/docs/kernel-recon/disagreements-with-provenance.md @@ -1,6 +1,6 @@ # Disagreements with docs/patch-provenance.md -Generated 2026-09-11 03:37 UTC. Every record where independent re-derivation contradicts the prior doc — each was a candidate `60e08955f`-class error; all are tier-2 verified. +Generated 2026-09-12 17:05 UTC. Every record where independent re-derivation contradicts the prior doc — each was a candidate `60e08955f`-class error; all are tier-2 verified. ## `45283785a` hid-nintendo: add virtual combo led, don't warn by IMU compensation. diff --git a/docs/kernel-recon/fork-sync-2026-09.md b/docs/kernel-recon/fork-sync-2026-09.md index 874f1a67..37e06c59 100644 --- a/docs/kernel-recon/fork-sync-2026-09.md +++ b/docs/kernel-recon/fork-sync-2026-09.md @@ -213,11 +213,12 @@ Measured against the shipped Release 20260907 config/module list, not inferred ( | `mmap(/dev/fb0)` → `-ENODEV`; Console Mode broken | fixed in `0001` (2026-07) | yes, #83 (Q3) | | No driver for RTL8811AU/8821AU dongles | `rtw88_8821au` since v10 | yes, #81 (Q2) | | No cpufreq/overclock at all | `0003` | yes, #85 (Q4), different design — kept ours | -| NSO Genesis BT PID, N64/Genesis button maps, IMU name suffix, LED classdev names, DS lightbar names | `0038`-`0042` | **no** — upstream's port still lacks them | +| NSO Genesis BT PID, N64/Genesis button maps, IMU name suffix, LED classdev names, DS lightbar names | `0038`-`0042` | **no** at the time — upstream's port still lacked them. *Update 2026-09-12:* `0038` he already had; `0039` merged as #95; `0040`/`0041` **closed** as #96/#97 in favour of Main_MiSTer #1307/#1308 and retired from our series; `0042` unsent | | 8BitDo USB Wireless Adapter reset loop | fixed this increment, `0049` | PR #92, still open | The `0038`-`0042` row remains the material for an optional Wave 5 (upstream PRs carrying what -stock 6.18 users are missing) — not actioned in this increment. +stock 6.18 users are missing) — not actioned in this increment. (Actioned 2026-09-12; see +`fork-sync-2026-09/STATUS.md` D6 for the outcome.) --- diff --git a/docs/kernel-recon/fork-sync-2026-09/STATUS.md b/docs/kernel-recon/fork-sync-2026-09/STATUS.md index 28d078fb..9504be5d 100644 --- a/docs/kernel-recon/fork-sync-2026-09/STATUS.md +++ b/docs/kernel-recon/fork-sync-2026-09/STATUS.md @@ -98,7 +98,7 @@ patches as carried before they exist. | D3 | Carry the open PR #92 now | **Yes.** | "Gamepad unusable" class, hardware-verified A/B by its author on a DE10-Nano at 6.18.38, 32 lines, applies clean on top of our whole hid-nintendo stack on both kernels; Main_MiSTer hard-codes `057e_2009`. | yes | | D4 | Align `0001` to upstream's `fb_sys_read/write` | **Yes** (also the beta copy). | Proven identical machine code on ARM; Main_MiSTer only ioctls `/dev/fb0`; shrinks the export diff. | follow the memo: yes | | D5 | Run the two Opus workers | moot — they ran (≈0.50 M tokens total) | — | — | -| D6 | Wave 5 upstream PRs for `0039`–`0042` (+ `BTN_Z` scoping, + the fork's `memremap()` check) | **prepared, not sent** — six patches + PR drafts under `upstream-candidates/`; opening them is the owner's call after reading the PR #75 thread | — | nothing is sent | +| D6 | Wave 5 upstream PRs for `0039`–`0042` (+ `BTN_Z` scoping, + the fork's `memremap()` check) | ~~**prepared, not sent**~~ **SENT 2026-09-12** as Linux-Kernel_MiSTer #95 (`0039`), #96 (`0040`), #97 (`0041`), #98 (`memremap()`), plus config PRs #93/#94. #93/#94/#95/#98 merged; **#96/#97 closed** — the maintainer took the Main_MiSTer alternatives (#1307/#1308, Release 20260912), so `0040`/`0041` were retired from our series the same day. `0042` and the `BTN_Z` scoping remain unsent. | — | see row | ## 4. Hardware-gated items (for when you are at the board) @@ -199,7 +199,7 @@ classdev names, `0042` stock lightbar names, `0037`'s DualSense-only `BTN_Z` sco fix — each applying at `-F0`/`git am` alone and all together in order, each compiled `W=1` against his tree (one harmless unused-declaration warning on `0041`'s idiom, same as ours), with a PR title and body per patch. `0038` was withdrawn: his tree already has the identical PID -normalization. **Nothing was pushed or opened upstream.** +normalization. ~~**Nothing was pushed or opened upstream.**~~ **Sent 2026-09-12 — outcome in D6.** **Follow-ups surfaced (not actioned here; items 1–2 were closed the same day by the parallel workstream's PRs #158 and #160, merged to master 2026-09-11 and merged into this branch):** 1. **[CLOSED by PR #158]** **Firmware gap on our side**, exposed by the audit's Realtek correction: we build diff --git a/docs/kernel-recon/fork-sync-2026-09/upstream-candidates/README.md b/docs/kernel-recon/fork-sync-2026-09/upstream-candidates/README.md index 4847cd64..f5ed92a9 100644 --- a/docs/kernel-recon/fork-sync-2026-09/upstream-candidates/README.md +++ b/docs/kernel-recon/fork-sync-2026-09/upstream-candidates/README.md @@ -1,5 +1,13 @@ # Wave 5 — upstream candidates for MiSTer-devel/Linux-Kernel_MiSTer +> **Outcome (2026-09-12).** Sent as Linux-Kernel_MiSTer PRs #95 (candidate 2), #96 (3), #97 (4) +> and #98 (7), plus config PRs #93/#94. #95 and #98 merged. **#96 and #97 were closed**: the +> maintainer took the userspace alternatives instead (Main_MiSTer #1307/#1308, in Release +> 20260912), so the source patches for candidates 3 and 4 — `0040`, `0041` — were **retired from +> this repo's series** the same day. The `03-*`/`04-*` files below are kept as the record of what +> was offered; the regeneration table's rows for them no longer resolve. Candidates 5 and 6 are +> still unsent. + **Purpose: these patches are PREPARED, not sent.** No network push, no PR was opened from this session (the environment has no `gh`/GitHub API access, and pushing is out of scope for this wave per `PLAN.md` §5.2). Everything here is a ready-to-apply artifact @@ -85,8 +93,7 @@ cd /path/to/Linux-Kernel_MiSTer git checkout MiSTer-v6.18 git am /path/to/Buildroot_MiSTer/docs/kernel-recon/fork-sync-2026-09/upstream-candidates/02-hid-nintendo-nso-n64-genesis-stock-button-mapping.patch -git am /path/to/Buildroot_MiSTer/docs/kernel-recon/fork-sync-2026-09/upstream-candidates/03-hid-nintendo-imu-name-suffix.patch -git am /path/to/Buildroot_MiSTer/docs/kernel-recon/fork-sync-2026-09/upstream-candidates/04-hid-nintendo-stock-led-classdev-names.patch +# 03-/04- (IMU name, LED names): do NOT re-offer -- closed upstream as #96/#97, see the note at the top git am /path/to/Buildroot_MiSTer/docs/kernel-recon/fork-sync-2026-09/upstream-candidates/05-hid-playstation-stock-lightbar-led-names.patch git am /path/to/Buildroot_MiSTer/docs/kernel-recon/fork-sync-2026-09/upstream-candidates/06-hid-playstation-dualsense-btn-z-scoping.patch git am /path/to/Buildroot_MiSTer/docs/kernel-recon/fork-sync-2026-09/upstream-candidates/07-fbdev-mister-fb-memremap-null-check.patch diff --git a/docs/kernel-recon/reconciliation.jsonl b/docs/kernel-recon/reconciliation.jsonl index 991a86ae..461e93c8 100644 --- a/docs/kernel-recon/reconciliation.jsonl +++ b/docs/kernel-recon/reconciliation.jsonl @@ -1,4 +1,4 @@ -{"_meta": {"generated": "2026-09-11 03:37 UTC", "fork_head": "5fcfae36975b217f6ab82b501065f3b13173ae15", "base_tag": "v5.15.1", "base_commit": "b6abb62daa5511c4a3eaa30cbdb02544d1f10fa2", "vanilla_target": "6.18.49 (release commit; v6.18.50 tag unreachable when this increment ran)", "vanilla_commit": "1c732c6b94f0faee1526bd375add2fe10cba2e26", "imports": {"e12ed6c19d51a2bdf818bd92e80b51da43709f25": "v5.13.12", "137491a75a9eac13a7825892986aefe5529db80e": "v5.14", "b6f2ca1c4d38ae0df5efc97ece55b3a505ad0a34": "v5.14.5", "aba1ef4c1101429fd2addb2be560c6370200ed0f": "v5.15.1"}, "delta_commit_count": 111, "increments": [{"date": "2026-07-24", "branch": "MiSTer-v5.15", "from": "f0fb626acadd07f0718934826b143b6e4c9ce81c", "to": "5fcfae36975b217f6ab82b501065f3b13173ae15", "added_shas": ["794e6f002d0f655c504733c126a01f8c1f0bc1d4", "5fcfae36975b217f6ab82b501065f3b13173ae15"], "note": "fork-sync increment; see docs/kernel-recon/fork-sync-2026-07.md. Vanilla grounding moved v6.18.38 -> v6.18.39 (the version configs/mister_de10nano_defconfig:130 now pins)."}, {"date": "2026-08-24", "branch": "MiSTer-v6.18", "from": "e8f065dbf8c567e8d7140142f72b9e2b1805d2dd", "to": "6332499e7545499dc361d09af7b44b33f494fe5d", "added_shas": ["6332499e7545499dc361d09af7b44b33f494fe5d"], "note": "First increment from the MiSTer-v6.18 branch rather than MiSTer-v5.15, so the work list is no longer single-branch -- reduce.py's header line now derives the branch breakdown from the records instead of labelling every work-list row v5.15. Dispositioned carried, as board/mister/de10nano/linux-patches/0047-btusb-mercusys-ma530-2c4e-0115.patch. vanilla_target deliberately LEFT at v6.18.39: the shipped pin is now 6.18.45 and this increment's own record is grounded on it explicitly, but the .40-.45 re-check across the other 125 records has not been done, and moving the global label would claim it had."}, {"date": "2026-09-11", "branch": "MiSTer-v6.18", "from": "6332499e7545499dc361d09af7b44b33f494fe5d", "to": "c129b0fac34ad5d613bbec3f59d6036775e41c83", "added_shas": ["aec7dc3aa4846385736f1d54c9155e3b3c726708", "33a0521fd46b3991ec3a882f659bceb2c1cb4399", "ea2212221ad137cf26bf5caa7ad3dab7216435a6", "59bcae8ebc53933bc4729af25ae5cd94ade1f756", "7c75b1b469e4dfd8bf59f9c28a25af16cddd2d9b", "9854075c86455942c2ce57e0b7dc80e3e2c5b108", "e6f377e7d178c20a4c28b09e1f70c4b8d4cbffe2", "41c45f378e8f433b56c4da9b80edcdfd67fcebfb", "c129b0fac34ad5d613bbec3f59d6036775e41c83", "a14b5e8e1c9c23f71b5d4cc300a7dab3083e546f"], "note": "2026-09 fork-sync increment (docs/kernel-recon/fork-sync-2026-09/{PLAN.md,STATUS.md} + docs/kernel-recon/fork-sync-2026-09.md). Nine MiSTer-v6.18 commits past 6332499e7 plus one open PR head (#92, refs/pull/92/head, NOT a merge commit -- keyed on its head SHA a14b5e8e1c9c23f71b5d4cc300a7dab3083e546f per owner decision D3; re-key to the merged SHA and re-diff when #92 lands, see records/a14b5e8e1c....json notes). Owner decisions 2026-09-11: D1=A (keep 0003-cpufreq-cyclone5-de10nano-overclock.patch; 59bcae8eb dispositioned dropped-deliberate, DTS OCRAM flags-sram reservation still carried into 0004; boost-ABI docs corrected; option B tracked bench-gated, memo-Q4-cpufreq.md \u00a78 flip conditions), D2=defer (c129b0fac AIC8800 driver dispositioned not-evaluated, blockers = upstream repo identity + firmware source, memo-Q9-aic8800.md), D3=carry PR #92 now, D4=align 0001 to fb_sys_read/fb_sys_write. Carried: 0048 (Q8 Stadia-FF IDs, clean-apply, all 3 series), 0049 (Q10 PR #92 hid-nintendo 8BitDo reorder, re-implemented, all 3 series), 0050 (Q6 exfat read-ahead plug, clean-apply, 6.18-only -- fails -F0 against 7.2.3's already-refactored exfat_blk_readahead), 0017 delta 5 (Q5 xpad skip_8bitdo_init, re-implemented), 0004 OCRAM flags-sram node (from Q4, partial carry -- driver itself not carried). Dropped-deliberate: Q1 aec7dc3aa (duplicate of 5fcfae369, CONFIG_TUN already ours), Q2 33a0521fd (CONFIG_RTW88_8821AU already in linux.config since v10), Q4 59bcae8eb (0003 kept, see D1 above), Q7 e6f377e7d (derived from Q2/Q3/Q4, no independent content). Not-evaluated: Q9 c129b0fac (see D2 above). GROUNDING: every vanilla-6.18 quote in this increment's records/memos is from the 6.18.49 release commit 1c732c6b94f0faee1526bd375add2fe10cba2e26 on linux-6.18.y -- NOT 6.18.50 (fork-sync-2026-09/env.md: the gregkh GitHub mirror lags one release and kernel.org is blocked from this session). vanilla_target/vanilla_commit below are updated to 6.18.49 honestly rather than silently advanced to the 6.18.50 the image pins; re-run the .49->.50 drift walk (env.md's one-command re-check) before ever claiming .50. Ledger fix: reduce.py taught to read an optional `carried_patches` (plural) list per record, and records/b00a72159..., 45283785a..., 60821059c..., f84543926....json given that field so the pre-existing 0039/0040/0041/0042 orphans (STATUS.md \u00a72.5) resolve -- see those four records' own notes for the a6b7e3666/f123647ef short-SHA identification."}], "record_count": 136, "tier2_verified": 126}} +{"_meta": {"generated": "2026-09-12 17:05 UTC", "fork_head": "5fcfae36975b217f6ab82b501065f3b13173ae15", "base_tag": "v5.15.1", "base_commit": "b6abb62daa5511c4a3eaa30cbdb02544d1f10fa2", "vanilla_target": "6.18.49 (release commit; v6.18.50 tag unreachable when this increment ran)", "vanilla_commit": "1c732c6b94f0faee1526bd375add2fe10cba2e26", "imports": {"e12ed6c19d51a2bdf818bd92e80b51da43709f25": "v5.13.12", "137491a75a9eac13a7825892986aefe5529db80e": "v5.14", "b6f2ca1c4d38ae0df5efc97ece55b3a505ad0a34": "v5.14.5", "aba1ef4c1101429fd2addb2be560c6370200ed0f": "v5.15.1"}, "delta_commit_count": 111, "increments": [{"date": "2026-07-24", "branch": "MiSTer-v5.15", "from": "f0fb626acadd07f0718934826b143b6e4c9ce81c", "to": "5fcfae36975b217f6ab82b501065f3b13173ae15", "added_shas": ["794e6f002d0f655c504733c126a01f8c1f0bc1d4", "5fcfae36975b217f6ab82b501065f3b13173ae15"], "note": "fork-sync increment; see docs/kernel-recon/fork-sync-2026-07.md. Vanilla grounding moved v6.18.38 -> v6.18.39 (the version configs/mister_de10nano_defconfig:130 now pins)."}, {"date": "2026-08-24", "branch": "MiSTer-v6.18", "from": "e8f065dbf8c567e8d7140142f72b9e2b1805d2dd", "to": "6332499e7545499dc361d09af7b44b33f494fe5d", "added_shas": ["6332499e7545499dc361d09af7b44b33f494fe5d"], "note": "First increment from the MiSTer-v6.18 branch rather than MiSTer-v5.15, so the work list is no longer single-branch -- reduce.py's header line now derives the branch breakdown from the records instead of labelling every work-list row v5.15. Dispositioned carried, as board/mister/de10nano/linux-patches/0047-btusb-mercusys-ma530-2c4e-0115.patch. vanilla_target deliberately LEFT at v6.18.39: the shipped pin is now 6.18.45 and this increment's own record is grounded on it explicitly, but the .40-.45 re-check across the other 125 records has not been done, and moving the global label would claim it had."}, {"date": "2026-09-11", "branch": "MiSTer-v6.18", "from": "6332499e7545499dc361d09af7b44b33f494fe5d", "to": "c129b0fac34ad5d613bbec3f59d6036775e41c83", "added_shas": ["aec7dc3aa4846385736f1d54c9155e3b3c726708", "33a0521fd46b3991ec3a882f659bceb2c1cb4399", "ea2212221ad137cf26bf5caa7ad3dab7216435a6", "59bcae8ebc53933bc4729af25ae5cd94ade1f756", "7c75b1b469e4dfd8bf59f9c28a25af16cddd2d9b", "9854075c86455942c2ce57e0b7dc80e3e2c5b108", "e6f377e7d178c20a4c28b09e1f70c4b8d4cbffe2", "41c45f378e8f433b56c4da9b80edcdfd67fcebfb", "c129b0fac34ad5d613bbec3f59d6036775e41c83", "a14b5e8e1c9c23f71b5d4cc300a7dab3083e546f"], "note": "2026-09 fork-sync increment (docs/kernel-recon/fork-sync-2026-09/{PLAN.md,STATUS.md} + docs/kernel-recon/fork-sync-2026-09.md). Nine MiSTer-v6.18 commits past 6332499e7 plus one open PR head (#92, refs/pull/92/head, NOT a merge commit -- keyed on its head SHA a14b5e8e1c9c23f71b5d4cc300a7dab3083e546f per owner decision D3; re-key to the merged SHA and re-diff when #92 lands, see records/a14b5e8e1c....json notes). Owner decisions 2026-09-11: D1=A (keep 0003-cpufreq-cyclone5-de10nano-overclock.patch; 59bcae8eb dispositioned dropped-deliberate, DTS OCRAM flags-sram reservation still carried into 0004; boost-ABI docs corrected; option B tracked bench-gated, memo-Q4-cpufreq.md \u00a78 flip conditions), D2=defer (c129b0fac AIC8800 driver dispositioned not-evaluated, blockers = upstream repo identity + firmware source, memo-Q9-aic8800.md), D3=carry PR #92 now, D4=align 0001 to fb_sys_read/fb_sys_write. Carried: 0048 (Q8 Stadia-FF IDs, clean-apply, all 3 series), 0049 (Q10 PR #92 hid-nintendo 8BitDo reorder, re-implemented, all 3 series), 0050 (Q6 exfat read-ahead plug, clean-apply, 6.18-only -- fails -F0 against 7.2.3's already-refactored exfat_blk_readahead), 0017 delta 5 (Q5 xpad skip_8bitdo_init, re-implemented), 0004 OCRAM flags-sram node (from Q4, partial carry -- driver itself not carried). Dropped-deliberate: Q1 aec7dc3aa (duplicate of 5fcfae369, CONFIG_TUN already ours), Q2 33a0521fd (CONFIG_RTW88_8821AU already in linux.config since v10), Q4 59bcae8eb (0003 kept, see D1 above), Q7 e6f377e7d (derived from Q2/Q3/Q4, no independent content). Not-evaluated: Q9 c129b0fac (see D2 above). GROUNDING: every vanilla-6.18 quote in this increment's records/memos is from the 6.18.49 release commit 1c732c6b94f0faee1526bd375add2fe10cba2e26 on linux-6.18.y -- NOT 6.18.50 (fork-sync-2026-09/env.md: the gregkh GitHub mirror lags one release and kernel.org is blocked from this session). vanilla_target/vanilla_commit below are updated to 6.18.49 honestly rather than silently advanced to the 6.18.50 the image pins; re-run the .49->.50 drift walk (env.md's one-command re-check) before ever claiming .50. Ledger fix: reduce.py taught to read an optional `carried_patches` (plural) list per record, and records/b00a72159..., 45283785a..., 60821059c..., f84543926....json given that field so the pre-existing 0039/0040/0041/0042 orphans (STATUS.md \u00a72.5) resolve -- see those four records' own notes for the a6b7e3666/f123647ef short-SHA identification."}], "record_count": 136, "tier2_verified": 126}} {"added": 3, "agrees_with_provenance_doc": true, "author": "Sorgelig", "author_is_pr_contributor": false, "carried_mode": "re-implemented", "carried_patch": "0004-dts-de10nano-MiSTer.patch", "change_type": "dts", "date": "2021-08-20", "dependencies": {"depends_on": [], "duplicate_of": [], "superseded_by": []}, "disposition": "carried", "files": ["arch/arm/boot/dts/socfpga_cyclone5_de10_nano.dts"], "forward_port": {"applies_to_6_18": true, "conflicts": null, "effort": "trivial"}, "impact": {"affected_hardware": ["DE10-Nano"], "device_ids": [], "effect_if_absent": "Device tree compiler warnings for unit-address-less nodes in the board DTS; no functional impact", "failure_mode": "silent", "severity": "cosmetic"}, "is_backport_of_vanilla": false, "license_provenance": null, "notes": "This commit fixed three device tree compilation warnings by adding correct unit addresses to device tree node names: (1) adxl345: adxl345@0 -> adxl345@53 (i2c address), (2) spiusb -> spiusb@0 (SPI bus 0 CS 0), (3) spibri -> spibri@0 (SPI bus 1 CS 0) -- confirmed by direct read of the fork commit diff (`git show 071d9092e`), exactly these 3 hunks, nothing else. For P1.7 forward-port to 6.18, patch 0004-dts-de10nano-MiSTer.patch was re-authored on top of mainline's minimal de10nano.dts (new path: arch/arm/boot/dts/intel/socfpga/socfpga_cyclone5_de10nano.dts) rather than replayed. The re-authored patch includes spiusb@0 with correct addressing (confirmed present at patch line 273: `spiusb@0 {`). accelerometer@53 is absent from 0004 because it's already present with the correct unit address in mainline's own board file (not added by us) -- confirmed by direct read (see corrected citation below). spibri is absent from 0004 for an unrelated reason not fully captured by the original note: patch 0004 replaces the fork's spibri/altspi SPI-bus-1 child entirely with a differently-named spidev@0 node using compatible=\"rohm,dh2228fv\" (a real mainline spidev binding), documented in 0004's own commit body (\"/dev/spidev1.0 WITHOUT A KERNEL PATCH\" section) as a deliberate substitution to avoid needing the fork's spidev_dt_ids[] kernel patch -- it is not merely that 'mainline's minimal board file doesn't define spibri', which was an imprecise characterization; mainline doesn't define ANY spi1 child, and we chose a different one on purpose. The replacement (spidev@0) does carry correct '@0' addressing either way, so the practical warning-fix outcome the original note claimed still holds. All unit-address fixes are present in the 6.18 build via patch 0004, and dtc reports zero new warnings (asserted in 0004's own commit message, not independently re-verified by a build in this pass).\n\nsonnet-verified CORRECTION: upstream.vanilla_file_line was wrong (cited :109 in a 95-line file). Corrected to :72-74, where `accelerometer@53 { compatible = \"adi,adxl345\"; reg = <0x53>; ...` actually lives in /mnt/source/linux/arch/arm/boot/dts/intel/socfpga/socfpga_cyclone5_de10nano.dts (re-derived live, not copied from any prior doc). The quoted content itself was accurate; only the line number was stale/wrong. Also softened the spibri characterization above. disposition/carried_patch/carried_mode/severity all confirmed correct otherwise.\n\nsonnet-verified: CARRY-MAPPING CONFIRMED, CITATION CORRECTED (vanilla_file_line :109 -> :72-74, re-derived live) -- disposition/carried_patch/carried_mode/severity all hold; only the stale line number and the spibri wording needed a fix. | review fix (PR #18): removed the tag string 'v6.18.38' from vanilla_shas \u2014 the schema wants commit SHAs; the grounding here is the file:line+quote against the v6.18.38 checkout (no single upstream commit is being cited).", "provenance_doc_ref": "patch-provenance.md line 310-311, 926-931 (class A, P1.7)", "removed": 3, "sha": "071d9092e60bdb8048a6ffc7ccc36d450d47d957", "subject": "dts: fix warnings.", "subsystem": "dts", "upstream": {"equivalence": "equivalent", "vanilla_file_line": "arch/arm/boot/dts/intel/socfpga/socfpga_cyclone5_de10nano.dts:72-74 (sonnet-corrected from :109 -- the file is only 95 lines total; the accelerometer@53 node actually starts at line 72)", "vanilla_quote": "\taccelerometer@53 {\n\t\tcompatible = \"adi,adxl345\";\n\t\treg = <0x53>;", "vanilla_shas": []}, "userspace_coupling": {"coupled": false, "interface": null, "main_mister_ref": null}, "verification": {"confidence": "high", "contradiction": false, "method": "diff"}} {"added": 4, "agrees_with_provenance_doc": true, "author": "Sorgelig", "author_is_pr_contributor": false, "carried_mode": "re-implemented", "carried_patch": "0004-dts-de10nano-MiSTer.patch", "change_type": "in-tree-code", "date": "2021-08-20", "dependencies": {"depends_on": [], "duplicate_of": [], "superseded_by": []}, "disposition": "carried", "files": ["arch/arm/boot/dts/socfpga_cyclone5_de10_nano.dts", "drivers/usb/dwc2/core.c"], "forward_port": {"applies_to_6_18": true, "conflicts": null, "effort": "trivial"}, "impact": {"affected_hardware": ["Terasic DE10-Nano (socfpga_cyclone5)"], "device_ids": [], "effect_if_absent": "USB over-current detection would be enabled on usb1, potentially triggering false over-current errors and disabling the host port if the external power supply is not providing ideal voltage. With disable-over-current, external VBUS indicators are used instead of built-in over-current detection.", "failure_mode": "silent", "severity": "feature-loss"}, "is_backport_of_vanilla": false, "license_provenance": null, "notes": "GROUPED COMMIT: This commit is part of a 12-commit group in patch-provenance.md \u00a73.1 (commits aa8afe109 through 077c2c317), all related to DE10-Nano DTS changes. This commit contains two logically separate changes: (1) Device tree changes (adds disable-over-current and dr_mode properties to &usb1 node), and (2) Driver code changes (removes conditional guard in drivers/usb/dwc2/core.c). STATUS: Only the DTS changes are carried in patch 0004-dts-de10nano-MiSTer.patch (the DTS is re-implemented on top of mainline's minimal de10nano DTS at a different file path: intel/socfpga/... instead of the fork's flat path). The driver code changes are NOT carried because they are identified in patch-provenance.md \u00a7N5 as a no-op: the 'disable-over-current' DTS property unconditionally sets oc_disable=true via drivers/usb/dwc2/params.c (of_property_read_bool), making the conditional guard in the driver always true. Therefore, removing the guard has no behavioral effect. VERIFICATION: (1) DTS property present in patch 0004 (line 317 of patch diff, &usb1 block with 'disable-over-current;' and 'dr_mode=\"host\";'). (2) Driver change not present in any of our linux-patches/*.patch files (grep confirms no matches for oc_disable, GUSBCFG_ULPI_INT_VBUS). (3) Vanilla 6.18.38 drivers/usb/dwc2/core.c still has the conditional guard (verified with git show v6.18.38). (4) Vanilla 6.18.38 drivers/usb/dwc2/params.c has the property-read line, CORRECTED LOCATION by sonnet-verify to params.c:606 (was mis-cited as :65 in first pass -- see SONNET-VERIFIED addendum below: :65 is a DIFFERENT, Ingenic-vendor-specific field, not the generic one that applies here). FUNCTIONAL EQUIVALENCE: With patch 0004's DTS property present, the vanilla conditional code and the fork's unconditional code both result in the same behavior: GUSBCFG_ULPI_INT_VBUS_IND | GUSBCFG_INDICATORPASSTHROUGH flags ARE set. The driver change is dropped per P1.9 confirmed task ruling (patch-provenance.md N5).\n\nSONNET-VERIFIED, property->param->guard chain re-traced against the live 6.18.38 checkout with exact quotes -- LINE-NUMBER CORRECTION: the first-pass record cited params.c:65 for the oc_disable read; that line is actually inside dwc2_set_jz4775_params() (an Ingenic X1000/JZ4775 vendor-quirk setter, params.c:51-61) which sets a DIFFERENT field, `p->activate_ingenic_overcurrent_detection = !device_property_read_bool(hsotg->dev, \"disable-over-current\")` (note also the inverted polarity) -- unrelated to SoCFPGA/de10nano. The field this record actually needs, `p->oc_disable`, is set in the GENERIC path every board goes through: (1) drivers/usb/dwc2/params.c:606, dwc2_get_device_properties() -- `p->oc_disable = of_property_read_bool(hsotg->dev->of_node, \"disable-over-current\");` -- this read is unconditional (not gated on dr_mode; the dr_mode-gated block above it only covers g-rx-fifo-size/g-np-tx-fifo-size/g-tx-fifo-size/otg_caps), so any DT node carrying the property gets oc_disable=true, period. upstream.vanilla_file_line corrected to params.c:606 accordingly. (2) drivers/usb/dwc2/core.c:1092-1126, dwc2_hs_phy_init(), inside `case DWC2_PHY_TYPE_PARAM_ULPI:` -- `/* Set external VBUS indicator as needed. */\\n\\t\\tif (hsotg->params.oc_disable)\\n\\t\\t\\tusbcfg |= (GUSBCFG_ULPI_INT_VBUS_IND |\\n\\t\\t\\t\\t GUSBCFG_INDICATORPASSTHROUGH);` -- this is the ONLY remaining trace of the guard the fork's commit deletes; with oc_disable forced true by (1), the guard always fires, so vanilla's guarded code and the fork's unconditional code write the identical usbcfg value. (Note: this block only executes at all when hsotg->params.phy_type == DWC2_PHY_TYPE_PARAM_ULPI, but that's immaterial to the equivalence claim -- if the board is NOT ULPI-PHY, neither the guarded nor the unconditional version executes, so the two remain equivalent either way; the equivalence holds regardless of which PHY-type branch this SoC actually takes.) (3) patch 0004 carries the DTS property verbatim: `&usb1 {\\n\\tdr_mode = \"host\";\\n\\tdisable-over-current;\\n\\tstatus = \"okay\";\\n};` (0004-dts-de10nano-MiSTer.patch, matching the original commit's &usb1 hunk). (4) Corroborating context for WHY the fork's driver hack was redundant: vanilla commit b11633c42a76 ('usb: dwc2: disable erroneous overcurrent condition', Dinh Nguyen -- the SoCFPGA platform maintainer -- Oct 2017) added this exact 'disable-over-current' DT binding upstream specifically to solve 'For the case where an external VBUS is used, we should enable the external VBUS comparator in the driver. This would prevent an unnecessary overcurrent error which would then disable the host port' -- the identical SoCFPGA/external-VBUS problem Sorgelig's Aug 2021 fork commit was independently patching around 4 years later, just via a cruder unconditional edit instead of using the DT property that was already available upstream. Chain confirmed end-to-end; equivalence='equivalent' and disposition='carried' (DTS-only) both stand as originally recorded.", "provenance_doc_ref": "patch-provenance.md \u00a73.1 (Class A), \u00a7N5", "removed": 4, "sha": "077c2c317bee62f8823093f40e5587acbd2cf4c8", "sonnet-verified": "confirmed -- the no-op equivalence argument holds: params.c:606's dwc2_get_device_properties() unconditionally sets p->oc_disable from the DTS 'disable-over-current' property (patch 0004 carries the property verbatim on &usb1), so core.c's `if (hsotg->params.oc_disable)` guard around GUSBCFG_ULPI_INT_VBUS_IND|GUSBCFG_INDICATORPASSTHROUGH always fires -- making the fork's unconditional version behaviorally identical to vanilla's guarded version on this board. One correction made in passing: the first-pass vanilla_file_line (params.c:65) was misattributed to an unrelated Ingenic-vendor-specific field (activate_ingenic_overcurrent_detection, inverted polarity); corrected to params.c:606, the actual generic oc_disable assignment. Equivalence grade and disposition are otherwise unchanged.", "subject": "Disable USB overcurrent signaling.", "subsystem": "usb", "upstream": {"equivalence": "equivalent", "vanilla_file_line": "drivers/usb/dwc2/params.c:606", "vanilla_quote": "p->oc_disable = of_property_read_bool(hsotg->dev->of_node, \"disable-over-current\");", "vanilla_shas": ["b11633c42a76"]}, "userspace_coupling": {"coupled": false, "interface": null, "main_mister_ref": null}, "verification": {"confidence": "high", "contradiction": false, "method": "diff"}} {"added": 10, "agrees_with_provenance_doc": true, "author": "Sorgelig", "author_is_pr_contributor": false, "carried_mode": "clean-apply", "carried_patch": "0023-hid-wiimote-fixes.patch", "change_type": "in-tree-code", "date": "2019-05-05", "dependencies": {"depends_on": [], "duplicate_of": [], "superseded_by": []}, "disposition": "carried", "files": ["drivers/hid/hid-wiimote-core.c", "drivers/hid/hid-wiimote-modules.c"], "forward_port": {"applies_to_6_18": true, "conflicts": null, "effort": null}, "impact": {"affected_hardware": [], "device_ids": ["057E:0306", "057E:0330"], "effect_if_absent": "Multiple paired Wiimotes cannot be distinguished by userspace; applications like Main_MiSTer cannot uniquely identify each device via the input uniq field (read through /proc/bus/input/devices parsing and the EVIOCGUNIQ ioctl), preventing per-device controller remapping", "failure_mode": "silent", "severity": "feature-loss"}, "is_backport_of_vanilla": false, "license_provenance": null, "notes": "Commit 0d7778d1f sets input->uniq field for core wiimote device in hid-wiimote-core.c (1 line) and for 7 wiimote extension modules in hid-wiimote-modules.c (9 lines total). Propagates hdev->uniq to allow userspace to distinguish multiple paired Wiimotes. Carried in 0023-hid-wiimote-fixes.patch which squashes this commit with two others (button code remapping, analog range fixes) and adds one additional hunk for wiimod_turntable_probe(). Forward-ported cleanly to 6.18.38 by MCF on 2026-07-12. NOT in vanilla 6.18.38 \u2014 verified grep for wdata->input->uniq in /mnt/source/linux/drivers/hid/hid-wiimote-core.c returns no results. ESCALATION NOTE: patch-provenance.md line 370 groups three commits together (0d7778d1f, 47dc53a22, 15968bc26), violating the no-grouping requirement for Phase 1 analysis. CORRECTION (sonnet review): the interface field previously said 'sysfs /sys/class/input/eventX/device/uniq' \u2014 Main_MiSTer does not actually read that sysfs path; it parses the 'U: Uniq=' line out of /proc/bus/input/devices (input.cpp:4107-4131, copied to input[i].mac at :4151 and folded into unique_hash) and separately calls EVIOCGUNIQ (input.cpp:5202). Same underlying kernel field (input_dev->uniq), different userspace access path than claimed; file:line citation at 4151 was itself accurate.", "provenance_doc_ref": "line 370", "removed": 0, "sha": "0d7778d1f49a44c59a1943042725a0fdfe638591", "sonnet-verified": "carry-mapping into 0023 confirmed exact (uniq-field hunks match fork commit verbatim in both hid-wiimote-core.c and hid-wiimote-modules.c); main_mister_ref file:line (input.cpp:4151) was accurate but the interface description wrongly said sysfs \u2014 corrected to /proc/bus/input/devices + EVIOCGUNIQ", "subject": "wiimote: set uniq field.", "subsystem": "hid", "upstream": {"equivalence": null, "vanilla_file_line": null, "vanilla_quote": null, "vanilla_shas": []}, "userspace_coupling": {"coupled": true, "interface": "hdev->uniq surfaced to userspace via /proc/bus/input/devices 'U: Uniq=' line and the EVIOCGUNIQ ioctl (not sysfs, corrected during sonnet review)", "main_mister_ref": "input.cpp:4151 (strcpy(input[i].mac, uniq) \u2014 uniq parsed from /proc/bus/input/devices 'U: Uniq=' at input.cpp:4124); also input.cpp:5202 (ioctl(fd, EVIOCGUNIQ(...), uniq))"}, "verification": {"confidence": "high", "contradiction": false, "method": "source-grep"}} @@ -10,13 +10,13 @@ {"added": 308, "agrees_with_provenance_doc": true, "author": "Sorgelig", "author_is_pr_contributor": false, "carried_mode": "re-implemented", "carried_patch": "0002-sound-add-MiSTer-audio-spi-and-snd-dummy-MiSTer-model.patch", "change_type": "in-tree-code", "date": "2021-08-20", "dependencies": {"depends_on": ["CONFIG_SND_DUMMY=y (snd-dummy.c patch is load-bearing; dummy.c modifications MUST ship with this driver)", "Device tree SPI0 node with MiSTer audio compatible (from commit implementing DTS, now in patch 0004)", "/etc/asound.conf with specific routing configuration"], "duplicate_of": [], "superseded_by": []}, "disposition": "carried", "files": ["arch/arm/boot/dts/socfpga_cyclone5_de10_nano.dts", "sound/drivers/Kconfig", "sound/drivers/Makefile", "sound/drivers/MiSTer-audio-spi.c", "sound/drivers/dummy.c"], "forward_port": {"applies_to_6_18": true, "conflicts": null, "effort": "medium"}, "impact": {"affected_hardware": ["Terasic DE10-Nano (MiSTer)"], "device_ids": [], "effect_if_absent": "Audio subsystem non-functional; /dev/MrAudio device will not exist; no sound output through MiSTer's audio path. ALSA dummy card would still exist but the FPGA audio routing via /dev/MrAudio would be missing. /etc/asound.conf routing pipeline would fail silently.", "failure_mode": "silent", "severity": "feature-loss"}, "is_backport_of_vanilla": false, "license_provenance": "GPL-2.0; authored by Sorgelig; added SPDX header in the carried patch (0002)", "notes": "LOAD-BEARING COMMIT with critical dependencies. The dummy.c hunks (fake_buffer=0 and model_MiSTer) are NOT optional \u2014 omitting them yields a silent system where audio does not work even though /dev/MrAudio and the audio driver module are healthy. Patch 0002 forward-ports this from v5.15 to v6.18 with multiple API changes: class_create() no longer takes struct module* (v6.4-rc1); spi_driver::remove became void (v5.18-rc1); class_create/device_create return ERR_PTR instead of NULL (v6.4+); major changed from int to dev_t; Kconfig gained 'depends on SPI'; bug fix in device_open() error path (pre-existing bug in the fork, fixed in carried patch). MiSTer audio is a two-part contract: (1) patched snd-dummy providing card 0 with forced MiSTer model, and (2) MiSTer-audio-spi.c providing /dev/MrAudio character device. They are glued by /etc/asound.conf, which is the real userspace ABI. Not upstreamable as-is (hardware-specific character driver + forced dummy model defaults for one board). Disposition per provenance doc: Class A (MiSTer core), carry indefinitely. Agrees fully with provenance.md N4 section. sonnet-verified: confirmed \u2014 DRIVER_NAME \"MrAudio\", model_MiSTer (S16_LE/48000/2ch/32KiB), fake_buffer 1->0, and all forward-port API-churn claims (class_create() module-arg drop, spi_driver::remove void, ERR_PTR vs NULL, dev_t major) verified against the fork diff and carried patch 0002 header; /etc/asound.conf routing (plug -> rate -> file(/dev/MrAudio) -> hw:0) confirmed at /mnt/source/Buildroot_MiSTer/work/imgroot/etc/asound.conf; grep of Main_MiSTer/*.cpp,*.h for MrAudio/asound found zero hits, confirming the record's claim of no direct Main_MiSTer coupling to this interface; &spi0/spiusb DT dependency confirmed present in 0004-dts-de10nano-MiSTer.patch.", "provenance_doc_ref": "patch-provenance.md:259-279 (N4 section)", "removed": 1, "sha": "333d49b95b34fdac9835248ba046b9a4f74e2f98", "subject": "Implement MiSTer audio driver.", "subsystem": "sound", "upstream": {"equivalence": null, "vanilla_file_line": null, "vanilla_quote": null, "vanilla_shas": []}, "userspace_coupling": {"coupled": true, "interface": "/dev/MrAudio (character device); CONFIG_SND_DUMMY model_MiSTer forcing (S16_LE, 48000 Hz, 2 channels); /etc/asound.conf routing", "main_mister_ref": "Main_MiSTer does not directly open ALSA or /dev/MrAudio; the routing is done by /etc/asound.conf which tees PCM into /dev/MrAudio via the ALSA 'file' plugin"}, "verification": {"confidence": "high", "contradiction": false, "method": "source-grep"}} {"added": 325, "agrees_with_provenance_doc": true, "author": "Michael Huang", "author_is_pr_contributor": true, "carried_mode": "re-implemented", "carried_patch": "0003-cpufreq-cyclone5-de10nano-overclock.patch", "change_type": "in-tree-code", "date": "2022-10-23", "dependencies": {"depends_on": ["CONFIG_CPU_FREQ", "CLK_INTEL_SOCFPGA32"], "duplicate_of": [], "superseded_by": []}, "disposition": "carried", "files": ["arch/arm/configs/MiSTer_defconfig", "drivers/cpufreq/Kconfig.arm", "drivers/cpufreq/Makefile", "drivers/cpufreq/socfpga-cpufreq.c"], "forward_port": {"applies_to_6_18": true, "conflicts": null, "effort": "medium"}, "impact": {"affected_hardware": ["DE10-Nano", "MiSTer"], "device_ids": [], "effect_if_absent": "CPU frequency scaling and overclocking capability unavailable. Board remains at stock 800 MHz. No boot failure; feature silently absent. Community overclock scripts on /media/fat fail silently.", "failure_mode": "silent", "severity": "feature-loss"}, "is_backport_of_vanilla": false, "license_provenance": "GPL. Copyright Michael Huang 2022. MODULE_LICENSE(\"GPL\") in socfpga-cpufreq.c.", "notes": "Implements CPU frequency scaling and overclocking (400/800/1000/1200 MHz) for Cyclone V SoC FPGA on DE10-Nano board. Frequencies 1000/1200 MHz marked CPUFREQ_BOOST_FREQ to prevent automatic selection on boot. Carried as 0003-cpufreq-cyclone5-de10nano-overclock.patch with significant 6.18 forward-port modifications. FORWARD-PORT NOTES (5.15\u21926.18): (1) cpufreq_frequency_table_verify() lost 'table' argument; (2) cpufreq_driver::exit() changed from int to void return; (3) wait_for_fsm() made static (was 'void inline'); (4) **scaling_available_frequencies removed from ->attr** \u2014 core creates it automatically since 6.x and double-creation aborts policy registration. KNOWN LATENT BUG DELIBERATELY PRESERVED: wait_for_fsm() calls wait_on_bit(word, CLKMGR_STAT_BUSY, mode) passing a mask where bit number expected; polls bit 1 instead of bit 0. In practice harmless as PLL settling covered by register-write latency. Fixing requires timing validation on hardware; not appropriate for forward-port. Cannot be replaced with mainline cpufreq-dt: gen5 socfpga clock driver is read-only (no .set_rate ops), cpu nodes lack 'clocks' property, and complex multi-clock VCO transitions exceed OPP expressiveness. Agrees with provenance doc disposition. sonnet-verified: confirmed \u2014 frequency table (400/800/1000/1200 MHz, 1000/1200 flagged CPUFREQ_BOOST_FREQ), Kconfig dependency \"depends on CPU_FREQ && CLK_INTEL_SOCFPGA32\", and defconfig hunk (CONFIG_ARM_SOCFPGA_CPUFREQ=y, CONFIG_CPUFREQ_DT not set) all verified against the fork diff; wait_for_fsm()/wait_on_bit() latent-bug claim confirmed against /mnt/source/linux/include/linux/wait_bit.h (bit param is a bit NUMBER, CLKMGR_STAT_BUSY=BIT(0)=1 is passed as if it were bit-index 1); grep of vanilla drivers/cpufreq/ for socfpga|altera|altr returned zero matches, confirming no upstream equivalent; grep of Main_MiSTer/*.cpp,*.h for cpufreq/socfpga confirmed no direct reference (only unrelated socfpga_reset_manager/fpga_manager structs in fpga_io.cpp), supporting coupled=false as correctly recorded here (contrast with sibling record e6df8e30e, which wrongly had coupled=true before this audit \u2014 corrected there).", "provenance_doc_ref": "docs/patch-provenance.md: line 309 (class A table), lines 724-886 (detailed analysis \u00a7P1.6)", "removed": 1, "sha": "3d72b9db7650bc27b0c4a9931adfb144e3b2850b", "subject": "Add cpufreq/overclock driver (#34)", "subsystem": "cpufreq", "upstream": {"equivalence": null, "vanilla_file_line": null, "vanilla_quote": null, "vanilla_shas": []}, "userspace_coupling": {"coupled": false, "interface": "standard /sys/devices/system/cpu/cpu[01]/cpufreq/ sysfs; scaling_available_frequencies, scaling_boost_frequencies, scaling_max_freq, cpuinfo_max_freq", "main_mister_ref": null}, "verification": {"confidence": "high", "contradiction": false, "method": "source-grep"}} {"added": 2, "agrees_with_provenance_doc": null, "author": "Porkchop Express", "author_is_pr_contributor": true, "carried_mode": "clean-apply", "carried_patch": "0048-hid-google-stadiaff-classic2usb-retrozord.patch", "change_type": "in-tree-code", "date": "2026-09-09", "dependencies": {"depends_on": [], "duplicate_of": [], "superseded_by": []}, "disposition": "carried", "files": ["drivers/hid/hid-google-stadiaff.c"], "forward_port": {"applies_to_6_18": true, "conflicts": null, "effort": "trivial -- two lines, applies verbatim at offset 0 to both the 6.18.49 and the v7.2.3 hid-google-stadiaff.c (they are byte-identical files, confirmed with `diff`), and by extension expected to apply to the pinned 6.18.50/7.2.4 releases absent an intervening change to that file (none found in the 6.18.39..6.18.49 or 7.2..7.2.3 windows this session can see -- see notes for the grounding gap)."}, "impact": {"affected_hardware": ["Classic2USB / Reflex Adapt (16d0:1460)", "RetroZord adapter (1209:595a)"], "device_ids": ["16d0:1460", "1209:595a"], "effect_if_absent": "A Classic2USB (Reflex Adapt) or RetroZord adapter enumerates as a plain hid-generic device instead of binding hid-google-stadiaff: it still shows up as an input device (buttons/axes work via hidinput), but EV_FF/FF_RUMBLE is never registered on it, so force feedback silently does not work on force-feedback-capable games/cores that would otherwise drive it. No error is logged -- hid-generic claims any unclaimed HID_GROUP_GENERIC device (hid-generic.c:74, `HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY, HID_ANY_ID, HID_ANY_ID)`), so probing succeeds silently on the wrong (functionally poorer) driver.", "failure_mode": "silent", "severity": "feature-loss"}, "is_backport_of_vanilla": false, "license_provenance": "GPL-2.0-or-later, two `hid_device_id` table rows added directly to Google's existing hid-google-stadiaff.c (file header: 'Copyright 2023 Google LLC', SPDX GPL-2.0-or-later). No new file, no vendored code; MODULE_LICENSE(\"GPL\") in the driver is unchanged.", "notes": "HYPOTHESIS CONFIRMED, NOT REFUTED. PLAN.md section 2.8's disposition (carry as new shared patch 0048, userspace_coupling.coupled=true) holds against direct grounding.\n\nHUNK. `drivers/hid/hid-google-stadiaff.c` inside `stadia_devices[]`, immediately after the two existing USB/Bluetooth Google Stadia entries:\n```\n+\t{ HID_DEVICE(BUS_USB, HID_GROUP_GENERIC, 0x16d0, 0x1460) }, /* Classic2USB */\n+\t{ HID_DEVICE(BUS_USB, HID_GROUP_GENERIC, 0x1209, 0x595a) }, /* RetroZord */\n```\ncommit message: 'Both use the existing Stadia rumble output report in compatible firmware.'\n\nMAINLINE/VANILLA STATUS -- absent everywhere reachable. `grep -n '1460\\|595a\\|16d0\\|1209' ` returned nothing (exit 1) in: $S/mainline/drivers/hid/hid-google-stadiaff.c (torvalds/linux v7.3-rc2, 50d05c7c76c9), $S/linux/drivers/hid/hid-google-stadiaff.c (gregkh/linux linux-6.18.y at 'Linux 6.18.49' release commit 1c732c6b94f0), $S/linux-7.2/drivers/hid/hid-google-stadiaff.c (linux-7.2.y head 'Linux 7.2.3'), and `git -C $S/linux show v7.2.3:drivers/hid/hid-google-stadiaff.c | grep -n 1460` (exit 1). `git -C $S/mainline log -S'0x1460' -- drivers/hid/` and the same against $S/linux over the 6.18.39..HEAD range both returned empty -- no commit ever added or removed this string in the visible history, consistent with the file never having carried these IDs upstream. `diff`-ing the extracted 6.18.49 and v7.2.3 copies of the file showed them byte-identical (exit 0), so this is one grounding fact covering both series, not two independent absences.\n\nCONFIG. `board/mister/de10nano/linux.config:410` = `CONFIG_HID_GOOGLE_STADIA_FF=y` (verbatim). `docs/kernel-recon/fork-sync-2026-09/evidence/stock-20260907-linux.config:2893` = `CONFIG_HID_GOOGLE_STADIA_FF=y` (verbatim, same stock config the fork-sync baseline captured). The driver is built into stock and into our config already; the two device-ID rows are the entire functional gap, exactly as PLAN.md section 2.8 states.\n\nUSERSPACE COUPLING -- direct and multi-site, per userspace_coupling above. Main_MiSTer does not merely enumerate these VID:PIDs incidentally; input.cpp:52-53 is a named predicate function keyed on exactly these two pairs, :4176-4177 dedups them explicitly by comment name ('Reflex Adapt Classic2USB', 'RetroZord adapter'), and :5101-5103 / :5348-5350 / :5495-5506 gate NeGcon-wheel and Guncon-lightgun emulation paths on the same VID:PID pairs combined with name/uniq substrings ('RZordPsWheel', 'RZordPsGun'). This is exactly the kind of coupling PLAN.md flags as 'must not drop silently' under recon spec section 7.2.\n\nNAME/UNIQ STABILITY -- checked, and it does not change. `stadia_probe()` in $S/linux/drivers/hid/hid-google-stadiaff.c:104-120 calls `hid_hw_start(hdev, HID_CONNECT_DEFAULT & ~HID_CONNECT_FF)`, NOT bare `HID_CONNECT_DEFAULT` as PLAN.md section 2.8's prose paraphrases it (worth flagging: the plan's summary is slightly imprecise, though its conclusion is right) -- the driver only masks off HID_CONNECT_FF (it wires up its own memless FF instead of the generic hidinput FF path) and otherwise takes the default connect flags, which still include HIDINPUT. Neither `stadia_probe()` nor `stadiaff_init()` (same file, ~line 62-100) ever writes `hid->name`, `hid->uniq`, or `hidinput->input->name`/`->uniq` -- `stadiaff_init()` only calls `hid_validate_values()`, `devm_kzalloc()`, `hid_set_drvdata()`, `input_set_capability(dev, EV_FF, FF_RUMBLE)`, and `input_ff_create_memless()`. Device naming happens earlier and generically in hid-core's own connect path from the HID descriptor/USB strings, before any per-driver `.probe` runs, so binding stadiaff instead of hid-generic changes nothing that Main_MiSTer's name/uniq string matches (`RZordPsWheel`, `RZordPsGun`, etc., which come from firmware-reported UNIQ/name strings, not from the kernel driver) depend on.\n\nNO OTHER DRIVER CLAIMS THESE IDS. `grep -n '0x1460\\|0x595[aA]\\|0x16[dD]0\\|0x1209' $S/linux/drivers/hid/hid-ids.h` found only an unrelated `USB_VENDOR_ID_MCS 0x16d0` (different device, MCS is a distinct vendor at the same VID -- hid-ids.h has no entry for PID 0x1460 under it) and `grep -rn` across all `drivers/hid/*.c` found only an unrelated `HID_PRODUCT_ID_U1 0x1209` in hid-alps.c (0x1209 there is a *product* ID for a different vendor's device, not the pid.codes shared VID:PID 1209:595a in question -- confirmed by reading context, no `hid_device_id` row anywhere matches either full VID:PID pair). $S/linux/drivers/hid/hid-generic.c:74 has the catch-all `{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY, HID_ANY_ID, HID_ANY_ID) }`, so absent stadiaff's claim these two devices bind hid-generic today, silently, with FF unavailable -- confirming the 'silent' failure_mode.\n\nAPPLY EVIDENCE. Extracted `hid-google-stadiaff.c` from $S/linux (6.18.49) and from `git -C $S/linux show v7.2.3:...` into two clean temp dirs (`$S/tmp-q8/linux618`, `$S/tmp-q8/v723`, both inside the session scratchpad, no tree under $S touched) and ran `patch -p1 -F0 --dry-run --verbose` with a minimal patch built from `git -C $S/fork-6.18 diff 41c45f378^ 41c45f378 -- drivers/hid/hid-google-stadiaff.c`. Both reported `Hunk #1 succeeded at 143.` -- zero offset, zero fuzz, clean apply against both series.\n\nTHE 6.18.49/7.2.3 GROUNDING GAP (env.md). All of the above 'absent from vanilla' and 'applies cleanly' findings are against 6.18.49 and 7.2.3, one stable point release short of the 6.18.50/7.2.4 this repo's pins target (env.md: gregkh mirror lag, kernel.org blocked from this session). Because the 6.18.49 and v7.2.3 copies of hid-google-stadiaff.c are byte-identical and the file has zero commits touching it anywhere in the visible 6.18.39..HEAD / v7.2..v7.2.3 history (the `-S'0x1460'` search covers that whole window, not just the endpoints), there is no evidence of any in-flight change to this file that a missing point release could have picked up -- the gap is real per env.md's general caveat but this file shows no signal of being affected by it.\n\nNUMBERING. 0048 is unused in board/mister/de10nano/linux-patches/ (last is 0047-btusb-mercusys-ma530-2c4e-0115.patch), unused in board/mister/de10nano/linux-patches-beta/ (series file ends at 0046-dts-ramoops.patch), and unused in board/mister/de25nano/linux-patches/ (highest present is 0030-i2c-designware-quiet-timeout.patch) -- no collision in any of the three series PLAN.md section 2.8 names.\n\nNOT AUTHORED THIS WAVE. Per WORKER-PREAMBLE.md and worker-instructions.md, this record sets carried_patch to the planned filename and carried_mode:\"planned\" only -- the .patch file itself is not created in board/mister/*/linux-patches*/ by this task.\n\nWAVE 3 (2026-09-11): carried_mode changed from 'planned' to 'clean-apply' -- 0048 is authored in Wave 3, 2026-09-11, by the concurrent W3-0048 patch-authoring task, as a verbatim carry of the fork's two-line hunk into all three series (de10, beta, de25).", "provenance_doc_ref": "none -- this commit postdates docs/patch-provenance.md's baseline by five years; dispositioned here first per PLAN.md section 2.8.", "removed": 0, "sha": "41c45f378e8f433b56c4da9b80edcdfd67fcebfb", "source_branch": "MiSTer-v6.18", "subject": "Adapt Classic2USB and RetroZord HID force feedback support (#91)", "subsystem": "hid", "upstream": {"equivalence": "contradicted", "vanilla_file_line": "drivers/hid/hid-google-stadiaff.c -- absent from $S/mainline (torvalds/linux v7.3-rc2, 50d05c7c76c9), $S/linux (gregkh/linux linux-6.18.y at release 6.18.49, 1c732c6b94f0), $S/linux-7.2 (linux-7.2.y head 'Linux 7.2.3'), and v7.2.3 as extracted with `git show v7.2.3:drivers/hid/hid-google-stadiaff.c` from $S/linux", "vanilla_quote": null, "vanilla_shas": []}, "userspace_coupling": {"coupled": true, "interface": "VID:PID special-case predicate + make_unique() device dedup + NeGcon/Guncon name/uniq string matching", "main_mister_ref": "$S/main/input.cpp:52-53 (`(vid == 0x16D0 && (pid == 0x127E || pid == 0x1460)) // Reflex Adapt || (vid == 0x1209 && pid == 0x595A); // RetroZord`); input.cpp:4176 `make_unique(0x16D0, 0x1460, 1); // Reflex Adapt Classic2USB`; input.cpp:4177 `make_unique(0x1209, 0x595A, 1); // RetroZord adapter`; input.cpp:5102 and :5349 match `input[i].vid == 0x1209 && input[i].pid == 0x595A` together with `strstr(input[i].name, \"RZordPsWheel\")` / `strstr(uniq, \"RZordPsGun\")` for NeGcon/Guncon emulation; input.cpp:5496 re-checks the same two VID:PID pairs (`0x16D0`/`0x1460` and `0x1209`/`0x595A`) alongside `strlen(uniq)` for RetroZord's UNIQ-field mode differentiation."}, "verification": {"confidence": "high", "contradiction": true, "method": "diff"}} -{"added": 23, "agrees_with_provenance_doc": false, "author": "Sorgelig", "author_is_pr_contributor": false, "carried_mode": "re-implemented", "carried_patch": "0032-hid-nintendo-joycon-combo-led.patch", "carried_patches": ["0032-hid-nintendo-joycon-combo-led.patch", "0040-hid-nintendo-imu-name-suffix.patch"], "change_type": "in-tree-code", "date": "2021-08-14", "dependencies": {"depends_on": [], "duplicate_of": ["a6b7e36668f60fee6d2cd8dd142db5237c3b3f1f (MiSTer-v6.18, same subject line verbatim -- 'hid-nintendo: add virtual combo led, don't warn by IMU compensation.' -- the v6.18-branch re-port of this v5.15 commit per fork-sync.conf's note on the 2026-07-24 e8f065dbf8 advance: subject-set comparison found only three v6.18 subjects without a byte-identical v5.15 twin, and this is not one of them)"], "superseded_by": []}, "disposition": "carried", "files": ["drivers/hid/hid-nintendo.c"], "forward_port": {"applies_to_6_18": false, "conflicts": null, "effort": "medium"}, "impact": {"affected_hardware": ["Nintendo Joy-Con (L)", "Nintendo Joy-Con (R)"], "device_ids": ["057e:2006", "057e:2007"], "effect_if_absent": "Joy-Con L+R combining is completely non-functional (not merely 'auto-detect disabled with manual fallback'). Individual Joy-Cons still work as separate single-stick controllers, but there is no way \u2014 automatic or manual \u2014 to pair two Joy-Cons into one virtual controller, because Main_MiSTer's ENTIRE pairing handshake (both the write side triggered by a button-combo request, and the read side that recognizes the pair on device rescan) is implemented purely as a read/write of the kernel-side ':combo' LED sysfs node. No alternative/manual pairing UI exists anywhere in Main_MiSTer (grep of menu.cpp/osd.cpp for 'joycon'/'joy-con' returns zero hits; input.cpp sets input[].bind for QUIRK_JOYCON devices at exactly one place, input.cpp:4729-4730, and that code path is unreachable without a valid combo-id readback).", "failure_mode": "silent", "severity": "feature-loss"}, "is_backport_of_vanilla": false, "license_provenance": null, "notes": "MISCLASSIFIED. patch-provenance.md:334 GROUPS four commits (`c4ec5cb40`, `9bdab534b`, `60821059c`, `45283785a`) into one Class-C 'drop \u2014 now upstream' row citing a single upstream SHA, `2af16c1f846b` ('HID: nintendo: add nintendo switch controller driver', 2021-09-11, v5.16), as the citation for all four. That upstream commit only introduced the BASE hid-nintendo driver (matches c4ec5cb40 and neighbors); it predates 45283785a by about a month in the fork's own history and never touched LED code beyond the stock player/home LEDs. Re-derived independently: `git log -S'combo' -- drivers/hid/hid-nintendo.c` and `git log -S'combo_led' -- drivers/hid/hid-nintendo.c` in /mnt/source/linux (HEAD confirmed at tag v6.18.38, commit e46dc0adfe39) both return ZERO commits across the entire vanilla history of the file \u2014 the string 'combo' has never appeared in mainline hid-nintendo.c. `grep -n combo /mnt/source/linux/drivers/hid/hid-nintendo.c` also returns nothing. Vanilla's joycon_leds_create() (hid-nintendo.c:2235-2327) registers exactly the player LEDs and the home LED, then returns \u2014 quoted above. This is a fabricated, MiSTer-specific extension with no upstream counterpart and no submission path (it depends on a MiSTer-only Main_MiSTer-side pairing protocol, not something Nintendo/Linux HID maintainers would take). Per the grounding contract, equivalence=contradicted + provenance doc claims upstream coverage in a grouped row => disposition=misclassified (not dropped-upstream, and not merely needs-verification since the contradiction is now fully proven with quotes). CORRECTION TO PRIOR DRAFT OF THIS RECORD: the previous pass's impact/notes claimed 'users lose automatic pairing but can manually configure' \u2014 this is WRONG. Traced set_led()/get_led()/check_joycon()/process_joycon() in full: there is no manual fallback. The button-combo-triggered pairing REQUEST (process_joycon, input.cpp:4785-4823) and the pairing RECOGNITION (check_joycon, input.cpp:4689-4738) communicate ONLY via the ':combo' sysfs LED value \u2014 one process writes it, the other reads it back after a forced device-rescan. Without the kernel classdev both operations are silent no-ops (fopen fails, functions return 0/false, nothing is logged), so input[].bind is never set for any Joy-Con pair, under any user action. Grep of menu.cpp and osd.cpp for 'joycon'/'joy-con' confirms there is no alternate UI. Net effect: Joy-Con dual-controller combining is entirely and silently broken, not merely 'less convenient.' Individual Joy-Cons (VID 057e, PID 2006/2007 \u2014 confirmed against input.cpp:5331-5340) still function as independent single-stick controllers, so severity is feature-loss rather than boot-critical. Secondary, unrelated change in the same commit: IMU-dropped-packet log lines downgraded hid_warn -> hid_dbg (fork diff, both call sites). Vanilla 6.18.38 (hid-nintendo.c:1457-1464) instead uses hid_warn_ratelimited (introduced by b8874720b2f3 'HID: nintendo: Rate limit IMU compensation message', 2025-10-06, confirmed via `git log --oneline -S'hid_warn_ratelimited' -- drivers/hid/hid-nintendo.c` and `git show --stat b8874720b2f3`) \u2014 a different mechanism (rate-limit vs. debug-demote) that achieves a similar log-spam-reduction goal but is not the same code; this part is a plausible, lower-stakes carry candidate on its own merits but is NOT what the coupled-regression escalation claim is about and does not rescue the provenance doc's citation for the combo LED half of the commit. Not carried: grep of all 25 files in board/mister/de10nano/linux-patches/*.patch for 'combo' returns zero matches (0015-hid-nintendo-nso-famicom.patch and 0013-hid-flydigi-vader.patch matched only on unrelated 'nintendo'/'joycon' substrings). CONFIG_HID_NINTENDO=y is set in our linux.config (line 323) and drivers/hid/hid-nintendo.c is present and built in vanilla 6.18.38, so the driver itself is not missing \u2014 only the combo LED classdev inside it. sonnet-verified: CONFIRMED \u2014 every link in the original coupled-regression claim holds under independent re-derivation (fork diff quoted directly from `git show`, vanilla absence proven by both grep and full-history `git log -S`, Main_MiSTer read/write/bind chain traced end-to-end with line numbers, provenance doc grouped-row citation confirmed wrong for this specific commit). One correction made to the prior draft: there is NO manual-pairing fallback in Main_MiSTer \u2014 the regression is total loss of Joy-Con combining, not degraded convenience; effect_if_absent, userspace_coupling, and notes above were rewritten accordingly. disposition upgraded from needs-verification to misclassified now that the contradiction is fully evidenced with quotes per the grounding contract. | RESOLVED (user carry decision 2026-07-14/15 (see silent-regressions.md + git d2f2791 follow-ups)): carried as 0032 \u2014 combo LED registered on 6.18 hid-nintendo with non-fatal registration; IMU log downgrade included. Joy-Con combining restored. WAVE 3 LEDGER FIX (2026-09-11): docs/patch-provenance.md \u00a711's '0040-hid-nintendo-imu-name-suffix' row cites its origin as fork commit `a6b7e3666` -- that short SHA resolves to `a6b7e36668f60fee6d2cd8dd142db5237c3b3f1f` on MiSTer-v6.18, subject byte-identical to THIS record's commit (see dependencies.duplicate_of), i.e. it is the v6.18-branch re-port of this same v5.15 change, not a separate unrecorded commit -- so 0040's real origin record is this one. Added above as `carried_patches` so reduce.py's orphan-carried-patch invariant (single `carried_patch` field only, previously) stops flagging 0040 as unmapped; `carried_patch` stays 0032, the schema's canonical single-value field.", "provenance_doc_ref": "patch-provenance.md:334", "removed": 2, "sha": "45283785a7ace3263f7c165ae6a4ec3055ebdcf6", "sonnet-verified": "confirmed \u2014 combo LED registration, vanilla absence, and full Main_MiSTer read/write/bind coupling all verified with direct quotes and line numbers; corrected the 'manual pairing fallback exists' claim in the prior draft (no such fallback exists) and upgraded disposition to misclassified per the grounding contract (contradicted + provenance doc claims upstream in a grouped row).", "subject": "hid-nintendo: add virtual combo led, don't warn by IMU compensation.", "subsystem": "hid", "upstream": {"equivalence": "contradicted", "vanilla_file_line": "drivers/hid/hid-nintendo.c:2235-2327 (joycon_leds_create, v6.18.38)", "vanilla_quote": "static int joycon_leds_create(struct joycon_ctlr *ctlr)\n{\n\t...\n\t/* configure the player LEDs */\n\t...\nhome_led:\n\t/* configure the home LED */\n\tif (jc_type_has_right(ctlr)) {\n\t\t...\n\t\tret = devm_led_classdev_register(&hdev->dev, led);\n\t\tif (ret) {\n\t\t\thid_err(hdev, \"Failed to register home LED; ret=%d\\n\", ret);\n\t\t\treturn ret;\n\t\t}\n\t}\n\n\treturn 0;\n}", "vanilla_shas": []}, "userspace_coupling": {"coupled": true, "interface": "/sys/.../leds/:combo/brightness (LED classdev registered by joycon_leds_create() in the fork commit; name format '%s:combo' with %s = dev_name(&hdev->dev), e.g. '0005:057E:2006.0001:combo')", "main_mister_ref": "input.cpp:2661-2674 set_led() and input.cpp:2676-2690 get_led() both fopen() the LED's 'brightness' sysfs file and silently return 0/no-op if it does not exist (no error logged) \u2014 this is the mechanism by which absence degrades silently. input.cpp:4689-4738 check_joycon() reads ':combo' via get_led() at lines 4704 and 4715 to recognize a matched Joy-Con pair on device rescan and, only if a nonzero shared id is read back, sets the actual pairing at input.cpp:4729-4730 (input[l].bind = r; input[r].bind = l). input.cpp:4785-4823 process_joycon() is the OTHER half of the handshake: on a specific 3-button hold (JOYCON_REQ, misc_flags&7==7) on both an unbound left and right Joy-Con, it writes a freshly-generated id to both controllers' ':combo' LED via set_led() at lines 4822-4823, then force-closes all input fds to trigger the rescan that re-invokes check_joycon(). Without the kernel-side combo LED classdev, the write at 4822-4823 is a silent no-op and the read at 4704/4715 always returns 0, so id_combo never matches and input[l]/input[r].bind is never set \u2014 pairing silently never completes, with no error surfaced to the user."}, "verification": {"confidence": "high", "contradiction": true, "method": "source-grep"}} +{"added": 23, "agrees_with_provenance_doc": false, "author": "Sorgelig", "author_is_pr_contributor": false, "carried_mode": "re-implemented", "carried_patch": "0032-hid-nintendo-joycon-combo-led.patch", "carried_patches": ["0032-hid-nintendo-joycon-combo-led.patch"], "change_type": "in-tree-code", "date": "2021-08-14", "dependencies": {"depends_on": [], "duplicate_of": ["a6b7e36668f60fee6d2cd8dd142db5237c3b3f1f (MiSTer-v6.18, same subject line verbatim -- 'hid-nintendo: add virtual combo led, don't warn by IMU compensation.' -- the v6.18-branch re-port of this v5.15 commit per fork-sync.conf's note on the 2026-07-24 e8f065dbf8 advance: subject-set comparison found only three v6.18 subjects without a byte-identical v5.15 twin, and this is not one of them)"], "superseded_by": []}, "disposition": "carried", "files": ["drivers/hid/hid-nintendo.c"], "forward_port": {"applies_to_6_18": false, "conflicts": null, "effort": "medium"}, "impact": {"affected_hardware": ["Nintendo Joy-Con (L)", "Nintendo Joy-Con (R)"], "device_ids": ["057e:2006", "057e:2007"], "effect_if_absent": "Joy-Con L+R combining is completely non-functional (not merely 'auto-detect disabled with manual fallback'). Individual Joy-Cons still work as separate single-stick controllers, but there is no way \u2014 automatic or manual \u2014 to pair two Joy-Cons into one virtual controller, because Main_MiSTer's ENTIRE pairing handshake (both the write side triggered by a button-combo request, and the read side that recognizes the pair on device rescan) is implemented purely as a read/write of the kernel-side ':combo' LED sysfs node. No alternative/manual pairing UI exists anywhere in Main_MiSTer (grep of menu.cpp/osd.cpp for 'joycon'/'joy-con' returns zero hits; input.cpp sets input[].bind for QUIRK_JOYCON devices at exactly one place, input.cpp:4729-4730, and that code path is unreachable without a valid combo-id readback).", "failure_mode": "silent", "severity": "feature-loss"}, "is_backport_of_vanilla": false, "license_provenance": null, "notes": "MISCLASSIFIED. patch-provenance.md:334 GROUPS four commits (`c4ec5cb40`, `9bdab534b`, `60821059c`, `45283785a`) into one Class-C 'drop \u2014 now upstream' row citing a single upstream SHA, `2af16c1f846b` ('HID: nintendo: add nintendo switch controller driver', 2021-09-11, v5.16), as the citation for all four. That upstream commit only introduced the BASE hid-nintendo driver (matches c4ec5cb40 and neighbors); it predates 45283785a by about a month in the fork's own history and never touched LED code beyond the stock player/home LEDs. Re-derived independently: `git log -S'combo' -- drivers/hid/hid-nintendo.c` and `git log -S'combo_led' -- drivers/hid/hid-nintendo.c` in /mnt/source/linux (HEAD confirmed at tag v6.18.38, commit e46dc0adfe39) both return ZERO commits across the entire vanilla history of the file \u2014 the string 'combo' has never appeared in mainline hid-nintendo.c. `grep -n combo /mnt/source/linux/drivers/hid/hid-nintendo.c` also returns nothing. Vanilla's joycon_leds_create() (hid-nintendo.c:2235-2327) registers exactly the player LEDs and the home LED, then returns \u2014 quoted above. This is a fabricated, MiSTer-specific extension with no upstream counterpart and no submission path (it depends on a MiSTer-only Main_MiSTer-side pairing protocol, not something Nintendo/Linux HID maintainers would take). Per the grounding contract, equivalence=contradicted + provenance doc claims upstream coverage in a grouped row => disposition=misclassified (not dropped-upstream, and not merely needs-verification since the contradiction is now fully proven with quotes). CORRECTION TO PRIOR DRAFT OF THIS RECORD: the previous pass's impact/notes claimed 'users lose automatic pairing but can manually configure' \u2014 this is WRONG. Traced set_led()/get_led()/check_joycon()/process_joycon() in full: there is no manual fallback. The button-combo-triggered pairing REQUEST (process_joycon, input.cpp:4785-4823) and the pairing RECOGNITION (check_joycon, input.cpp:4689-4738) communicate ONLY via the ':combo' sysfs LED value \u2014 one process writes it, the other reads it back after a forced device-rescan. Without the kernel classdev both operations are silent no-ops (fopen fails, functions return 0/false, nothing is logged), so input[].bind is never set for any Joy-Con pair, under any user action. Grep of menu.cpp and osd.cpp for 'joycon'/'joy-con' confirms there is no alternate UI. Net effect: Joy-Con dual-controller combining is entirely and silently broken, not merely 'less convenient.' Individual Joy-Cons (VID 057e, PID 2006/2007 \u2014 confirmed against input.cpp:5331-5340) still function as independent single-stick controllers, so severity is feature-loss rather than boot-critical. Secondary, unrelated change in the same commit: IMU-dropped-packet log lines downgraded hid_warn -> hid_dbg (fork diff, both call sites). Vanilla 6.18.38 (hid-nintendo.c:1457-1464) instead uses hid_warn_ratelimited (introduced by b8874720b2f3 'HID: nintendo: Rate limit IMU compensation message', 2025-10-06, confirmed via `git log --oneline -S'hid_warn_ratelimited' -- drivers/hid/hid-nintendo.c` and `git show --stat b8874720b2f3`) \u2014 a different mechanism (rate-limit vs. debug-demote) that achieves a similar log-spam-reduction goal but is not the same code; this part is a plausible, lower-stakes carry candidate on its own merits but is NOT what the coupled-regression escalation claim is about and does not rescue the provenance doc's citation for the combo LED half of the commit. Not carried: grep of all 25 files in board/mister/de10nano/linux-patches/*.patch for 'combo' returns zero matches (0015-hid-nintendo-nso-famicom.patch and 0013-hid-flydigi-vader.patch matched only on unrelated 'nintendo'/'joycon' substrings). CONFIG_HID_NINTENDO=y is set in our linux.config (line 323) and drivers/hid/hid-nintendo.c is present and built in vanilla 6.18.38, so the driver itself is not missing \u2014 only the combo LED classdev inside it. sonnet-verified: CONFIRMED \u2014 every link in the original coupled-regression claim holds under independent re-derivation (fork diff quoted directly from `git show`, vanilla absence proven by both grep and full-history `git log -S`, Main_MiSTer read/write/bind chain traced end-to-end with line numbers, provenance doc grouped-row citation confirmed wrong for this specific commit). One correction made to the prior draft: there is NO manual-pairing fallback in Main_MiSTer \u2014 the regression is total loss of Joy-Con combining, not degraded convenience; effect_if_absent, userspace_coupling, and notes above were rewritten accordingly. disposition upgraded from needs-verification to misclassified now that the contradiction is fully evidenced with quotes per the grounding contract. | RESOLVED (user carry decision 2026-07-14/15 (see silent-regressions.md + git d2f2791 follow-ups)): carried as 0032 \u2014 combo LED registered on 6.18 hid-nintendo with non-fatal registration; IMU log downgrade included. Joy-Con combining restored. WAVE 3 LEDGER FIX (2026-09-11): docs/patch-provenance.md \u00a711's '0040-hid-nintendo-imu-name-suffix' row cites its origin as fork commit `a6b7e3666` -- that short SHA resolves to `a6b7e36668f60fee6d2cd8dd142db5237c3b3f1f` on MiSTer-v6.18, subject byte-identical to THIS record's commit (see dependencies.duplicate_of), i.e. it is the v6.18-branch re-port of this same v5.15 change, not a separate unrecorded commit -- so 0040's real origin record is this one. Added above as `carried_patches` so reduce.py's orphan-carried-patch invariant (single `carried_patch` field only, previously) stops flagging 0040 as unmapped; `carried_patch` stays 0032, the schema's canonical single-value field. | RETIRED 2026-09-12: 0040-hid-nintendo-imu-name-suffix.patch was deleted from board/mister/de10nano/linux-patches/ (and the beta/DE25 symlinks). Offered upstream as Linux-Kernel_MiSTer PR #96; the maintainer closed it in favour of the userspace fix, Main_MiSTer #1307 (in Release 20260912), so the kernel keeps mainline's name and nothing carries it. Dropped from carried_patches so reduce.py's mapping stays truthful; 0032 is unaffected and stays carried.", "provenance_doc_ref": "patch-provenance.md:334", "removed": 2, "sha": "45283785a7ace3263f7c165ae6a4ec3055ebdcf6", "sonnet-verified": "confirmed \u2014 combo LED registration, vanilla absence, and full Main_MiSTer read/write/bind coupling all verified with direct quotes and line numbers; corrected the 'manual pairing fallback exists' claim in the prior draft (no such fallback exists) and upgraded disposition to misclassified per the grounding contract (contradicted + provenance doc claims upstream in a grouped row).", "subject": "hid-nintendo: add virtual combo led, don't warn by IMU compensation.", "subsystem": "hid", "upstream": {"equivalence": "contradicted", "vanilla_file_line": "drivers/hid/hid-nintendo.c:2235-2327 (joycon_leds_create, v6.18.38)", "vanilla_quote": "static int joycon_leds_create(struct joycon_ctlr *ctlr)\n{\n\t...\n\t/* configure the player LEDs */\n\t...\nhome_led:\n\t/* configure the home LED */\n\tif (jc_type_has_right(ctlr)) {\n\t\t...\n\t\tret = devm_led_classdev_register(&hdev->dev, led);\n\t\tif (ret) {\n\t\t\thid_err(hdev, \"Failed to register home LED; ret=%d\\n\", ret);\n\t\t\treturn ret;\n\t\t}\n\t}\n\n\treturn 0;\n}", "vanilla_shas": []}, "userspace_coupling": {"coupled": true, "interface": "/sys/.../leds/:combo/brightness (LED classdev registered by joycon_leds_create() in the fork commit; name format '%s:combo' with %s = dev_name(&hdev->dev), e.g. '0005:057E:2006.0001:combo')", "main_mister_ref": "input.cpp:2661-2674 set_led() and input.cpp:2676-2690 get_led() both fopen() the LED's 'brightness' sysfs file and silently return 0/no-op if it does not exist (no error logged) \u2014 this is the mechanism by which absence degrades silently. input.cpp:4689-4738 check_joycon() reads ':combo' via get_led() at lines 4704 and 4715 to recognize a matched Joy-Con pair on device rescan and, only if a nonzero shared id is read back, sets the actual pairing at input.cpp:4729-4730 (input[l].bind = r; input[r].bind = l). input.cpp:4785-4823 process_joycon() is the OTHER half of the handshake: on a specific 3-button hold (JOYCON_REQ, misc_flags&7==7) on both an unbound left and right Joy-Con, it writes a freshly-generated id to both controllers' ':combo' LED via set_led() at lines 4822-4823, then force-closes all input fds to trigger the rescan that re-invokes check_joycon(). Without the kernel-side combo LED classdev, the write at 4822-4823 is a silent no-op and the read at 4704/4715 always returns 0, so id_combo never matches and input[l]/input[r].bind is never set \u2014 pairing silently never completes, with no error surfaced to the user."}, "verification": {"confidence": "high", "contradiction": true, "method": "source-grep"}} {"added": 12, "agrees_with_provenance_doc": true, "author": "Sorgelig", "author_is_pr_contributor": false, "carried_mode": "clean-apply", "carried_patch": "0023-hid-wiimote-fixes.patch", "change_type": "in-tree-code", "date": "2019-05-05", "dependencies": {"depends_on": ["0d7778d1f (wiimote: set uniq field)"], "duplicate_of": [], "superseded_by": []}, "disposition": "carried", "files": ["drivers/hid/hid-wiimote-modules.c"], "forward_port": {"applies_to_6_18": true, "conflicts": null, "effort": "minimal"}, "impact": {"affected_hardware": ["Nintendo Wiimote (0x057e:0x0306)", "Nintendo Wiimote 2 (0x057e:0x0330)", "Wiimote Classic Controller extension"], "device_ids": ["057e:0306", "057e:0330"], "effect_if_absent": "Wiimote sends generic keyboard codes (KEY_LEFT/RIGHT/UP/DOWN/NEXT/PREVIOUS) instead of gamepad-appropriate codes (BTN_DPAD_LEFT/RIGHT/UP/DOWN/BTN_START/BTN_SELECT). This affects userspace input mapping\u2014devices expecting BTN_DPAD_* codes in their saved button mappings would not recognize KEY_* codes and vice versa.", "failure_mode": "silent", "severity": "feature-loss"}, "is_backport_of_vanilla": false, "license_provenance": null, "notes": "This commit is part of the tripartite wiimote fix grouped in patch 0023 (along with 0d7778d1f and 15968bc26). The button code change is INTENTIONAL and NOT upstream\u2014vanilla 6.18.38 still uses KEY_LEFT/RIGHT/UP/DOWN/NEXT/PREVIOUS for wiimote d-pad and plus/minus buttons, confirmed by git show v6.18.38:drivers/hid/hid-wiimote-modules.c. MiSTer maintainers deliberately chose BTN_DPAD_* as more semantically correct for a gamepad device (not a remote control). The patch is forward-ported cleanly to 6.18 with NO file-layout conflicts. FAILURE_MODE=SILENT: patch 0023 has shipped in every MiSTer image since 2019, so any wiimote .map file a real user has actually saved was captured against BTN_DPAD_*/BTN_START/BTN_SELECT codes (what the running kernel has always emitted). If this carry were DROPPED in a future forward-port, the kernel would revert to emitting KEY_LEFT/RIGHT/UP/DOWN/NEXT/PREVIOUS, and those existing BTN_DPAD_*-keyed .map file entries would silently stop matching incoming events \u2014 not the reverse. [CORRECTED during sonnet review: an earlier draft of this note had the direction backwards, describing .map files 'containing KEY_LEFT' as the ones that would break; that is wrong \u2014 a KEY_LEFT-keyed map file only exists if authored against an unpatched/dropped kernel, and dropping this carry would make such a file work again, not break it.] No upstream equivalent exists for this commit (confirmed: git log -S 'BTN_DPAD_LEFT' -- drivers/hid/hid-wiimote-modules.c yields only b8e0fe31a7c8 (2013), which added BTN_DPAD_* to a new 'pro_map' array for Wii U Pro Controller, not to wiimod_keys_map or wiimod_classic_map). For users upgrading from stock to MiSTer: automatic button mapping (Main_MiSTer's default on device connection) adapts to any codes, so the change is transparent; only manual mapping authors would notice. Severity/framing note: because carrying this patch simply preserves the behavior every MiSTer user has always had, the risk this record should emphasize is drop-risk (breaking existing BTN_DPAD_*-keyed .map files on a future kernel bump that fails to re-carry this delta), not any deficiency in the current shipped state \u2014 impact.effect_if_absent already reflects this correctly ('devices expecting BTN_DPAD_* codes ... would not recognize KEY_* codes').", "provenance_doc_ref": "patch-provenance.md:370, :1154", "removed": 12, "sha": "47dc53a22a31c8cabbe21213084e958a973cfc6d", "sonnet-verified": "carry-mapping into 0023 confirmed exact (button-remap hunks match fork commit verbatim, wiimod_keys_map and wiimod_classic_map both changed as claimed); Main_MiSTer citations spot-checked at input.cpp:2942 (input_cb), :2741 (057e LED handling), :3099-3101 and :3661-3667 (mmap[]-based event-code comparison) \u2014 all accurate; AMENDED a direction error in notes: the record had .map files 'containing KEY_LEFT' breaking on drop, when it is actually BTN_DPAD_*-keyed files (the ones real users actually have, since this patch has shipped since 2019) that break if the carry is dropped", "subject": "wiimote: fix the buttons codes.", "subsystem": "hid", "upstream": {"equivalence": "contradicted", "vanilla_file_line": null, "vanilla_quote": null, "vanilla_shas": []}, "userspace_coupling": {"coupled": true, "interface": "input event codes; input_report_key() emits BTN_DPAD_LEFT/RIGHT/UP/DOWN and BTN_START/BTN_SELECT instead of KEY_LEFT/RIGHT/UP/DOWN and KEY_NEXT/KEY_PREVIOUS", "main_mister_ref": "input.cpp uses generic EV_KEY event handling with button mapping system (mmap[] array in struct input_dev). Event codes are mapped through input_cb() at line 2942+ and compared against mmap[] entries at lines 3099-3101, 3661-3667. No hardcoded wiimote button codes found, but user-created .map files store exact event codes; changing kernel codes breaks existing mappings. Grep for '057e' at input.cpp:2741 (LED handling only, no button code dependency)."}, "verification": {"confidence": "high", "contradiction": false, "method": "source-grep"}} {"added": 17, "agrees_with_provenance_doc": true, "author": "Aurora", "author_is_pr_contributor": true, "carried_mode": "re-implemented", "carried_patch": "0015-hid-nintendo-nso-famicom.patch", "change_type": "in-tree-code", "date": "2025-06-16", "dependencies": {"depends_on": [], "duplicate_of": [], "superseded_by": []}, "disposition": "carried", "files": ["drivers/hid/hid-nintendo.c"], "forward_port": {"applies_to_6_18": true, "conflicts": null, "effort": null}, "impact": {"affected_hardware": ["Nintendo Switch Online Famicom controller I (type 0x07)", "Nintendo Switch Online Famicom controller II (type 0x08)"], "device_ids": ["057e:2007"], "effect_if_absent": "NSO Famicom controllers probe successfully but register no buttons or axes\u2014completely dead gamepad with nothing in kernel logs (silent feature loss)", "failure_mode": "silent", "severity": "feature-loss"}, "is_backport_of_vanilla": false, "license_provenance": null, "notes": "CARRIED: patch 0015-hid-nintendo-nso-famicom.patch landed as P1.9-esc (re-implementation, not rebase). The original 5.15 commit was written against a macro-based type-detection idiom (#define jc_type_is_nescon, jc_type_is_joycon, jc_type_is_nso, jc_has_rumble). Upstream 6.18.38 completely reorganized hid-nintendo.c, replacing all these macros with typed static inline bool helper functions (joycon_type_is_*). The carried patch re-implements the feature against the new helper scheme, with additional refinements: (1) joycon_ctlr_button_mapping tables replace flat BTN_* arrays; (2) Famicom controller I reuses nescon_button_mappings (same buttons/bits as NES pad); (3) Famicom controller II gets its own famicom_r_button_mappings for A/B/L/R only (no SELECT/START, microphone not exposed). SILENT FAILURE MODE: Without this patch, Famicom pads report controller type 0x07/0x08 which every capability helper (joycon_has_imu, joycon_has_joysticks, joycon_has_rumble) treats as unknown\u2014pads probe but create completely dead input devices with no buttons or axes. HISTORICAL NOTE (superseded, do not treat as current behavior): as originally landed, patch 0015's famicom_r_button_mappings (and nescon_button_mappings) followed the positional convention A=BTN_SOUTH/B=BTN_EAST, matching upstream NSO NES/SNES/N64/Genesis pads but not stock MiSTer's A=BTN_EAST/B=BTN_SOUTH convention. SUPERSEDED: patch 0034-hid-nintendo-nes-famicom-stock-ab-mapping.patch (carrying e155f6a2f5fe088527f7c01e637e7c51b18a5695's A/B intent per its own record, RESOLVED 2026-07-14/15) subsequently swapped BOTH nescon_button_mappings and this patch's famicom_r_button_mappings to the stock assignment (A=BTN_EAST, B=BTN_SOUTH). As currently applied (0015+0034 together), the Famicom controllers' A/B buttons DO match stock MiSTer; the paragraph above describing 'not stock MiSTer' is the pre-0034 state only and must not be read as current behavior.\n\nsonnet-verified: carry-mapping to 0015 confirmed exact (patch diff matches fork commit's enum/macro/table additions verbatim: JOYCON_CTLR_TYPE_FAML=0x07/FAMR=0x08 in the fork become FAML/FAMR unchanged in the carried patch too; famicom_r_button_mappings A/B/L/R-only table, joycon_type_is_left_famicom()/right_famicom() helper idiom all verified against the live patch file). Device ID re-derived: 057e:2007 confirmed against /mnt/source/linux/drivers/hid/hid-ids.h (USB_DEVICE_ID_NINTENDO_JOYCONR=0x2007) and the fork commit's own message ('report themselves... with the Joy-Con (R) product ID, 057e:2007'). vanilla_file_line drivers/hid/hid-nintendo.c:315-324 spot-checked against live 6.18.38 checkout: line 315 is the enum opening brace, 316-323 the eight type values, 324 the closing brace -- exact match, no correction needed. MAIN FINDING (per task instruction to check for staleness against patch 0034): the record's A/B mapping note was accurate for 0015 as originally landed but had gone stale/self-contradictory once 0034 (dated 2026-07-15, present in linux-patches/) swapped both nescon_button_mappings and 0015's famicom_r_button_mappings to the stock A=BTN_EAST/B=BTN_SOUTH convention -- confirmed by reading 0034-hid-nintendo-nes-famicom-stock-ab-mapping.patch directly and cross-checked against sibling record e155f6a2f5fe088527f7c01e637e7c51b18a5695.json's RESOLVED note ('the A/B assignment divergence is restored to stock via 0034 (also aligns 0015's Famicom tables)'). Corrected in this record's notes above; no other field required amendment (disposition/carried_patch/carried_mode/device_ids/userspace_coupling=false all confirmed correct as generic BTN_* codes with no Main_MiSTer-specific dependency).", "provenance_doc_ref": "docs/patch-provenance.md:9.2", "removed": 1, "sha": "484f681720ca5037042a8d3b89158e6d3af09563", "subject": "input: Add support for the NSO Famicom controllers (no mic for Famicom R) (#62)", "subsystem": "hid", "upstream": {"equivalence": null, "vanilla_file_line": "drivers/hid/hid-nintendo.c:315-324", "vanilla_quote": "enum joycon_ctlr_type {\n\tJOYCON_CTLR_TYPE_JCL = 0x01,\n\tJOYCON_CTLR_TYPE_JCR = 0x02,\n\tJOYCON_CTLR_TYPE_PRO = 0x03,\n\tJOYCON_CTLR_TYPE_NESL = 0x09,\n\tJOYCON_CTLR_TYPE_NESR = 0x0A,\n\tJOYCON_CTLR_TYPE_SNES = 0x0B,\n\tJOYCON_CTLR_TYPE_GEN = 0x0D,\n\tJOYCON_CTLR_TYPE_N64 = 0x0C,\n};", "vanilla_shas": []}, "userspace_coupling": {"coupled": false, "interface": "Generic input event codes: BTN_SOUTH/BTN_EAST/BTN_TL/BTN_TR for D-pad and four face buttons (Famicom II uses dedicated 4-button set; Famicom I reuses NES layout). No Main_MiSTer direct dependency identified.", "main_mister_ref": null}, "verification": {"confidence": "high", "contradiction": false, "method": "diff"}} {"added": 15, "agrees_with_provenance_doc": true, "author": "Sorgelig", "author_is_pr_contributor": false, "carried_mode": "re-implemented", "carried_patch": "0026-input-mousedev-eviocgrab.patch", "change_type": "in-tree-code", "date": "2021-08-20", "dependencies": {"depends_on": [], "duplicate_of": [], "superseded_by": []}, "disposition": "carried", "files": ["drivers/input/mousedev.c"], "forward_port": {"applies_to_6_18": true, "conflicts": null, "effort": "moderate"}, "impact": {"affected_hardware": ["DualShock4", "DualShock4 variant 2", "DualShock4 Wireless Dongle", "DualSense"], "device_ids": ["054c:05c4", "054c:09cc", "054c:0ba0", "054c:0ce6"], "effect_if_absent": "DualShock4 and DualSense touchpad would emit spurious left-click button events every time a finger is lifted from the pad; this breaks touchpad-as-mouse input functionality and causes unintended button presses in cores that use the touchpad as a pointing device", "failure_mode": "silent", "severity": "feature-loss"}, "is_backport_of_vanilla": false, "license_provenance": "GPL (kernel in-tree code)", "notes": "CARRIED in patch 0026-input-mousedev-eviocgrab.patch, forward-ported 2026-07-12 by Michael C. Ferguson (task P1.9-esc). Patch 0026 re-implements the original commit with: (1) type change int\u2192bool for dis_t2c field, (2) added documentation comment, (3) macros extracted for device IDs (MOUSEDEV_VENDOR_ID_SONY, MOUSEDEV_DEVICE_ID_SONY_PS4_CONTROLLER, etc.) instead of inline hex values. Device IDs verified against official hid-ids.h (6.18.38: USB_VENDOR_ID_SONY=0x054c, USB_DEVICE_ID_SONY_PS4_CONTROLLER=0x05c4, USB_DEVICE_ID_SONY_PS4_CONTROLLER_2=0x09cc, USB_DEVICE_ID_SONY_PS4_CONTROLLER_DONGLE=0x0ba0, USB_DEVICE_ID_SONY_PS5_CONTROLLER=0x0ce6). USERSPACE COUPLING is explicit and load-bearing: Main_MiSTer input.cpp explicitly detects these device IDs (line 5277) and names (line 5280) to set QUIRK_DS4TOUCH for reading the controller's touchpad as a pointing device through /dev/input/mouseN (input.cpp:5237 writes ImPS/2 mode, :5728-5743 reads as lightgun or regular pointing device). Vanilla 6.18.38 has no dis_t2c field and unconditionally emulates tap-to-click on all touchpads via set_bit/clear_bit in mousedev_touchpad_touch() (equivalence=contradicted). This is a deliberate MiSTer-specific behaviour change to suppress the synthetic tap-to-click emulation for game controllers, which are used as plain pointing devices (e.g., light gun simulators in arcade cores) rather than traditional laptop touchpads. Patch-provenance.md groups this commit with 2ac0aa1e8 (EVIOCGRAB support) in a single row (0026), but they are functionally independent: dis_t2c suppression works without EVIOCGRAB, and EVIOCGRAB works without dis_t2c. The grouping is accurate for patch-level tracking but this commit analysis is independent per P1.9 worker instructions.", "provenance_doc_ref": "patch-provenance.md line 373", "removed": 4, "sha": "52a56ae3dc7f82ff6339c1be1de05d8b2d997ef9", "sonnet-verified": "carry-mapping into 0026 confirmed exact (fork commit's dis_t2c hunks present in applied patch, macro-ized as claimed); device IDs 054c:05c4/09cc/0ba0/0ce6 verified byte-for-byte against /mnt/source/linux/drivers/hid/hid-ids.h (USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER[/_2/_DONGLE], USB_DEVICE_ID_SONY_PS5_CONTROLLER); main_mister_ref spot-checked at input.cpp:5266-5285 (QUIRK_DS4TOUCH assignment) and input.cpp:5727-5743 (touchpad-as-lightgun quirk handling) \u2014 both accurate", "subject": "mousedev: disable touch to click on DualShock4 and DualSense.", "subsystem": "input", "upstream": {"equivalence": "contradicted", "vanilla_file_line": "drivers/input/mousedev.c:374-401", "vanilla_quote": "static void mousedev_touchpad_touch(struct mousedev *mousedev, int value)\n{\n\tif (!value) {\n\t\tif (mousedev->touch &&\n\t\t time_before(jiffies,\n\t\t\t\tmousedev->touch + msecs_to_jiffies(tap_time))) {\n\t\t\t/*\n\t\t\t * Toggle left button to emulate tap.\n\t\t\t * We rely on the fact that mousedev_mix always has 0\n\t\t\t * motion packet so we won't mess current position.\n\t\t\t */\n\t\t\tset_bit(0, &mousedev->packet.buttons);\n\t\t\tset_bit(0, &mousedev_mix->packet.buttons);\n\t\t\tmousedev_notify_readers(mousedev, &mousedev_mix->packet);\n\t\t\tmousedev_notify_readers(mousedev_mix,\n\t\t\t\t\t\t&mousedev_mix->packet);\n\t\t\tclear_bit(0, &mousedev->packet.buttons);\n\t\t\tclear_bit(0, &mousedev_mix->packet.buttons);\n\t\t}", "vanilla_shas": []}, "userspace_coupling": {"coupled": true, "interface": "/dev/input/mouseX (mousedev driver)", "main_mister_ref": "input.cpp:5277-5282 (QUIRK_DS4TOUCH device detection by product ID and touchpad name), input.cpp:5728-5743 (touchpad read as lightgun input)"}, "verification": {"confidence": "high", "contradiction": false, "method": "diff"}} {"added": 3, "agrees_with_provenance_doc": true, "author": "Sorgelig", "author_is_pr_contributor": false, "carried_mode": "re-implemented", "carried_patch": "0018-hid-controllable-quirk.patch", "change_type": "in-tree-code", "date": "2021-09-08", "dependencies": {"depends_on": ["CONFIG_HID_PANTHERLORD=y (verified present in linux.config)"], "duplicate_of": [], "superseded_by": []}, "disposition": "carried", "files": ["drivers/hid/hid-pl.c", "drivers/hid/hid-quirks.c"], "forward_port": {"applies_to_6_18": true, "conflicts": null, "effort": "minimal"}, "impact": {"affected_hardware": ["ControllaBLE Bluetooth gamepad"], "device_ids": ["1209:FACA"], "effect_if_absent": "ControllaBLE Bluetooth gamepad (VID:PID 1209:FACA) would enumerate as generic HID input device instead of being routed through hid-pl.c (PANTHERLORD dual-PSX-adapter quirk handler); device would not be recognized correctly for MiSTer input mapping, and the HID_QUIRK_MULTI_INPUT (driver_data=1) would not be applied, breaking dual-input handling.", "failure_mode": "silent", "severity": "feature-loss"}, "is_backport_of_vanilla": false, "license_provenance": null, "notes": "Device uses pid.codes VID 0x1209 (shared/test ID namespace) with PID 0xFACA. ControllaBLE is a Bluetooth gamepad that emulates Twin-USB-Joystick protocol. Commit adds device to both hid-pl.c device table (with HID_QUIRK_MULTI_INPUT flag via driver_data=1) and hid-quirks.c special-driver list. Forward-ported to 6.18.38 with comment correction (original had copy-paste 'Twin USB Joystick' comment from adjacent GAMERON entry; fixed to 'ControllaBLE'). Matches provenance-doc claim: disposition=carry, class D. Vanilla 6.18.38 source confirms device ID not present in upstream drivers/hid/hid-pl.c or hid-quirks.c. Strong userspace coupling via Main_MiSTer input device recognition and mode detection.\n\nRECONCILIATION (per task instruction): a separate record, 0d7b4fc7edacc66a8c8a30c7b2616518022a4374.json ('Enable CONFIG_PANTHERLORD_FF'), had its device_ids list corrected by a prior verifier pass to REMOVE '1209:FACA / ControllaBLE', with the note 'exhaustive grep of drivers/hid/*.c and hid-ids.h for 0x1209, 0xFACA, and ControllaBLE found zero matches; this device ID does not appear anywhere in the pl_devices[] table or the kernel tree and was hallucinated in the original pass.' These two findings do NOT contradict each other: 0d7b4fc7e's commit is a KCONFIG-only change (enables CONFIG_PANTHERLORD_FF in the fork's 5.15 defconfig) whose disposition is dropped-deliberate/superseded because the option is already on in OUR linux.config, which tracks vanilla 6.18's hid-pl.c pl_devices[] table -- and 1209:FACA genuinely does NOT exist in VANILLA's pl_devices[] table (confirmed independently: it is a MiSTer-fork-only addition). THIS commit (5bdbf2f7e) is the actual origin of 1209:FACA: it adds the device-table entry to hid-pl.c/hid-quirks.c directly, is carried verbatim (modulo one comment fix) as patch 0018-hid-controllable-quirk.patch, and 1209:FACA IS present in our patched tree (confirmed via `git show 5bdbf2f7e -- drivers/hid/hid-pl.c drivers/hid/hid-quirks.c` and by reading 0018-hid-controllable-quirk.patch directly) and in linux-patches/0018, which board/mister/de10nano applies on top of vanilla. So 0d7b4fc7e's 'hallucinated relative to the kernel tree' finding was scoped to VANILLA (correct), while this record's claim is scoped to OUR patched tree via patch 0018 (also correct) -- no error in either record, just different trees under discussion; 0d7b4fc7e's notes did not make that tree distinction explicit, which is what prompted this cross-check.\n\nsonnet-verified: carry-mapping to 0018-hid-controllable-quirk.patch confirmed exact -- `git show 5bdbf2f7e65510acf8c4e2bf484c0be3b72c06d2` diff (hid-pl.c: `+ { HID_BLUETOOTH_DEVICE(0x1209, 0xFACA), .driver_data = 1 }, /* Twin USB Joystick */`; hid-quirks.c: `+ { HID_BLUETOOTH_DEVICE(0x1209, 0xFACA) },`) matches the carried patch's hunks exactly, modulo the documented comment fix ('Twin USB Joystick' -> 'ControllaBLE'). Device ID 1209:FACA re-derived independently from the live fork diff -- correct as stated. Main_MiSTer citations re-verified byte-exact: input.cpp:4174 is literally `make_unique(0x1209, 0xFACA, 1); // ControllaBLE` and input.cpp:5506 is literally `else if (input[n].vid == 0x1209 && (input[n].pid == 0xFACE || input[n].pid == 0xFACA))` -- both confirmed correct, no change needed. CONFIG_HID_PANTHERLORD=y confirmed present at linux.config:329. provenance_doc_ref was WRONG (cited 'line ~33', which is unrelated prose about the v5.15.1 baseline-verification procedure, nowhere near this commit) and has been corrected to the actual row at patch-provenance.md:366. Added the reconciliation paragraph above per task instruction; no disposition/severity/coupling changes needed otherwise.", "provenance_doc_ref": "patch-provenance.md:366, \u00a73.4 Class D: explicitly listed as carried via 0018-hid-controllable-quirk.patch", "removed": 0, "sha": "5bdbf2f7e65510acf8c4e2bf484c0be3b72c06d2", "subject": "hid: add quirk for ControllaBLE.", "subsystem": "hid", "upstream": {"equivalence": null, "vanilla_file_line": null, "vanilla_quote": null, "vanilla_shas": []}, "userspace_coupling": {"coupled": true, "interface": "HID input device ID matching for device-specific input mapping and mode detection", "main_mister_ref": "Main_MiSTer/input.cpp:4174 (make_unique call for ControllaBLE device setup) and line 5506 (device ID detection for dual-input handling)"}, "verification": {"confidence": "high", "contradiction": false, "method": "source-grep"}} {"added": 2, "agrees_with_provenance_doc": true, "author": "Sorgelig", "author_is_pr_contributor": false, "carried_mode": "re-implemented", "carried_patch": "0022-hid-playstation-ds4-mac-fix.patch", "change_type": "in-tree-code", "date": "2025-11-06", "dependencies": {"depends_on": [], "duplicate_of": [], "superseded_by": []}, "disposition": "carried", "files": ["drivers/hid/hid-sony.c"], "forward_port": {"applies_to_6_18": true, "conflicts": null, "effort": "carried via 0022-hid-playstation-ds4-mac-fix.patch; re-targeted to dualshock4_get_mac_address() in hid-playstation.c instead of sony_check_add() in hid-sony.c"}, "impact": {"affected_hardware": ["3rd-party wired DualShock4 controllers"], "device_ids": ["054c:05c4", "054c:09cc", "054c:0ba0"], "effect_if_absent": "3rd-party wired DualShock4 clones that don't implement the vendor-specific DS4_FEATURE_REPORT_0x81 (MAC address retrieval) will fail to connect when wired via USB. The device probe will abort with an error return, preventing the device from binding to the driver and becoming unusable.", "failure_mode": "loud", "severity": "feature-loss"}, "is_backport_of_vanilla": false, "license_provenance": null, "notes": "The fork commit targets hid-sony.c's sony_check_add() function (5.15 kernel). In vanilla 6.18, DualShock4 support was split into a new hid-playstation.c driver (commit 8c0ab553b072 et al.). The carried patch 0022-hid-playstation-ds4-mac-fix.patch applies the same semantic fix (making MAC address retrieval failure non-fatal) to dualshock4_get_mac_address() in hid-playstation.c. Verified: vanilla v6.18.38 hid-playstation.c still has hard-fail-on-read-error behavior at lines 2130-2132 (goto err_free on ps_get_report failure). The carried patch remediates this for 3rd-party DS4 clones that lack vendor feature report support. Re-implementation confirmed: both changes comment-out/skip error handling to allow continued operation with zeroed/uninitialized MAC address data. Classification matches patch-provenance.md: 'Re-targeted; carried as 0022-hid-playstation-ds4-mac-fix.patch'.\n\nsonnet-verified: PASS. Re-ran `git show` on fork commit 5c410e935 (drivers/hid/hid-sony.c sony_check_add(), comments out the `goto out_free` hard-fail) and read /mnt/source/linux/drivers/hid/hid-playstation.c:2117-2155 directly -- vanilla 6.18.38's dualshock4_get_mac_address() still does `hid_err(...); goto err_free;` at exactly lines 2130-2132 on ps_get_report() failure, confirming the cited lines and hard-fail claim verbatim. Re-derived device IDs independently from /mnt/source/linux/drivers/hid/hid-ids.h:1277-1279 (USB_DEVICE_ID_SONY_PS4_CONTROLLER=0x05c4, _2=0x09cc, _DONGLE=0x0ba0) and hid-playstation.c's hid_device_id table (lines ~2896-2914, all under USB_VENDOR_ID_SONY=0x054c) -- 054c:05c4/09cc/0ba0 are correct, not transposed. Carried patch 0022-hid-playstation-ds4-mac-fix.patch exists and matches the described re-targeting exactly (same non-fatal-continue semantics, plus removal of the now-unreferenced err_free label). Confirmed the companion commit 1412bd7075d24db01785f0749f8efe498f24181d (grouped with this one in patch-provenance.md:369's row) has its own separate record file (1412bd7075d24db01785f0749f8efe498f24181d.json) and is correctly NOT folded into this record -- the grouped provenance-doc row does not indicate a grouping error in the recon records themselves. Tightened provenance_doc_ref with precise line citations. No disposition or vocabulary errors found.", "provenance_doc_ref": "patch-provenance.md:369 (Class D summary table, grouped row '1412bd707, 5c410e935'), :1029-1034 (dedicated note: '5c410e935 ... is NOT superseded, but its target moved ... Re-targeted; carried as 0022-hid-playstation-ds4-mac-fix.patch'), :1153 (0022 patch landed-status row)", "removed": 2, "sha": "5c410e935d4f9743d9d71a0d0d796258544eba91", "subject": "hid-sony: fix for 3rd party DS4 failing to connect by wire.", "subsystem": "hid", "upstream": {"equivalence": null, "vanilla_file_line": null, "vanilla_quote": null, "vanilla_shas": []}, "userspace_coupling": {"coupled": false, "interface": null, "main_mister_ref": null}, "verification": {"confidence": "high", "contradiction": false, "method": "source-grep"}} -{"added": 2, "agrees_with_provenance_doc": false, "author": "Sorgelig", "author_is_pr_contributor": false, "carried_mode": "re-implemented", "carried_patch": "0035-hid-nintendo-home-led-nonfatal.patch", "carried_patches": ["0035-hid-nintendo-home-led-nonfatal.patch", "0041-hid-nintendo-stock-led-classdev-names.patch"], "change_type": "in-tree-code", "date": "2021-08-12", "dependencies": {"depends_on": [], "duplicate_of": [], "superseded_by": []}, "disposition": "carried", "files": ["drivers/hid/hid-nintendo.c"], "forward_port": {"applies_to_6_18": true, "conflicts": true, "effort": "low"}, "impact": {"affected_hardware": ["Nintendo Pro Controller", "Nintendo Joy-Con (R)", "Nintendo Charging Grip (right Joy-Con instance)"], "device_ids": ["057e:2009", "057e:2007", "057e:200E"], "effect_if_absent": "If devm_led_classdev_register() itself fails for the home LED (kernel-side sysfs/allocation failure, e.g. -ENOMEM or name collision \u2014 NOT the same as the controller lacking home-LED hardware), joycon_leds_create() returns the error, nintendo_hid_probe() takes the err_close path, and the ENTIRE controller (all buttons/sticks, not just the LED) fails to bind \u2014 the device is unusable, not just missing a home LED. This only happens for controller types that reach the home-LED branch: Pro Controller and right Joy-Con (jc_type_has_right() gate at hid-nintendo.c:654-656 requires ctlr_type == JCR(0x02) or PRO(0x03)). Left Joy-Con, SNES/N64/Genesis NSO controllers have distinct ctlr_type values (JCL=0x01, SNES=0x0B, N64=0x0C, GEN=0x0D) and never enter this code path at all, so they cannot be affected by this specific commit regardless of vanilla vs fork. Separately, the 'clone controller doesn't support home LED at all' scenario (the SET failure at joycon_set_home_led(), lines 2310-2317) is already non-fatal in vanilla 6.18.38 via a different code path (skip registration, return 0) \u2014 no regression there.", "failure_mode": "loud", "severity": "feature-loss"}, "is_backport_of_vanilla": false, "license_provenance": null, "notes": "VERIFIED. Fork diff (drivers/hid/hid-nintendo.c, joycon_leds_create()) confirmed by `git show 60821059c`: both `return ret;` statements are commented out \u2014 (1) after `devm_led_classdev_register()` fails ('Failed registering home led'), (2) after `joycon_home_led_brightness_set()` fails ('Failed to set home LED dflt; ret=%d'). Both error paths become non-fatal in the fork.\n\nVanilla 6.18.38 history (all three SHAs confirmed via `git log`/`git show`/`git merge-base --is-ancestor` in /mnt/source/linux, checked out at tag v6.18.38):\n- `2af16c1f846b` (2021-09-11, Daniel J. Ogorchock) is simply the original upstream addition of hid-nintendo.c (869 lines, new file). It predates the fork's 2021-08-12 commit chronologically upstream (the fork's driver was an out-of-tree precursor) and, critically, is NOT specifically about home-LED error handling \u2014 at that point both the SET and REGISTER paths were still fully fatal upstream. Citing it as 'upstream coverage' for 60821059c's behavior (as patch-provenance.md:334's grouped row does) is not correct for this specific commit's effect.\n- `8b30fb40f8f2` (2022-04-15, Icenowy Zheng, 'HID: nintendo: deregister home LED when it fails') is the real fix for the 'clone controller doesn't support home LED' scenario described in its own commit message ('Some Pro Controller compatible controllers do not support home LED, and will fail when setting it. Currently this leads to probe failure.'). At the time, code order was register-then-set (matching the fork's pre-image exactly, including the literal string 'Failed to set home LED dflt; ret=%d'). The fix changed the post-registration SET failure from `hid_err(...); return ret;` to `hid_warn(...); devm_led_classdev_unregister(&hdev->dev, led);` (implicit `return 0`) \u2014 non-fatal. It did NOT touch the REGISTRATION failure, which remained `return ret;` (fatal) at that point in history.\n- `928276075f16` (2023-09-24, Martino Fontana, 'HID: nintendo: cleanup LED code') refactored the order to set-before-register: a new `joycon_set_home_led()` helper is called first, and only on success does `devm_led_classdev_register()` run. This is the current v6.18.38 shape (lines 2310-2323). SET failure is still non-fatal (skip registration, `return 0`) but implemented via a different mechanism than 8b30fb40f8f2's register+unregister approach. REGISTRATION failure is STILL untouched \u2014 `hid_err(...); return ret;` at 2319-2323 remains exactly as fatal as it was in 2021.\n\nConclusion: equivalence is PARTIAL, not fully contradicted and not fully equivalent. The SET-failure path (the actual 'clone controller lacks home LED hardware' scenario that motivated both the fork's patch and 8b30fb40f8f2's commit message) is equivalent/superseded-better upstream \u2014 dropping the fork's SET-path comment-out is safe. The REGISTRATION-failure path is a genuine, never-addressed gap: vanilla still hard-fails the ENTIRE controller probe (not just the LED) if devm_led_classdev_register() itself errors, while the fork tolerated it. This is a real carry candidate for that one residual line (hid-nintendo.c:2322 `return ret;`), though its real-world trigger probability is low \u2014 devm_led_classdev_register() failing is a kernel resource/sysfs issue (OOM, name collision), not a controller-hardware-capability issue; the hardware-capability case is already the SET path and is already fixed upstream. Only Pro Controller and right Joy-Con (including via Charging Grip) reach this code at all (jc_type_has_right() gate); left Joy-Con, SNES, N64, and Genesis NSO controllers have distinct ctlr_type values and never execute joycon_leds_create()'s home-LED branch, so the original record's affected_hardware/device_ids list (which included Joy-Con L, SNES, N64, Mega Drive) was overbroad and has been corrected here.\n\npatch-provenance.md:334 is a GROUPED ROW (c4ec5cb40, 9bdab534b, 60821059c, 45283785a all mapped to 2af16c1f846b, labeled Class C 'now upstream (drop)'). For this specific commit that classification is not fully accurate \u2014 hence disposition=misclassified rather than dropped-upstream, per the pilot-lesson rule (contradicted/partial-with-real-gap + provenance doc claimed upstream coverage \u21d2 misclassified). Not carried in our build: grepped board/mister/de10nano/linux-patches/ for home-LED/joycon_leds_create strings \u2014 only hit is 0015-hid-nintendo-nso-famicom.patch, which does not touch LED code at all (confirmed via grep, no 'home'/'led'/'LED' matches). So this behavior is neither carried-by-patch nor fully dropped-upstream; it is a partial, unflagged silent gap for the registration-failure branch specifically.\n\nsonnet-verified: partial equivalence confirmed \u2014 vanilla 6.18.38 (via 8b30fb40f8f2 + 928276075f16) makes the SET-failure path non-fatal, matching the fork's intent for genuine clone-controller-lacks-home-LED cases, but the REGISTRATION-failure path (hid-nintendo.c:2319-2323, `return ret;`) remains fatal in vanilla exactly as it was in 2021, unlike the fork which tolerated it too \u2014 real (if low-probability) carry candidate, and patch-provenance.md:334's grouped 'now upstream, drop' classification is not fully accurate for this commit. | RESOLVED (user carry decision 2026-07-14/15 (see silent-regressions.md + git d2f2791 follow-ups)): carried as 0035 \u2014 home-LED registration failure now warn+continue on 6.18. WAVE 3 LEDGER FIX (2026-09-11): this commit (docs/patch-provenance.md \u00a711's '0041' row cites it as '60821059c') is ALSO the origin of 0041-hid-nintendo-stock-led-classdev-names.patch (the stock player1-4/home LED classdev-name fix, a separable hunk of the same origin diff as 0035's registration fix). Added above as `carried_patches` so reduce.py's orphan-carried-patch invariant (which previously read only the single `carried_patch` field) stops flagging 0041 as unmapped; `carried_patch` stays 0035, the schema's canonical single-value field.", "provenance_doc_ref": "patch-provenance.md:334", "removed": 2, "sha": "60821059c0d3b28b26729fdbe2719e7b4186aaba", "subject": "hid-nintendo: don't fail if home led is not present.", "subsystem": "hid", "upstream": {"equivalence": "partial", "vanilla_file_line": "drivers/hid/hid-nintendo.c:2310-2323", "vanilla_quote": "SET path (2310-2317, non-fatal \u2014 equivalent to fork intent):\n\t\t/* Set the home LED to 0 as default state */\n\t\tmutex_lock(&ctlr->output_mutex);\n\t\tret = joycon_set_home_led(ctlr, 0);\n\t\tmutex_unlock(&ctlr->output_mutex);\n\t\tif (ret) {\n\t\t\thid_warn(hdev, \"Failed to set home LED, skipping registration; ret=%d\\n\", ret);\n\t\t\treturn 0;\n\t\t}\n\nREGISTER path (2319-2323, still FATAL \u2014 never fixed upstream, contradicts fork):\n\t\tret = devm_led_classdev_register(&hdev->dev, led);\n\t\tif (ret) {\n\t\t\thid_err(hdev, \"Failed to register home LED; ret=%d\\n\", ret);\n\t\t\treturn ret;\n\t\t}", "vanilla_shas": ["2af16c1f846bd60240745bbd3afa13d5f040c61a", "8b30fb40f8f2c5e56b7af553a398340f92d17aae", "928276075f169d36f34e751ea5c81dd24d3a6823"]}, "userspace_coupling": {"coupled": true, "interface": "/sys/class/leds/:blue:player5/brightness (the \":home\" LED classdev created by joycon_leds_create())", "main_mister_ref": "Main_MiSTer/input.cpp:2761 \u2014 set_led(led_path, \":home\", num ? 1 : 15) inside the `input[dev].vid == 0x057e && ((input[dev].pid & 0xFF00) == 0x2000)` branch (input.cpp:2752). If the whole controller fails to probe (the residual registration-failure gap), this write silently no-ops (fopen() returns NULL, set_led() returns 0 at input.cpp:2665-2673) with no user-visible error from Main_MiSTer itself \u2014 the failure signal only exists in dmesg via hid_err()."}, "verification": {"confidence": "high", "contradiction": true, "method": "diff"}} +{"added": 2, "agrees_with_provenance_doc": false, "author": "Sorgelig", "author_is_pr_contributor": false, "carried_mode": "re-implemented", "carried_patch": "0035-hid-nintendo-home-led-nonfatal.patch", "carried_patches": ["0035-hid-nintendo-home-led-nonfatal.patch"], "change_type": "in-tree-code", "date": "2021-08-12", "dependencies": {"depends_on": [], "duplicate_of": [], "superseded_by": []}, "disposition": "carried", "files": ["drivers/hid/hid-nintendo.c"], "forward_port": {"applies_to_6_18": true, "conflicts": true, "effort": "low"}, "impact": {"affected_hardware": ["Nintendo Pro Controller", "Nintendo Joy-Con (R)", "Nintendo Charging Grip (right Joy-Con instance)"], "device_ids": ["057e:2009", "057e:2007", "057e:200E"], "effect_if_absent": "If devm_led_classdev_register() itself fails for the home LED (kernel-side sysfs/allocation failure, e.g. -ENOMEM or name collision \u2014 NOT the same as the controller lacking home-LED hardware), joycon_leds_create() returns the error, nintendo_hid_probe() takes the err_close path, and the ENTIRE controller (all buttons/sticks, not just the LED) fails to bind \u2014 the device is unusable, not just missing a home LED. This only happens for controller types that reach the home-LED branch: Pro Controller and right Joy-Con (jc_type_has_right() gate at hid-nintendo.c:654-656 requires ctlr_type == JCR(0x02) or PRO(0x03)). Left Joy-Con, SNES/N64/Genesis NSO controllers have distinct ctlr_type values (JCL=0x01, SNES=0x0B, N64=0x0C, GEN=0x0D) and never enter this code path at all, so they cannot be affected by this specific commit regardless of vanilla vs fork. Separately, the 'clone controller doesn't support home LED at all' scenario (the SET failure at joycon_set_home_led(), lines 2310-2317) is already non-fatal in vanilla 6.18.38 via a different code path (skip registration, return 0) \u2014 no regression there.", "failure_mode": "loud", "severity": "feature-loss"}, "is_backport_of_vanilla": false, "license_provenance": null, "notes": "VERIFIED. Fork diff (drivers/hid/hid-nintendo.c, joycon_leds_create()) confirmed by `git show 60821059c`: both `return ret;` statements are commented out \u2014 (1) after `devm_led_classdev_register()` fails ('Failed registering home led'), (2) after `joycon_home_led_brightness_set()` fails ('Failed to set home LED dflt; ret=%d'). Both error paths become non-fatal in the fork.\n\nVanilla 6.18.38 history (all three SHAs confirmed via `git log`/`git show`/`git merge-base --is-ancestor` in /mnt/source/linux, checked out at tag v6.18.38):\n- `2af16c1f846b` (2021-09-11, Daniel J. Ogorchock) is simply the original upstream addition of hid-nintendo.c (869 lines, new file). It predates the fork's 2021-08-12 commit chronologically upstream (the fork's driver was an out-of-tree precursor) and, critically, is NOT specifically about home-LED error handling \u2014 at that point both the SET and REGISTER paths were still fully fatal upstream. Citing it as 'upstream coverage' for 60821059c's behavior (as patch-provenance.md:334's grouped row does) is not correct for this specific commit's effect.\n- `8b30fb40f8f2` (2022-04-15, Icenowy Zheng, 'HID: nintendo: deregister home LED when it fails') is the real fix for the 'clone controller doesn't support home LED' scenario described in its own commit message ('Some Pro Controller compatible controllers do not support home LED, and will fail when setting it. Currently this leads to probe failure.'). At the time, code order was register-then-set (matching the fork's pre-image exactly, including the literal string 'Failed to set home LED dflt; ret=%d'). The fix changed the post-registration SET failure from `hid_err(...); return ret;` to `hid_warn(...); devm_led_classdev_unregister(&hdev->dev, led);` (implicit `return 0`) \u2014 non-fatal. It did NOT touch the REGISTRATION failure, which remained `return ret;` (fatal) at that point in history.\n- `928276075f16` (2023-09-24, Martino Fontana, 'HID: nintendo: cleanup LED code') refactored the order to set-before-register: a new `joycon_set_home_led()` helper is called first, and only on success does `devm_led_classdev_register()` run. This is the current v6.18.38 shape (lines 2310-2323). SET failure is still non-fatal (skip registration, `return 0`) but implemented via a different mechanism than 8b30fb40f8f2's register+unregister approach. REGISTRATION failure is STILL untouched \u2014 `hid_err(...); return ret;` at 2319-2323 remains exactly as fatal as it was in 2021.\n\nConclusion: equivalence is PARTIAL, not fully contradicted and not fully equivalent. The SET-failure path (the actual 'clone controller lacks home LED hardware' scenario that motivated both the fork's patch and 8b30fb40f8f2's commit message) is equivalent/superseded-better upstream \u2014 dropping the fork's SET-path comment-out is safe. The REGISTRATION-failure path is a genuine, never-addressed gap: vanilla still hard-fails the ENTIRE controller probe (not just the LED) if devm_led_classdev_register() itself errors, while the fork tolerated it. This is a real carry candidate for that one residual line (hid-nintendo.c:2322 `return ret;`), though its real-world trigger probability is low \u2014 devm_led_classdev_register() failing is a kernel resource/sysfs issue (OOM, name collision), not a controller-hardware-capability issue; the hardware-capability case is already the SET path and is already fixed upstream. Only Pro Controller and right Joy-Con (including via Charging Grip) reach this code at all (jc_type_has_right() gate); left Joy-Con, SNES, N64, and Genesis NSO controllers have distinct ctlr_type values and never execute joycon_leds_create()'s home-LED branch, so the original record's affected_hardware/device_ids list (which included Joy-Con L, SNES, N64, Mega Drive) was overbroad and has been corrected here.\n\npatch-provenance.md:334 is a GROUPED ROW (c4ec5cb40, 9bdab534b, 60821059c, 45283785a all mapped to 2af16c1f846b, labeled Class C 'now upstream (drop)'). For this specific commit that classification is not fully accurate \u2014 hence disposition=misclassified rather than dropped-upstream, per the pilot-lesson rule (contradicted/partial-with-real-gap + provenance doc claimed upstream coverage \u21d2 misclassified). Not carried in our build: grepped board/mister/de10nano/linux-patches/ for home-LED/joycon_leds_create strings \u2014 only hit is 0015-hid-nintendo-nso-famicom.patch, which does not touch LED code at all (confirmed via grep, no 'home'/'led'/'LED' matches). So this behavior is neither carried-by-patch nor fully dropped-upstream; it is a partial, unflagged silent gap for the registration-failure branch specifically.\n\nsonnet-verified: partial equivalence confirmed \u2014 vanilla 6.18.38 (via 8b30fb40f8f2 + 928276075f16) makes the SET-failure path non-fatal, matching the fork's intent for genuine clone-controller-lacks-home-LED cases, but the REGISTRATION-failure path (hid-nintendo.c:2319-2323, `return ret;`) remains fatal in vanilla exactly as it was in 2021, unlike the fork which tolerated it too \u2014 real (if low-probability) carry candidate, and patch-provenance.md:334's grouped 'now upstream, drop' classification is not fully accurate for this commit. | RESOLVED (user carry decision 2026-07-14/15 (see silent-regressions.md + git d2f2791 follow-ups)): carried as 0035 \u2014 home-LED registration failure now warn+continue on 6.18. WAVE 3 LEDGER FIX (2026-09-11): this commit (docs/patch-provenance.md \u00a711's '0041' row cites it as '60821059c') is ALSO the origin of 0041-hid-nintendo-stock-led-classdev-names.patch (the stock player1-4/home LED classdev-name fix, a separable hunk of the same origin diff as 0035's registration fix). Added above as `carried_patches` so reduce.py's orphan-carried-patch invariant (which previously read only the single `carried_patch` field) stops flagging 0041 as unmapped; `carried_patch` stays 0035, the schema's canonical single-value field. | RETIRED 2026-09-12: 0041-hid-nintendo-stock-led-classdev-names.patch was deleted from board/mister/de10nano/linux-patches/ (and the beta/DE25 symlinks). Offered upstream as Linux-Kernel_MiSTer PR #97; the maintainer closed it in favour of the userspace fix, Main_MiSTer #1308 (in Release 20260912), so the kernel keeps mainline's name and nothing carries it. Dropped from carried_patches so reduce.py's mapping stays truthful; 0035 is unaffected and stays carried.", "provenance_doc_ref": "patch-provenance.md:334", "removed": 2, "sha": "60821059c0d3b28b26729fdbe2719e7b4186aaba", "subject": "hid-nintendo: don't fail if home led is not present.", "subsystem": "hid", "upstream": {"equivalence": "partial", "vanilla_file_line": "drivers/hid/hid-nintendo.c:2310-2323", "vanilla_quote": "SET path (2310-2317, non-fatal \u2014 equivalent to fork intent):\n\t\t/* Set the home LED to 0 as default state */\n\t\tmutex_lock(&ctlr->output_mutex);\n\t\tret = joycon_set_home_led(ctlr, 0);\n\t\tmutex_unlock(&ctlr->output_mutex);\n\t\tif (ret) {\n\t\t\thid_warn(hdev, \"Failed to set home LED, skipping registration; ret=%d\\n\", ret);\n\t\t\treturn 0;\n\t\t}\n\nREGISTER path (2319-2323, still FATAL \u2014 never fixed upstream, contradicts fork):\n\t\tret = devm_led_classdev_register(&hdev->dev, led);\n\t\tif (ret) {\n\t\t\thid_err(hdev, \"Failed to register home LED; ret=%d\\n\", ret);\n\t\t\treturn ret;\n\t\t}", "vanilla_shas": ["2af16c1f846bd60240745bbd3afa13d5f040c61a", "8b30fb40f8f2c5e56b7af553a398340f92d17aae", "928276075f169d36f34e751ea5c81dd24d3a6823"]}, "userspace_coupling": {"coupled": true, "interface": "/sys/class/leds/:blue:player5/brightness (the \":home\" LED classdev created by joycon_leds_create())", "main_mister_ref": "Main_MiSTer/input.cpp:2761 \u2014 set_led(led_path, \":home\", num ? 1 : 15) inside the `input[dev].vid == 0x057e && ((input[dev].pid & 0xFF00) == 0x2000)` branch (input.cpp:2752). If the whole controller fails to probe (the residual registration-failure gap), this write silently no-ops (fopen() returns NULL, set_led() returns 0 at input.cpp:2665-2673) with no user-visible error from Main_MiSTer itself \u2014 the failure signal only exists in dmesg via hid_err()."}, "verification": {"confidence": "high", "contradiction": true, "method": "diff"}} {"added": 52, "agrees_with_provenance_doc": false, "author": "Sorgelig", "author_is_pr_contributor": false, "carried_mode": "re-implemented", "carried_patch": "0037-hid-playstation-dualsense-mute-btn-z.patch", "change_type": "in-tree-code", "date": "2021-07-10", "dependencies": {"depends_on": [], "duplicate_of": [], "superseded_by": []}, "disposition": "carried", "files": ["drivers/hid/hid-playstation.c"], "forward_port": {"applies_to_6_18": false, "conflicts": true, "effort": "medium"}, "impact": {"affected_hardware": ["Sony DualSense (PS5 controller)"], "device_ids": ["054C:0CE6", "054C:0DF2"], "effect_if_absent": "No functional change for any current MiSTer user (see userspace_coupling \u2014 no shipped consumer exists either way). At the kernel-capability level: the DualSense mute button no longer surfaces as a distinguishable BTN_Z evdev event (it becomes fully invisible to userspace, same as vanilla), and the mute LED is no longer exposed as a writable /sys/class/leds/*:mute node. Both remain latent/opt-in capabilities that nothing in Main_MiSTer currently reads or writes.", "failure_mode": "silent", "severity": "cosmetic"}, "is_backport_of_vanilla": false, "license_provenance": null, "notes": "MISCLASSIFIED in patch-provenance.md:337 (verbatim): '| `f84543926`, `0d60c3482`, `60e08955f`, `b76b4bc6a` | DualSense player LEDs / lightbar / mute / player-6 | **`8c0ab553b072`** *HID: playstation: expose DualSense player LEDs through LED class* (2021-09-08); **`8e5198a12d64`** *...add initial DualSense lightbar support* (2021-02-16) | 6.18 `hid-playstation.c:217` `update_player_leds`, `:155` lightbar flag. MiSTer's were pre-upstream backports. verify controller LED behaviour on HW (P3.13)'. Both cited vanilla SHAs verified to exist in /mnt/source/linux and are ancestors of v6.18.38 (`git merge-base --is-ancestor v6.18.38` => true for both). Their content was independently confirmed by reading each diff: 8c0ab553b072 (85 lines, hid-playstation.c) adds per-player LED class devices ('inputX:white:player-N'); 8e5198a12d64 (65 lines) adds lightbar support with a default PS-blue color. `git show | grep -i mute` on both returns nothing except an unrelated comment ('Reset the LEDs (lightbar, mute, player leds)...') in 8e5198a12d64 -- neither commit implements any mic-mute-to-userspace or mute-LED functionality. So the doc's grouping is a genuine mismatch: it cites two real, real-and-upstream commits for player-LEDs/lightbar (which DO cover f84543926/0d60c3482/b76b4bc6a) but folds in 60e08955f (mute) under the same citation even though neither cited SHA touches mute. Vanilla 6.18.38 still contains the OLD kernel-managed mute approach verbatim at hid-playstation.c:1496-1506 (line numbers reconfirmed exact against the live file, byte-for-byte match with the record's quote) -- last_btn_mic_state toggling ds->mic_muted internally and writing it back to the controller's own hardware mute LED via the output report's mute_button_led field (hid-playstation.c:1404-1405), never exposed to userspace. The MiSTer commit deletes last_btn_mic_state and the internal-toggle block, adds BTN_Z to ps_gamepad_buttons[] and reports it via input_report_key (confirmed in `git show` diff), and adds a new writable led_classdev named '%s:mute' via ds_muteled_create()/devm_led_classdev_register() with brightness_set_blocking=dualsense_muteled_brightness_set -- both quotes reconfirmed directly from `git show 60e08955f` in this pass. This is not carried in current Buildroot (only 0022-hid-playstation-ds4-mac-fix.patch touches hid-playstation.c, and it is a completely unrelated DS4-clone MAC-probe fix, confirmed by reading the patch's provenance header and diff -- no mute/BTN_Z content). SILENT REGRESSION (still true): whether carried or not, dropping/never-porting this produces no build/boot error, it just silently doesn't exist. CORRECTIONS MADE THIS PASS (Sonnet escalation verifier): (1) device_ids were WRONG in the prior pass -- '054C:05C5' (not a real ID) and '054C:09CC' (USB_DEVICE_ID_SONY_PS4_CONTROLLER_2, i.e. DualShock 4, NOT DualSense) were cited; the actual DualSense IDs per hid-ids.h are USB_DEVICE_ID_SONY_PS5_CONTROLLER=0x0ce6 and PS5_CONTROLLER_2=0x0df2 (054C:0CE6 / 054C:0DF2), confirmed against both hid-ids.h and the ps_devices match table (hid-playstation.c:2907-2915). Fixed. (2) userspace_coupling.coupled was asserted true with main_mister_ref=null (i.e. unevidenced) in the prior pass. This pass did an exhaustive grep of Main_MiSTer for BTN_Z, mute-related identifiers, DualSense PIDs, and LED-sysfs writes and found ZERO dedicated consumer of either BTN_Z-as-mute or the mute LED classdev -- corrected to coupled=false, with the generic (non-mute-specific) evdev button-sweep mechanism documented as a caveat in main_mister_ref. Severity downgraded from 'feature-loss' to 'cosmetic' accordingly: as of today, carrying or dropping this commit produces literally no observable behavior difference for any MiSTer user, since nothing consumes either interface it exposes. This remains a legitimate carry-decision item for the auditor (it's real kernel-level capability the fork deliberately added and the community may want restored/finished with an actual userspace consumer some day), but the framing is 'fork feature with no shipped consumer' rather than 'silently dropped working feature.' The core misclassification thesis (doc groups a mute-architecture commit under two upstream SHAs that only cover player-LEDs/lightbar) is CONFIRMED and now airtight with direct quotes/line numbers on both sides plus verified vanilla-SHA ancestry. sonnet-verified: corrected \u2014 misclassification confirmed and now fully grounded with quotes on both sides and verified vanilla-SHA ancestry; device_ids were wrong (DS4 IDs, not DualSense) and userspace_coupling was asserted without evidence \u2014 both fixed after exhaustive Main_MiSTer grep found no dedicated consumer, severity downgraded feature-loss -> cosmetic accordingly. | RESOLVED (user carry decision 2026-07-15): carried as 0037 for stock behavioral parity \u2014 mic-mute button reported as BTN_Z (extra OSD-mappable input), mute LED exposed as writable :mute classdev; in-kernel mic toggle removed. Forward-port declares BTN_Z per-device (6.18 shares ps_gamepad_buttons[] with DS4).", "provenance_doc_ref": "patch-provenance.md:337", "removed": 27, "sha": "60e08955fe23c2a1d57834f7dc31860395542e4a", "subject": "dualsense: give mute button and led to system.", "subsystem": "hid", "upstream": {"equivalence": "contradicted", "vanilla_file_line": "drivers/hid/hid-playstation.c:1496-1506", "vanilla_quote": "btn_mic_state = !!(ds_report->buttons[2] & DS_BUTTONS2_MIC_MUTE);\nif (btn_mic_state && !ds->last_btn_mic_state) {\n\tscoped_guard(spinlock_irqsave, &ps_dev->lock) {\n\t\tds->update_mic_mute = true;\n\t\tds->mic_muted = !ds->mic_muted; /* toggle */\n\t}\n\n\t/* Schedule updating of microphone state at hardware level. */\n\tdualsense_schedule_work(ds);\n}\nds->last_btn_mic_state = btn_mic_state;", "vanilla_shas": []}, "userspace_coupling": {"coupled": false, "interface": "BTN_Z evdev key event (gamepad range) + led_classdev sysfs node named \":mute\"; NEITHER has a dedicated Main_MiSTer consumer", "main_mister_ref": "Exhaustively grepped /mnt/source/Main_MiSTer for BTN_Z, mute, 0ce6/0df2 (DualSense PIDs), and led sysfs writes. The only BTN_Z hit repo-wide is input.cpp:5867 `case KEY_RECORD: ev.code = BTN_Z; break;` inside a block gated on `input[dev].vid == 0x45E` (Microsoft/Xbox X-Input devices, input.cpp:5861) -- unrelated to Sony/DualSense; it remaps an Xbox-pad keyboard-mode key INTO the generic BTN_Z slot, it does not consume BTN_Z coming FROM a DualSense. The only LED sysfs writer is update_num_hw() (input.cpp:2692-2770), which hardcodes writes to \":player_id\"/\":blue\"/\":green\"/\":red\" (DS4/DualSense lightbar+player-LED, quirk==QUIRK_DS4), \"::sonyN\" (DS3), \":playerN\"/\":home\" (Switch) -- there is no \":mute\" reference anywhere in the tree, and no generic LED-enumeration mechanism exists (LED writes are all hardcoded per-VID/PID paths). No default .map/.cfg/.json ships any 'mute' binding either (grep -rli mute --include=*.map --include=*.cfg --include=*.json => empty). CAVEAT: Main_MiSTer's joystick input DOES have a fully generic evdev button-capability sweep -- gamecontroller_db.cpp:207-217 `for (i = BTN_JOYSTICK; i < KEY_MAX; i++) if (test_bit(i, keybits)) btn_map[btn_cnt++] = i;`, used by input.cpp:6740-6789 get_button_name_for_code() for the OSD's 'define joystick buttons' screen. If the kernel driver advertised BTN_Z (i.e. if this commit were forward-ported), a user could manually bind the DualSense mute button to any core function via that generic OSD remap UI, exactly as any other 'extra' pad button is handled (this same BTN_Z slot is independently reused by fork patches for GameCube-adapter, Flydigi Vader and Xbox-360 'Z' buttons -- 0013/0014/0017 patches -- confirming it's a shared generic slot, not mute-specific). That is generic infrastructure noticing an unclaimed button, not a dedicated mute consumer -- it does not change the coupled=false verdict for THIS commit's specific (mute) semantics."}, "verification": {"confidence": "high", "contradiction": true, "method": "source-grep"}} {"added": 2, "agrees_with_provenance_doc": true, "author": "Stanislav Ponomarev", "author_is_pr_contributor": true, "carried_mode": "clean-apply", "carried_patch": "0047-btusb-mercusys-ma530-2c4e-0115.patch", "change_type": "in-tree-code", "date": "2026-08-24", "dependencies": {"depends_on": [], "duplicate_of": ["ce21a5cf3d1fd92b84ea9ad2b7c7240aff2162d2 (mainline, 2026-04-22, 'Bluetooth: btusb: Add Mercusys MA530 for Realtek RTL8761BUV') -- the fork commit is an independent re-landing of the identical two lines"], "superseded_by": []}, "disposition": "carried", "files": ["drivers/bluetooth/btusb.c"], "forward_port": {"applies_to_6_18": true, "conflicts": null, "effort": "trivial -- two lines, applied verbatim. Not forward-ported from the fork at all: the mainline commit's own hunk applies unmodified to 6.18.y, so the carried patch is a straight backport with zero edits."}, "impact": {"affected_hardware": ["Mercusys MA550H USB Bluetooth 5 adapter (Realtek RTL8761BUV)", "Mercusys MA530 USB Bluetooth 5 adapter (Realtek RTL8761BUV)"], "device_ids": ["2c4e:0115"], "effect_if_absent": "A Mercusys MA530 or MA550H Bluetooth adapter (USB 2c4e:0115, Realtek RTL8761BUV) binds no driver at all: btusb's quirks_table has no matching entry, so the device never reaches btrtl, never loads rtl_bt/rtl8761bu_fw.bin, and no hci0 appears. Every Bluetooth feature on the box -- pad pairing, DS3/SIXAXIS, BT audio -- is simply absent for a user who owns that dongle and no other. Nothing logs an error; the device just does not enumerate as a controller.", "failure_mode": "silent", "severity": "feature-loss"}, "is_backport_of_vanilla": true, "license_provenance": "GPL-2.0. Two lines of a mainline device-ID table, carried verbatim from torvalds/linux ce21a5cf3d1f with authorship preserved (Hrvoje Nuic).", "notes": "THE FIRST 'carried' ROW THAT IS NOT FORK CODE. Every other carried patch in board/mister/de10nano/linux-patches/ exists because mainline does not have the change. This one is the opposite: mainline DOES have it, and we carry it anyway because the 6.18.y stable line we pin never received it. The disposition is therefore 'carried', not 'dropped-upstream' -- 'dropped-upstream' asserts the functionality is present in the kernel we build, and here it demonstrably is not.\n\nWHY THE FORK COMMIT AND OUR PATCH ARE NOT THE SAME FILE. scripts/check-fork-sync.sh flagged 6332499e7 (Stanislav Ponomarev, MiSTer-v6.18, 2026-08-24). Its two added lines are byte-identical to mainline ce21a5cf3d1f (Hrvoje Nuic, authored 2026-04-22, committed 2026-06-11 by Luiz Augusto von Dentz via bluetooth-next -> net-next merge 9bbdc7dc4090). Two people landed the same table row independently. The patch we carry names the MAINLINE commit as its origin and preserves Hrvoje Nuic's authorship, because that is where the code and the attribution come from; this record is keyed on the fork SHA because that is what the sync check raised. dependencies.duplicate_of records the relationship.\n\nRELEASE ARITHMETIC, CHECKED BY TAG RATHER THAN INFERRED. The ID is absent from v7.0 and v7.1 and present in v7.2-rc1 and v7.2 final, so v7.2 is its first release. It is absent from the pinned v6.18.45 (and from v6.18.44 and v6.18.38, the other two 6.18.y trees this repo touches). The commit carries no 'Cc: stable', so no 6.18.y point release will bring it in -- which is exactly why carrying it is not redundant with the stable-bump treadmill.\n\nTHE RT VARIANT MUST NOT HAVE IT, AND THAT IS MEASURED. configs/mister_rt.fragment pins 7.2, which already carries the ID, so 0047 is the one shared patch deliberately absent from board/mister/de10nano/linux-patches-beta/series. This is not a tidiness choice: at -F0 (Buildroot's fuzz setting) against a pristine v7.2 btusb.c the hunk reports 'Hunk #1 FAILED at 786' -- listing it would break `make rt` at patch time rather than apply harmlessly twice.\n\nAPPLY EVIDENCE. Dry-run at -F0 against pristine btusb.c from v6.18.45 (offset 0), v6.18.44 (offset 0) and v6.18.38 (offset -2, the base scripts/export-kernel-tree.sh replays onto). Offsets are permitted at -F0; fuzz is not, and none was taken. scripts/lint-kernel-patches.sh passes on the patch (git-am-able, identity parses).\n\nNOTHING ELSE WAS MISSING. The device needs firmware and a setup path as well as a table row, and both were already in place before this change: rtl_bt/rtl8761bu_fw.bin and rtl8761bu_config.bin ship via BR2_PACKAGE_LINUX_FIRMWARE_RTL_87XX_BT (present in output/target/lib/firmware/rtl_bt/), and the resolved kernel config has CONFIG_BT_HCIBTUSB=m, CONFIG_BT_RTL=m, CONFIG_BT_HCIBTUSB_RTL=y. The two-line table entry was the only gap.\n\nNOT HARDWARE-TESTED HERE. Neither adapter is on hand. The fork's contributor reports a tested MA550H and the mainline author a tested MA530. The failure mode if that testimony were wrong is a dongle that still does not bind -- a device-ID row cannot regress hardware that does not match it.\n\norchestrator-verified (Opus 5, 2026-08-24): every claim in this record re-derived a second time from git.kernel.org (stable/linux.git v6.18.45 plain btusb.c: 0 matches; torvalds/linux.git v7.2: 1 match; torvalds/linux.git patch/?id=ce21a5cf3d1f: commit present, author Hrvoje Nuic, date 2026-04-22) rather than from the GitHub mirror the first pass used. Independent source, same answer.", "provenance_doc_ref": "none -- this commit postdates docs/patch-provenance.md's baseline (f0fb626ac) by five years. Dispositioned here first; docs/patch-provenance.md section 11 carries the summary row.", "removed": 0, "sha": "6332499e7545499dc361d09af7b44b33f494fe5d", "source_branch": "MiSTer-v6.18", "subject": "Bluetooth: btusb: add Mercusys 2c4e:0115 support (#78)", "subsystem": "bluetooth", "upstream": {"equivalence": "exact", "vanilla_file_line": "drivers/bluetooth/btusb.c:830 (v7.2; the quoted comment line is 829) -- and NOT in v6.18.45, the version configs/mister_de10nano_defconfig pins", "vanilla_quote": "\t/* Additional Realtek 8761BUV Bluetooth devices */\n\t{ USB_DEVICE(0x2c4e, 0x0115), .driver_info = BTUSB_REALTEK |\n\t\t\t\t\t\t BTUSB_WIDEBAND_SPEECH },", "vanilla_shas": ["ce21a5cf3d1fd92b84ea9ad2b7c7240aff2162d2"]}, "userspace_coupling": {"coupled": false, "interface": null, "main_mister_ref": null}, "verification": {"confidence": "high", "contradiction": false, "method": "diff"}} {"added": 4, "agrees_with_provenance_doc": true, "author": "antoniovillena", "author_is_pr_contributor": false, "carried_mode": "re-implemented", "carried_patch": "0004-dts-de10nano-MiSTer.patch", "change_type": "dts", "date": "2020-10-12", "dependencies": {"depends_on": [], "duplicate_of": [], "superseded_by": []}, "disposition": "carried", "files": ["arch/arm/boot/dts/socfpga_cyclone5_de10_nano.dts"], "forward_port": {"applies_to_6_18": true, "conflicts": null, "effort": "low"}, "impact": {"affected_hardware": ["DE10-Nano with optional RTC add-on board populated with PCF8563 chip"], "device_ids": ["NXP:PCF8563"], "effect_if_absent": "RTC device (PCF8563 at I2C address 0x51) will not be registered; /dev/rtcN will not appear for this device", "failure_mode": "silent", "severity": "feature-loss"}, "is_backport_of_vanilla": false, "license_provenance": null, "notes": "ESCALATION REQUIRED: The provenance doc entry groups this commit with 12 others (aa8afe109, e40563ae1, 2548c2978, 6c2d53934, 246984fce, 1337de1fd, c4d12c768, 7d2df2d2d, c5066763c, 071d9092e, f52690120, 077c2c317) under a single row, violating the single-commit-per-analysis principle. The commit adds a device tree node for a PCF8563 RTC at I2C address 0x51 on the i2c_gpio bit-banged bus. Vanilla 6.18.38's socfpga_cyclone5_de10nano.dts (added in 144616a80889, v6.14) is minimal and contains no RTC nodes. The kernel has full PCF8563 driver support (drivers/rtc/rtc-pcf8563.c, compatible = 'nxp,pcf8563'). The original commit used compatible = 'pcf8563' (without vendor prefix), but the carried patch 0004 corrects this to 'nxp,pcf8563', which is required by the vanilla driver. The DTS node addition is specific to the MiSTer board's optional add-on hardware and represents a carry candidate. No userspace coupling in Main_MiSTer; the RTC is used for FPGA cores, not Linux system time. The failure mode is silent\u2014without the DTS node, the device simply won't be registered, producing no error.\n\nsonnet-verified: carry-mapping CONFIRMED. Re-read the original fork commit diff (`git show 6827e764`) and confirmed it adds exactly `rtc_at_51 { compatible = \"pcf8563\"; reg = <0x51>; };` to the (by-then-already-i2c-gpio) bus alongside the pre-existing m41t81/mcp7941x nodes, matching the record's description. Confirmed 0004's rtc@51 node (patch lines 170-173) uses compatible=\"nxp,pcf8563\", and cross-checked against the live vanilla driver: drivers/rtc/rtc-pcf8563.c:569 has of_device_id.compatible=\"nxp,pcf8563\" in pcf8563_of_match[], confirming the vendor-prefix correction claim. No corrections needed.", "provenance_doc_ref": "docs/patch-provenance.md row grouping commits aa8afe109 through 077c2c317", "removed": 0, "sha": "6827e764473c224efb011bfdd383b6ea213b6acc", "subject": "Support for RTC PCF8563", "subsystem": "dts", "upstream": {"equivalence": "partial", "vanilla_file_line": null, "vanilla_quote": null, "vanilla_shas": []}, "userspace_coupling": {"coupled": false, "interface": null, "main_mister_ref": null}, "verification": {"confidence": "high", "contradiction": false, "method": "diff"}} diff --git a/docs/kernel-recon/reconciliation.md b/docs/kernel-recon/reconciliation.md index e3b8e14e..345e75a0 100644 --- a/docs/kernel-recon/reconciliation.md +++ b/docs/kernel-recon/reconciliation.md @@ -1,6 +1,6 @@ # Reconciliation — one row per fork commit -Generated 2026-09-11 03:37 UTC by `reduce.py` from 136 records (110 MiSTer-v5.15 + 10 MiSTer-v6.18 + 1 refs/pull/92/head + 15 old-branch residue). Tier-2 verified: 126/136. +Generated 2026-09-12 17:05 UTC by `reduce.py` from 136 records (110 MiSTer-v5.15 + 10 MiSTer-v6.18 + 1 refs/pull/92/head + 15 old-branch residue). Tier-2 verified: 126/136. ## How to read this table @@ -143,13 +143,13 @@ Of 136 rows, **3** describe a real difference a user could notice on this build | `333d49b95` | v5.15 | **carried** | 0002-sound-add-MiSTer-audio-spi-and-snd-dummy-MiSTer-model.patch | — | none (carried) | feature-loss/silent | Y | Y | ✓ | Implement MiSTer audio driver. | | `3d72b9db7` | v5.15 | **carried** | 0003-cpufreq-cyclone5-de10nano-overclock.patch | — | none (carried) | feature-loss/silent | — | Y | ✓ | Add cpufreq/overclock driver (#34) | | `41c45f378` | v6.18 | **carried** | 0048-hid-google-stadiaff-classic2usb-retrozord.patch | — | none (carried) | feature-loss/silent | Y | ? | | Adapt Classic2USB and RetroZord HID force feedback support … | -| `45283785a` | v5.15 | **carried** | 0032-hid-nintendo-joycon-combo-led.patch, 0040-hid-nintendo-imu-name-suffix.patch | — | none (carried) | feature-loss/silent | Y | N | ✓ | hid-nintendo: add virtual combo led, don't warn by IMU comp… | +| `45283785a` | v5.15 | **carried** | 0032-hid-nintendo-joycon-combo-led.patch | — | none (carried) | feature-loss/silent | Y | N | ✓ | hid-nintendo: add virtual combo led, don't warn by IMU comp… | | `47dc53a22` | v5.15 | **carried** | 0023-hid-wiimote-fixes.patch | — | none (carried) | feature-loss/silent | Y | Y | ✓ | wiimote: fix the buttons codes. | | `484f68172` | v5.15 | **carried** | 0015-hid-nintendo-nso-famicom.patch | — | none (carried) | feature-loss/silent | — | Y | ✓ | input: Add support for the NSO Famicom controllers (no mic … | | `52a56ae3d` | v5.15 | **carried** | 0026-input-mousedev-eviocgrab.patch | — | none (carried) | feature-loss/silent | Y | Y | ✓ | mousedev: disable touch to click on DualShock4 and DualSens… | | `5bdbf2f7e` | v5.15 | **carried** | 0018-hid-controllable-quirk.patch | — | none (carried) | feature-loss/silent | Y | Y | ✓ | hid: add quirk for ControllaBLE. | | `5c410e935` | v5.15 | **carried** | 0022-hid-playstation-ds4-mac-fix.patch | — | none (carried) | feature-loss/loud | — | Y | ✓ | hid-sony: fix for 3rd party DS4 failing to connect by wire. | -| `60821059c` | v5.15 | **carried** | 0035-hid-nintendo-home-led-nonfatal.patch, 0041-hid-nintendo-stock-led-classdev-names.patch | — | none (carried) | feature-loss/loud | Y | N | ✓ | hid-nintendo: don't fail if home led is not present. | +| `60821059c` | v5.15 | **carried** | 0035-hid-nintendo-home-led-nonfatal.patch | — | none (carried) | feature-loss/loud | Y | N | ✓ | hid-nintendo: don't fail if home led is not present. | | `60e08955f` | v5.15 | **carried** | 0037-hid-playstation-dualsense-mute-btn-z.patch | — | none (carried) | cosmetic/silent | — | N | ✓ | dualsense: give mute button and led to system. | | `6332499e7` | v6.18 | **carried** | 0047-btusb-mercusys-ma530-2c4e-0115.patch | — | none (carried) | feature-loss/silent | — | Y | ✓ | Bluetooth: btusb: add Mercusys 2c4e:0115 support (#78) | | `6827e7644` | v5.15 | **carried** | 0004-dts-de10nano-MiSTer.patch | — | none (carried) | feature-loss/silent | — | Y | ✓ | Support for RTC PCF8563 | diff --git a/docs/kernel-recon/records/45283785a7ace3263f7c165ae6a4ec3055ebdcf6.json b/docs/kernel-recon/records/45283785a7ace3263f7c165ae6a4ec3055ebdcf6.json index 57cd376a..030ec6e3 100644 --- a/docs/kernel-recon/records/45283785a7ace3263f7c165ae6a4ec3055ebdcf6.json +++ b/docs/kernel-recon/records/45283785a7ace3263f7c165ae6a4ec3055ebdcf6.json @@ -15,8 +15,7 @@ "disposition": "carried", "carried_patch": "0032-hid-nintendo-joycon-combo-led.patch", "carried_patches": [ - "0032-hid-nintendo-joycon-combo-led.patch", - "0040-hid-nintendo-imu-name-suffix.patch" + "0032-hid-nintendo-joycon-combo-led.patch" ], "carried_mode": "re-implemented", "upstream": { @@ -33,7 +32,7 @@ "agrees_with_provenance_doc": false, "provenance_doc_ref": "patch-provenance.md:334", "impact": { - "effect_if_absent": "Joy-Con L+R combining is completely non-functional (not merely 'auto-detect disabled with manual fallback'). Individual Joy-Cons still work as separate single-stick controllers, but there is no way \u2014 automatic or manual \u2014 to pair two Joy-Cons into one virtual controller, because Main_MiSTer's ENTIRE pairing handshake (both the write side triggered by a button-combo request, and the read side that recognizes the pair on device rescan) is implemented purely as a read/write of the kernel-side ':combo' LED sysfs node. No alternative/manual pairing UI exists anywhere in Main_MiSTer (grep of menu.cpp/osd.cpp for 'joycon'/'joy-con' returns zero hits; input.cpp sets input[].bind for QUIRK_JOYCON devices at exactly one place, input.cpp:4729-4730, and that code path is unreachable without a valid combo-id readback).", + "effect_if_absent": "Joy-Con L+R combining is completely non-functional (not merely 'auto-detect disabled with manual fallback'). Individual Joy-Cons still work as separate single-stick controllers, but there is no way — automatic or manual — to pair two Joy-Cons into one virtual controller, because Main_MiSTer's ENTIRE pairing handshake (both the write side triggered by a button-combo request, and the read side that recognizes the pair on device rescan) is implemented purely as a read/write of the kernel-side ':combo' LED sysfs node. No alternative/manual pairing UI exists anywhere in Main_MiSTer (grep of menu.cpp/osd.cpp for 'joycon'/'joy-con' returns zero hits; input.cpp sets input[].bind for QUIRK_JOYCON devices at exactly one place, input.cpp:4729-4730, and that code path is unreachable without a valid combo-id readback).", "affected_hardware": [ "Nintendo Joy-Con (L)", "Nintendo Joy-Con (R)" @@ -48,7 +47,7 @@ "userspace_coupling": { "coupled": true, "interface": "/sys/.../leds/:combo/brightness (LED classdev registered by joycon_leds_create() in the fork commit; name format '%s:combo' with %s = dev_name(&hdev->dev), e.g. '0005:057E:2006.0001:combo')", - "main_mister_ref": "input.cpp:2661-2674 set_led() and input.cpp:2676-2690 get_led() both fopen() the LED's 'brightness' sysfs file and silently return 0/no-op if it does not exist (no error logged) \u2014 this is the mechanism by which absence degrades silently. input.cpp:4689-4738 check_joycon() reads ':combo' via get_led() at lines 4704 and 4715 to recognize a matched Joy-Con pair on device rescan and, only if a nonzero shared id is read back, sets the actual pairing at input.cpp:4729-4730 (input[l].bind = r; input[r].bind = l). input.cpp:4785-4823 process_joycon() is the OTHER half of the handshake: on a specific 3-button hold (JOYCON_REQ, misc_flags&7==7) on both an unbound left and right Joy-Con, it writes a freshly-generated id to both controllers' ':combo' LED via set_led() at lines 4822-4823, then force-closes all input fds to trigger the rescan that re-invokes check_joycon(). Without the kernel-side combo LED classdev, the write at 4822-4823 is a silent no-op and the read at 4704/4715 always returns 0, so id_combo never matches and input[l]/input[r].bind is never set \u2014 pairing silently never completes, with no error surfaced to the user." + "main_mister_ref": "input.cpp:2661-2674 set_led() and input.cpp:2676-2690 get_led() both fopen() the LED's 'brightness' sysfs file and silently return 0/no-op if it does not exist (no error logged) — this is the mechanism by which absence degrades silently. input.cpp:4689-4738 check_joycon() reads ':combo' via get_led() at lines 4704 and 4715 to recognize a matched Joy-Con pair on device rescan and, only if a nonzero shared id is read back, sets the actual pairing at input.cpp:4729-4730 (input[l].bind = r; input[r].bind = l). input.cpp:4785-4823 process_joycon() is the OTHER half of the handshake: on a specific 3-button hold (JOYCON_REQ, misc_flags&7==7) on both an unbound left and right Joy-Con, it writes a freshly-generated id to both controllers' ':combo' LED via set_led() at lines 4822-4823, then force-closes all input fds to trigger the rescan that re-invokes check_joycon(). Without the kernel-side combo LED classdev, the write at 4822-4823 is a silent no-op and the read at 4704/4715 always returns 0, so id_combo never matches and input[l]/input[r].bind is never set — pairing silently never completes, with no error surfaced to the user." }, "forward_port": { "applies_to_6_18": false, @@ -63,6 +62,6 @@ ] }, "license_provenance": null, - "notes": "MISCLASSIFIED. patch-provenance.md:334 GROUPS four commits (`c4ec5cb40`, `9bdab534b`, `60821059c`, `45283785a`) into one Class-C 'drop \u2014 now upstream' row citing a single upstream SHA, `2af16c1f846b` ('HID: nintendo: add nintendo switch controller driver', 2021-09-11, v5.16), as the citation for all four. That upstream commit only introduced the BASE hid-nintendo driver (matches c4ec5cb40 and neighbors); it predates 45283785a by about a month in the fork's own history and never touched LED code beyond the stock player/home LEDs. Re-derived independently: `git log -S'combo' -- drivers/hid/hid-nintendo.c` and `git log -S'combo_led' -- drivers/hid/hid-nintendo.c` in /mnt/source/linux (HEAD confirmed at tag v6.18.38, commit e46dc0adfe39) both return ZERO commits across the entire vanilla history of the file \u2014 the string 'combo' has never appeared in mainline hid-nintendo.c. `grep -n combo /mnt/source/linux/drivers/hid/hid-nintendo.c` also returns nothing. Vanilla's joycon_leds_create() (hid-nintendo.c:2235-2327) registers exactly the player LEDs and the home LED, then returns \u2014 quoted above. This is a fabricated, MiSTer-specific extension with no upstream counterpart and no submission path (it depends on a MiSTer-only Main_MiSTer-side pairing protocol, not something Nintendo/Linux HID maintainers would take). Per the grounding contract, equivalence=contradicted + provenance doc claims upstream coverage in a grouped row => disposition=misclassified (not dropped-upstream, and not merely needs-verification since the contradiction is now fully proven with quotes). CORRECTION TO PRIOR DRAFT OF THIS RECORD: the previous pass's impact/notes claimed 'users lose automatic pairing but can manually configure' \u2014 this is WRONG. Traced set_led()/get_led()/check_joycon()/process_joycon() in full: there is no manual fallback. The button-combo-triggered pairing REQUEST (process_joycon, input.cpp:4785-4823) and the pairing RECOGNITION (check_joycon, input.cpp:4689-4738) communicate ONLY via the ':combo' sysfs LED value \u2014 one process writes it, the other reads it back after a forced device-rescan. Without the kernel classdev both operations are silent no-ops (fopen fails, functions return 0/false, nothing is logged), so input[].bind is never set for any Joy-Con pair, under any user action. Grep of menu.cpp and osd.cpp for 'joycon'/'joy-con' confirms there is no alternate UI. Net effect: Joy-Con dual-controller combining is entirely and silently broken, not merely 'less convenient.' Individual Joy-Cons (VID 057e, PID 2006/2007 \u2014 confirmed against input.cpp:5331-5340) still function as independent single-stick controllers, so severity is feature-loss rather than boot-critical. Secondary, unrelated change in the same commit: IMU-dropped-packet log lines downgraded hid_warn -> hid_dbg (fork diff, both call sites). Vanilla 6.18.38 (hid-nintendo.c:1457-1464) instead uses hid_warn_ratelimited (introduced by b8874720b2f3 'HID: nintendo: Rate limit IMU compensation message', 2025-10-06, confirmed via `git log --oneline -S'hid_warn_ratelimited' -- drivers/hid/hid-nintendo.c` and `git show --stat b8874720b2f3`) \u2014 a different mechanism (rate-limit vs. debug-demote) that achieves a similar log-spam-reduction goal but is not the same code; this part is a plausible, lower-stakes carry candidate on its own merits but is NOT what the coupled-regression escalation claim is about and does not rescue the provenance doc's citation for the combo LED half of the commit. Not carried: grep of all 25 files in board/mister/de10nano/linux-patches/*.patch for 'combo' returns zero matches (0015-hid-nintendo-nso-famicom.patch and 0013-hid-flydigi-vader.patch matched only on unrelated 'nintendo'/'joycon' substrings). CONFIG_HID_NINTENDO=y is set in our linux.config (line 323) and drivers/hid/hid-nintendo.c is present and built in vanilla 6.18.38, so the driver itself is not missing \u2014 only the combo LED classdev inside it. sonnet-verified: CONFIRMED \u2014 every link in the original coupled-regression claim holds under independent re-derivation (fork diff quoted directly from `git show`, vanilla absence proven by both grep and full-history `git log -S`, Main_MiSTer read/write/bind chain traced end-to-end with line numbers, provenance doc grouped-row citation confirmed wrong for this specific commit). One correction made to the prior draft: there is NO manual-pairing fallback in Main_MiSTer \u2014 the regression is total loss of Joy-Con combining, not degraded convenience; effect_if_absent, userspace_coupling, and notes above were rewritten accordingly. disposition upgraded from needs-verification to misclassified now that the contradiction is fully evidenced with quotes per the grounding contract. | RESOLVED (user carry decision 2026-07-14/15 (see silent-regressions.md + git d2f2791 follow-ups)): carried as 0032 \u2014 combo LED registered on 6.18 hid-nintendo with non-fatal registration; IMU log downgrade included. Joy-Con combining restored. WAVE 3 LEDGER FIX (2026-09-11): docs/patch-provenance.md \u00a711's '0040-hid-nintendo-imu-name-suffix' row cites its origin as fork commit `a6b7e3666` -- that short SHA resolves to `a6b7e36668f60fee6d2cd8dd142db5237c3b3f1f` on MiSTer-v6.18, subject byte-identical to THIS record's commit (see dependencies.duplicate_of), i.e. it is the v6.18-branch re-port of this same v5.15 change, not a separate unrecorded commit -- so 0040's real origin record is this one. Added above as `carried_patches` so reduce.py's orphan-carried-patch invariant (single `carried_patch` field only, previously) stops flagging 0040 as unmapped; `carried_patch` stays 0032, the schema's canonical single-value field.", - "sonnet-verified": "confirmed \u2014 combo LED registration, vanilla absence, and full Main_MiSTer read/write/bind coupling all verified with direct quotes and line numbers; corrected the 'manual pairing fallback exists' claim in the prior draft (no such fallback exists) and upgraded disposition to misclassified per the grounding contract (contradicted + provenance doc claims upstream in a grouped row)." -} \ No newline at end of file + "notes": "MISCLASSIFIED. patch-provenance.md:334 GROUPS four commits (`c4ec5cb40`, `9bdab534b`, `60821059c`, `45283785a`) into one Class-C 'drop — now upstream' row citing a single upstream SHA, `2af16c1f846b` ('HID: nintendo: add nintendo switch controller driver', 2021-09-11, v5.16), as the citation for all four. That upstream commit only introduced the BASE hid-nintendo driver (matches c4ec5cb40 and neighbors); it predates 45283785a by about a month in the fork's own history and never touched LED code beyond the stock player/home LEDs. Re-derived independently: `git log -S'combo' -- drivers/hid/hid-nintendo.c` and `git log -S'combo_led' -- drivers/hid/hid-nintendo.c` in /mnt/source/linux (HEAD confirmed at tag v6.18.38, commit e46dc0adfe39) both return ZERO commits across the entire vanilla history of the file — the string 'combo' has never appeared in mainline hid-nintendo.c. `grep -n combo /mnt/source/linux/drivers/hid/hid-nintendo.c` also returns nothing. Vanilla's joycon_leds_create() (hid-nintendo.c:2235-2327) registers exactly the player LEDs and the home LED, then returns — quoted above. This is a fabricated, MiSTer-specific extension with no upstream counterpart and no submission path (it depends on a MiSTer-only Main_MiSTer-side pairing protocol, not something Nintendo/Linux HID maintainers would take). Per the grounding contract, equivalence=contradicted + provenance doc claims upstream coverage in a grouped row => disposition=misclassified (not dropped-upstream, and not merely needs-verification since the contradiction is now fully proven with quotes). CORRECTION TO PRIOR DRAFT OF THIS RECORD: the previous pass's impact/notes claimed 'users lose automatic pairing but can manually configure' — this is WRONG. Traced set_led()/get_led()/check_joycon()/process_joycon() in full: there is no manual fallback. The button-combo-triggered pairing REQUEST (process_joycon, input.cpp:4785-4823) and the pairing RECOGNITION (check_joycon, input.cpp:4689-4738) communicate ONLY via the ':combo' sysfs LED value — one process writes it, the other reads it back after a forced device-rescan. Without the kernel classdev both operations are silent no-ops (fopen fails, functions return 0/false, nothing is logged), so input[].bind is never set for any Joy-Con pair, under any user action. Grep of menu.cpp and osd.cpp for 'joycon'/'joy-con' confirms there is no alternate UI. Net effect: Joy-Con dual-controller combining is entirely and silently broken, not merely 'less convenient.' Individual Joy-Cons (VID 057e, PID 2006/2007 — confirmed against input.cpp:5331-5340) still function as independent single-stick controllers, so severity is feature-loss rather than boot-critical. Secondary, unrelated change in the same commit: IMU-dropped-packet log lines downgraded hid_warn -> hid_dbg (fork diff, both call sites). Vanilla 6.18.38 (hid-nintendo.c:1457-1464) instead uses hid_warn_ratelimited (introduced by b8874720b2f3 'HID: nintendo: Rate limit IMU compensation message', 2025-10-06, confirmed via `git log --oneline -S'hid_warn_ratelimited' -- drivers/hid/hid-nintendo.c` and `git show --stat b8874720b2f3`) — a different mechanism (rate-limit vs. debug-demote) that achieves a similar log-spam-reduction goal but is not the same code; this part is a plausible, lower-stakes carry candidate on its own merits but is NOT what the coupled-regression escalation claim is about and does not rescue the provenance doc's citation for the combo LED half of the commit. Not carried: grep of all 25 files in board/mister/de10nano/linux-patches/*.patch for 'combo' returns zero matches (0015-hid-nintendo-nso-famicom.patch and 0013-hid-flydigi-vader.patch matched only on unrelated 'nintendo'/'joycon' substrings). CONFIG_HID_NINTENDO=y is set in our linux.config (line 323) and drivers/hid/hid-nintendo.c is present and built in vanilla 6.18.38, so the driver itself is not missing — only the combo LED classdev inside it. sonnet-verified: CONFIRMED — every link in the original coupled-regression claim holds under independent re-derivation (fork diff quoted directly from `git show`, vanilla absence proven by both grep and full-history `git log -S`, Main_MiSTer read/write/bind chain traced end-to-end with line numbers, provenance doc grouped-row citation confirmed wrong for this specific commit). One correction made to the prior draft: there is NO manual-pairing fallback in Main_MiSTer — the regression is total loss of Joy-Con combining, not degraded convenience; effect_if_absent, userspace_coupling, and notes above were rewritten accordingly. disposition upgraded from needs-verification to misclassified now that the contradiction is fully evidenced with quotes per the grounding contract. | RESOLVED (user carry decision 2026-07-14/15 (see silent-regressions.md + git d2f2791 follow-ups)): carried as 0032 — combo LED registered on 6.18 hid-nintendo with non-fatal registration; IMU log downgrade included. Joy-Con combining restored. WAVE 3 LEDGER FIX (2026-09-11): docs/patch-provenance.md §11's '0040-hid-nintendo-imu-name-suffix' row cites its origin as fork commit `a6b7e3666` -- that short SHA resolves to `a6b7e36668f60fee6d2cd8dd142db5237c3b3f1f` on MiSTer-v6.18, subject byte-identical to THIS record's commit (see dependencies.duplicate_of), i.e. it is the v6.18-branch re-port of this same v5.15 change, not a separate unrecorded commit -- so 0040's real origin record is this one. Added above as `carried_patches` so reduce.py's orphan-carried-patch invariant (single `carried_patch` field only, previously) stops flagging 0040 as unmapped; `carried_patch` stays 0032, the schema's canonical single-value field. | RETIRED 2026-09-12: 0040-hid-nintendo-imu-name-suffix.patch was deleted from board/mister/de10nano/linux-patches/ (and the beta/DE25 symlinks). Offered upstream as Linux-Kernel_MiSTer PR #96; the maintainer closed it in favour of the userspace fix, Main_MiSTer #1307 (in Release 20260912), so the kernel keeps mainline's name and nothing carries it. Dropped from carried_patches so reduce.py's mapping stays truthful; 0032 is unaffected and stays carried.", + "sonnet-verified": "confirmed — combo LED registration, vanilla absence, and full Main_MiSTer read/write/bind coupling all verified with direct quotes and line numbers; corrected the 'manual pairing fallback exists' claim in the prior draft (no such fallback exists) and upgraded disposition to misclassified per the grounding contract (contradicted + provenance doc claims upstream in a grouped row)." +} diff --git a/docs/kernel-recon/records/60821059c0d3b28b26729fdbe2719e7b4186aaba.json b/docs/kernel-recon/records/60821059c0d3b28b26729fdbe2719e7b4186aaba.json index 781427c2..1a601aae 100644 --- a/docs/kernel-recon/records/60821059c0d3b28b26729fdbe2719e7b4186aaba.json +++ b/docs/kernel-recon/records/60821059c0d3b28b26729fdbe2719e7b4186aaba.json @@ -15,8 +15,7 @@ "disposition": "carried", "carried_patch": "0035-hid-nintendo-home-led-nonfatal.patch", "carried_patches": [ - "0035-hid-nintendo-home-led-nonfatal.patch", - "0041-hid-nintendo-stock-led-classdev-names.patch" + "0035-hid-nintendo-home-led-nonfatal.patch" ], "carried_mode": "re-implemented", "upstream": { @@ -26,7 +25,7 @@ "928276075f169d36f34e751ea5c81dd24d3a6823" ], "vanilla_file_line": "drivers/hid/hid-nintendo.c:2310-2323", - "vanilla_quote": "SET path (2310-2317, non-fatal \u2014 equivalent to fork intent):\n\t\t/* Set the home LED to 0 as default state */\n\t\tmutex_lock(&ctlr->output_mutex);\n\t\tret = joycon_set_home_led(ctlr, 0);\n\t\tmutex_unlock(&ctlr->output_mutex);\n\t\tif (ret) {\n\t\t\thid_warn(hdev, \"Failed to set home LED, skipping registration; ret=%d\\n\", ret);\n\t\t\treturn 0;\n\t\t}\n\nREGISTER path (2319-2323, still FATAL \u2014 never fixed upstream, contradicts fork):\n\t\tret = devm_led_classdev_register(&hdev->dev, led);\n\t\tif (ret) {\n\t\t\thid_err(hdev, \"Failed to register home LED; ret=%d\\n\", ret);\n\t\t\treturn ret;\n\t\t}", + "vanilla_quote": "SET path (2310-2317, non-fatal — equivalent to fork intent):\n\t\t/* Set the home LED to 0 as default state */\n\t\tmutex_lock(&ctlr->output_mutex);\n\t\tret = joycon_set_home_led(ctlr, 0);\n\t\tmutex_unlock(&ctlr->output_mutex);\n\t\tif (ret) {\n\t\t\thid_warn(hdev, \"Failed to set home LED, skipping registration; ret=%d\\n\", ret);\n\t\t\treturn 0;\n\t\t}\n\nREGISTER path (2319-2323, still FATAL — never fixed upstream, contradicts fork):\n\t\tret = devm_led_classdev_register(&hdev->dev, led);\n\t\tif (ret) {\n\t\t\thid_err(hdev, \"Failed to register home LED; ret=%d\\n\", ret);\n\t\t\treturn ret;\n\t\t}", "equivalence": "partial" }, "verification": { @@ -37,7 +36,7 @@ "agrees_with_provenance_doc": false, "provenance_doc_ref": "patch-provenance.md:334", "impact": { - "effect_if_absent": "If devm_led_classdev_register() itself fails for the home LED (kernel-side sysfs/allocation failure, e.g. -ENOMEM or name collision \u2014 NOT the same as the controller lacking home-LED hardware), joycon_leds_create() returns the error, nintendo_hid_probe() takes the err_close path, and the ENTIRE controller (all buttons/sticks, not just the LED) fails to bind \u2014 the device is unusable, not just missing a home LED. This only happens for controller types that reach the home-LED branch: Pro Controller and right Joy-Con (jc_type_has_right() gate at hid-nintendo.c:654-656 requires ctlr_type == JCR(0x02) or PRO(0x03)). Left Joy-Con, SNES/N64/Genesis NSO controllers have distinct ctlr_type values (JCL=0x01, SNES=0x0B, N64=0x0C, GEN=0x0D) and never enter this code path at all, so they cannot be affected by this specific commit regardless of vanilla vs fork. Separately, the 'clone controller doesn't support home LED at all' scenario (the SET failure at joycon_set_home_led(), lines 2310-2317) is already non-fatal in vanilla 6.18.38 via a different code path (skip registration, return 0) \u2014 no regression there.", + "effect_if_absent": "If devm_led_classdev_register() itself fails for the home LED (kernel-side sysfs/allocation failure, e.g. -ENOMEM or name collision — NOT the same as the controller lacking home-LED hardware), joycon_leds_create() returns the error, nintendo_hid_probe() takes the err_close path, and the ENTIRE controller (all buttons/sticks, not just the LED) fails to bind — the device is unusable, not just missing a home LED. This only happens for controller types that reach the home-LED branch: Pro Controller and right Joy-Con (jc_type_has_right() gate at hid-nintendo.c:654-656 requires ctlr_type == JCR(0x02) or PRO(0x03)). Left Joy-Con, SNES/N64/Genesis NSO controllers have distinct ctlr_type values (JCL=0x01, SNES=0x0B, N64=0x0C, GEN=0x0D) and never enter this code path at all, so they cannot be affected by this specific commit regardless of vanilla vs fork. Separately, the 'clone controller doesn't support home LED at all' scenario (the SET failure at joycon_set_home_led(), lines 2310-2317) is already non-fatal in vanilla 6.18.38 via a different code path (skip registration, return 0) — no regression there.", "affected_hardware": [ "Nintendo Pro Controller", "Nintendo Joy-Con (R)", @@ -54,7 +53,7 @@ "userspace_coupling": { "coupled": true, "interface": "/sys/class/leds/:blue:player5/brightness (the \":home\" LED classdev created by joycon_leds_create())", - "main_mister_ref": "Main_MiSTer/input.cpp:2761 \u2014 set_led(led_path, \":home\", num ? 1 : 15) inside the `input[dev].vid == 0x057e && ((input[dev].pid & 0xFF00) == 0x2000)` branch (input.cpp:2752). If the whole controller fails to probe (the residual registration-failure gap), this write silently no-ops (fopen() returns NULL, set_led() returns 0 at input.cpp:2665-2673) with no user-visible error from Main_MiSTer itself \u2014 the failure signal only exists in dmesg via hid_err()." + "main_mister_ref": "Main_MiSTer/input.cpp:2761 — set_led(led_path, \":home\", num ? 1 : 15) inside the `input[dev].vid == 0x057e && ((input[dev].pid & 0xFF00) == 0x2000)` branch (input.cpp:2752). If the whole controller fails to probe (the residual registration-failure gap), this write silently no-ops (fopen() returns NULL, set_led() returns 0 at input.cpp:2665-2673) with no user-visible error from Main_MiSTer itself — the failure signal only exists in dmesg via hid_err()." }, "forward_port": { "applies_to_6_18": true, @@ -67,5 +66,5 @@ "duplicate_of": [] }, "license_provenance": null, - "notes": "VERIFIED. Fork diff (drivers/hid/hid-nintendo.c, joycon_leds_create()) confirmed by `git show 60821059c`: both `return ret;` statements are commented out \u2014 (1) after `devm_led_classdev_register()` fails ('Failed registering home led'), (2) after `joycon_home_led_brightness_set()` fails ('Failed to set home LED dflt; ret=%d'). Both error paths become non-fatal in the fork.\n\nVanilla 6.18.38 history (all three SHAs confirmed via `git log`/`git show`/`git merge-base --is-ancestor` in /mnt/source/linux, checked out at tag v6.18.38):\n- `2af16c1f846b` (2021-09-11, Daniel J. Ogorchock) is simply the original upstream addition of hid-nintendo.c (869 lines, new file). It predates the fork's 2021-08-12 commit chronologically upstream (the fork's driver was an out-of-tree precursor) and, critically, is NOT specifically about home-LED error handling \u2014 at that point both the SET and REGISTER paths were still fully fatal upstream. Citing it as 'upstream coverage' for 60821059c's behavior (as patch-provenance.md:334's grouped row does) is not correct for this specific commit's effect.\n- `8b30fb40f8f2` (2022-04-15, Icenowy Zheng, 'HID: nintendo: deregister home LED when it fails') is the real fix for the 'clone controller doesn't support home LED' scenario described in its own commit message ('Some Pro Controller compatible controllers do not support home LED, and will fail when setting it. Currently this leads to probe failure.'). At the time, code order was register-then-set (matching the fork's pre-image exactly, including the literal string 'Failed to set home LED dflt; ret=%d'). The fix changed the post-registration SET failure from `hid_err(...); return ret;` to `hid_warn(...); devm_led_classdev_unregister(&hdev->dev, led);` (implicit `return 0`) \u2014 non-fatal. It did NOT touch the REGISTRATION failure, which remained `return ret;` (fatal) at that point in history.\n- `928276075f16` (2023-09-24, Martino Fontana, 'HID: nintendo: cleanup LED code') refactored the order to set-before-register: a new `joycon_set_home_led()` helper is called first, and only on success does `devm_led_classdev_register()` run. This is the current v6.18.38 shape (lines 2310-2323). SET failure is still non-fatal (skip registration, `return 0`) but implemented via a different mechanism than 8b30fb40f8f2's register+unregister approach. REGISTRATION failure is STILL untouched \u2014 `hid_err(...); return ret;` at 2319-2323 remains exactly as fatal as it was in 2021.\n\nConclusion: equivalence is PARTIAL, not fully contradicted and not fully equivalent. The SET-failure path (the actual 'clone controller lacks home LED hardware' scenario that motivated both the fork's patch and 8b30fb40f8f2's commit message) is equivalent/superseded-better upstream \u2014 dropping the fork's SET-path comment-out is safe. The REGISTRATION-failure path is a genuine, never-addressed gap: vanilla still hard-fails the ENTIRE controller probe (not just the LED) if devm_led_classdev_register() itself errors, while the fork tolerated it. This is a real carry candidate for that one residual line (hid-nintendo.c:2322 `return ret;`), though its real-world trigger probability is low \u2014 devm_led_classdev_register() failing is a kernel resource/sysfs issue (OOM, name collision), not a controller-hardware-capability issue; the hardware-capability case is already the SET path and is already fixed upstream. Only Pro Controller and right Joy-Con (including via Charging Grip) reach this code at all (jc_type_has_right() gate); left Joy-Con, SNES, N64, and Genesis NSO controllers have distinct ctlr_type values and never execute joycon_leds_create()'s home-LED branch, so the original record's affected_hardware/device_ids list (which included Joy-Con L, SNES, N64, Mega Drive) was overbroad and has been corrected here.\n\npatch-provenance.md:334 is a GROUPED ROW (c4ec5cb40, 9bdab534b, 60821059c, 45283785a all mapped to 2af16c1f846b, labeled Class C 'now upstream (drop)'). For this specific commit that classification is not fully accurate \u2014 hence disposition=misclassified rather than dropped-upstream, per the pilot-lesson rule (contradicted/partial-with-real-gap + provenance doc claimed upstream coverage \u21d2 misclassified). Not carried in our build: grepped board/mister/de10nano/linux-patches/ for home-LED/joycon_leds_create strings \u2014 only hit is 0015-hid-nintendo-nso-famicom.patch, which does not touch LED code at all (confirmed via grep, no 'home'/'led'/'LED' matches). So this behavior is neither carried-by-patch nor fully dropped-upstream; it is a partial, unflagged silent gap for the registration-failure branch specifically.\n\nsonnet-verified: partial equivalence confirmed \u2014 vanilla 6.18.38 (via 8b30fb40f8f2 + 928276075f16) makes the SET-failure path non-fatal, matching the fork's intent for genuine clone-controller-lacks-home-LED cases, but the REGISTRATION-failure path (hid-nintendo.c:2319-2323, `return ret;`) remains fatal in vanilla exactly as it was in 2021, unlike the fork which tolerated it too \u2014 real (if low-probability) carry candidate, and patch-provenance.md:334's grouped 'now upstream, drop' classification is not fully accurate for this commit. | RESOLVED (user carry decision 2026-07-14/15 (see silent-regressions.md + git d2f2791 follow-ups)): carried as 0035 \u2014 home-LED registration failure now warn+continue on 6.18. WAVE 3 LEDGER FIX (2026-09-11): this commit (docs/patch-provenance.md \u00a711's '0041' row cites it as '60821059c') is ALSO the origin of 0041-hid-nintendo-stock-led-classdev-names.patch (the stock player1-4/home LED classdev-name fix, a separable hunk of the same origin diff as 0035's registration fix). Added above as `carried_patches` so reduce.py's orphan-carried-patch invariant (which previously read only the single `carried_patch` field) stops flagging 0041 as unmapped; `carried_patch` stays 0035, the schema's canonical single-value field." -} \ No newline at end of file + "notes": "VERIFIED. Fork diff (drivers/hid/hid-nintendo.c, joycon_leds_create()) confirmed by `git show 60821059c`: both `return ret;` statements are commented out — (1) after `devm_led_classdev_register()` fails ('Failed registering home led'), (2) after `joycon_home_led_brightness_set()` fails ('Failed to set home LED dflt; ret=%d'). Both error paths become non-fatal in the fork.\n\nVanilla 6.18.38 history (all three SHAs confirmed via `git log`/`git show`/`git merge-base --is-ancestor` in /mnt/source/linux, checked out at tag v6.18.38):\n- `2af16c1f846b` (2021-09-11, Daniel J. Ogorchock) is simply the original upstream addition of hid-nintendo.c (869 lines, new file). It predates the fork's 2021-08-12 commit chronologically upstream (the fork's driver was an out-of-tree precursor) and, critically, is NOT specifically about home-LED error handling — at that point both the SET and REGISTER paths were still fully fatal upstream. Citing it as 'upstream coverage' for 60821059c's behavior (as patch-provenance.md:334's grouped row does) is not correct for this specific commit's effect.\n- `8b30fb40f8f2` (2022-04-15, Icenowy Zheng, 'HID: nintendo: deregister home LED when it fails') is the real fix for the 'clone controller doesn't support home LED' scenario described in its own commit message ('Some Pro Controller compatible controllers do not support home LED, and will fail when setting it. Currently this leads to probe failure.'). At the time, code order was register-then-set (matching the fork's pre-image exactly, including the literal string 'Failed to set home LED dflt; ret=%d'). The fix changed the post-registration SET failure from `hid_err(...); return ret;` to `hid_warn(...); devm_led_classdev_unregister(&hdev->dev, led);` (implicit `return 0`) — non-fatal. It did NOT touch the REGISTRATION failure, which remained `return ret;` (fatal) at that point in history.\n- `928276075f16` (2023-09-24, Martino Fontana, 'HID: nintendo: cleanup LED code') refactored the order to set-before-register: a new `joycon_set_home_led()` helper is called first, and only on success does `devm_led_classdev_register()` run. This is the current v6.18.38 shape (lines 2310-2323). SET failure is still non-fatal (skip registration, `return 0`) but implemented via a different mechanism than 8b30fb40f8f2's register+unregister approach. REGISTRATION failure is STILL untouched — `hid_err(...); return ret;` at 2319-2323 remains exactly as fatal as it was in 2021.\n\nConclusion: equivalence is PARTIAL, not fully contradicted and not fully equivalent. The SET-failure path (the actual 'clone controller lacks home LED hardware' scenario that motivated both the fork's patch and 8b30fb40f8f2's commit message) is equivalent/superseded-better upstream — dropping the fork's SET-path comment-out is safe. The REGISTRATION-failure path is a genuine, never-addressed gap: vanilla still hard-fails the ENTIRE controller probe (not just the LED) if devm_led_classdev_register() itself errors, while the fork tolerated it. This is a real carry candidate for that one residual line (hid-nintendo.c:2322 `return ret;`), though its real-world trigger probability is low — devm_led_classdev_register() failing is a kernel resource/sysfs issue (OOM, name collision), not a controller-hardware-capability issue; the hardware-capability case is already the SET path and is already fixed upstream. Only Pro Controller and right Joy-Con (including via Charging Grip) reach this code at all (jc_type_has_right() gate); left Joy-Con, SNES, N64, and Genesis NSO controllers have distinct ctlr_type values and never execute joycon_leds_create()'s home-LED branch, so the original record's affected_hardware/device_ids list (which included Joy-Con L, SNES, N64, Mega Drive) was overbroad and has been corrected here.\n\npatch-provenance.md:334 is a GROUPED ROW (c4ec5cb40, 9bdab534b, 60821059c, 45283785a all mapped to 2af16c1f846b, labeled Class C 'now upstream (drop)'). For this specific commit that classification is not fully accurate — hence disposition=misclassified rather than dropped-upstream, per the pilot-lesson rule (contradicted/partial-with-real-gap + provenance doc claimed upstream coverage ⇒ misclassified). Not carried in our build: grepped board/mister/de10nano/linux-patches/ for home-LED/joycon_leds_create strings — only hit is 0015-hid-nintendo-nso-famicom.patch, which does not touch LED code at all (confirmed via grep, no 'home'/'led'/'LED' matches). So this behavior is neither carried-by-patch nor fully dropped-upstream; it is a partial, unflagged silent gap for the registration-failure branch specifically.\n\nsonnet-verified: partial equivalence confirmed — vanilla 6.18.38 (via 8b30fb40f8f2 + 928276075f16) makes the SET-failure path non-fatal, matching the fork's intent for genuine clone-controller-lacks-home-LED cases, but the REGISTRATION-failure path (hid-nintendo.c:2319-2323, `return ret;`) remains fatal in vanilla exactly as it was in 2021, unlike the fork which tolerated it too — real (if low-probability) carry candidate, and patch-provenance.md:334's grouped 'now upstream, drop' classification is not fully accurate for this commit. | RESOLVED (user carry decision 2026-07-14/15 (see silent-regressions.md + git d2f2791 follow-ups)): carried as 0035 — home-LED registration failure now warn+continue on 6.18. WAVE 3 LEDGER FIX (2026-09-11): this commit (docs/patch-provenance.md §11's '0041' row cites it as '60821059c') is ALSO the origin of 0041-hid-nintendo-stock-led-classdev-names.patch (the stock player1-4/home LED classdev-name fix, a separable hunk of the same origin diff as 0035's registration fix). Added above as `carried_patches` so reduce.py's orphan-carried-patch invariant (which previously read only the single `carried_patch` field) stops flagging 0041 as unmapped; `carried_patch` stays 0035, the schema's canonical single-value field. | RETIRED 2026-09-12: 0041-hid-nintendo-stock-led-classdev-names.patch was deleted from board/mister/de10nano/linux-patches/ (and the beta/DE25 symlinks). Offered upstream as Linux-Kernel_MiSTer PR #97; the maintainer closed it in favour of the userspace fix, Main_MiSTer #1308 (in Release 20260912), so the kernel keeps mainline's name and nothing carries it. Dropped from carried_patches so reduce.py's mapping stays truthful; 0035 is unaffected and stays carried." +} diff --git a/docs/kernel-recon/silent-regressions.md b/docs/kernel-recon/silent-regressions.md index 43fb437f..230e0c54 100644 --- a/docs/kernel-recon/silent-regressions.md +++ b/docs/kernel-recon/silent-regressions.md @@ -1,6 +1,6 @@ # Silent-regression triage — the headline list -Generated 2026-09-11 03:37 UTC. Rows where the functionality is NOT covered in our 6.18 build (misclassified / needs-verification / not-evaluated) and failure is silent. Sorted worst-first. All tier-2 verified. +Generated 2026-09-12 17:05 UTC. Rows where the functionality is NOT covered in our 6.18 build (misclassified / needs-verification / not-evaluated) and failure is silent. Sorted worst-first. All tier-2 verified. **Total: 0 candidates** (of which 0 feature-loss). @@ -17,7 +17,7 @@ These WOULD regress silently if their patch (or, for `carried-as-package` rows, - `333d49b95` Implement MiSTer audio driver. → 0002-sound-add-MiSTer-audio-spi-and-snd-dummy-MiSTer-model.patch - `3d72b9db7` Add cpufreq/overclock driver (#34) → 0003-cpufreq-cyclone5-de10nano-overclock.patch - `41c45f378` Adapt Classic2USB and RetroZord HID force feedback support … → 0048-hid-google-stadiaff-classic2usb-retrozord.patch -- `45283785a` hid-nintendo: add virtual combo led, don't warn by IMU comp… → 0032-hid-nintendo-joycon-combo-led.patch, 0040-hid-nintendo-imu-name-suffix.patch +- `45283785a` hid-nintendo: add virtual combo led, don't warn by IMU comp… → 0032-hid-nintendo-joycon-combo-led.patch - `47dc53a22` wiimote: fix the buttons codes. → 0023-hid-wiimote-fixes.patch - `484f68172` input: Add support for the NSO Famicom controllers (no mic … → 0015-hid-nintendo-nso-famicom.patch - `52a56ae3d` mousedev: disable touch to click on DualShock4 and DualSens… → 0026-input-mousedev-eviocgrab.patch diff --git a/docs/patch-provenance.md b/docs/patch-provenance.md index 321ec35b..655e0cad 100644 --- a/docs/patch-provenance.md +++ b/docs/patch-provenance.md @@ -1609,8 +1609,8 @@ carries a self-documenting provenance header; this doc only needs the row. |---|---|---| | `0038-hid-nintendo-nso-genesis-bt-pid` | `b00a72159` (Shig) | stock-parity: forces the NSO Genesis pad's Bluetooth product ID from `ctlr_type` before the input_dev is created; without it the pad reports the SNES pad's `0x2017` and Main_MiSTer's gamecontrollerdb GUID lookup matches the wrong row | | `0039-hid-nintendo-nso-n64-genesis-stock-button-mapping` | `b00a72159` (Shig) | mainline's NSO N64/Genesis tables assign different evdev codes than stock — A/B outright swapped on N64, three of four C-buttons moved, six of ten Genesis bits differ; every gamecontrollerdb `bN` index shifts | -| `0040-hid-nintendo-imu-name-suffix` | `a6b7e3666` (Sorgelig) | Main_MiSTer excludes the IMU input device with `strstr(name, " IMU")` and that string test is its only hook; mainline's `"%s (IMU)"` does not match, so the IMU node is opened as a phantom controller | -| `0041-hid-nintendo-stock-led-classdev-names` | `60821059c` (Sorgelig) | stock `player1`-`player4`/`home` LED classdev names — Main_MiSTer opens these by exact path and treats a failed `fopen()` as a silent no-op, so under mainline's names every Switch controller loses userspace LED control (same origin commit as `0035`) | +| `0040-hid-nintendo-imu-name-suffix` | `a6b7e3666` (Sorgelig) | **RETIRED 2026-09-12 — slot intentionally empty.** Was: Main_MiSTer excludes the IMU input device with `strstr(name, " IMU")` and that string test is its only hook; mainline's `"%s (IMU)"` does not match, so the IMU node is opened as a phantom controller. Offered upstream as Linux-Kernel_MiSTer PR #96 alongside a userspace alternative; the maintainer closed the kernel PR ("better to follow mainline to be compatible with upstream kernel source") and merged Main_MiSTer #1307, which also matches `"(IMU)"`. Shipped in Main_MiSTer Release 20260912, so the kernel no longer needs to carry the name. The patch header's second consumer, SDL2's `SDL_strstr(name, " IMU")` filter, is *not* covered: an SDL2 program on this image now enumerates a Switch pad's `(IMU)` node as a second game controller — the same thing stock's own 6.18 kernel does, and nothing shipped uses SDL2's controller layer for it. | +| `0041-hid-nintendo-stock-led-classdev-names` | `60821059c` (Sorgelig) | **RETIRED 2026-09-12 — slot intentionally empty.** Was: stock `player1`-`player4`/`home` LED classdev names — Main_MiSTer opens these by exact path and treats a failed `fopen()` as a silent no-op, so under mainline's names every Switch controller loses userspace LED control (same origin commit as `0035`). Offered upstream as Linux-Kernel_MiSTer PR #97; closed ("we will use mainline version to be compatible with further updates") in favour of Main_MiSTer #1308, which falls back to `:green:player-1`..`-4` and `:blue:player-5` when the 5.15 paths are absent. Shipped in Release 20260912. `0035` (registration non-fatal) and `0032`'s `:combo` node are unaffected — `:combo` never had a mainline name to fall back to. | | `0042-hid-playstation-stock-lightbar-led-names` | `f123647ef` (Sorgelig) | stock lightbar LED names (`:red`/`:green`/`:blue`) plus probe-time player-LED clear; without them both PlayStation pads lose lightbar colour control | Config parity: `CONFIG_MACVLAN=y`, `CONFIG_JOYSTICK_XPAD=m`. All verified via full `linux-dirclean` rebuild. diff --git a/docs/reference-materials.md b/docs/reference-materials.md index 356239af..f55460c7 100644 --- a/docs/reference-materials.md +++ b/docs/reference-materials.md @@ -44,7 +44,34 @@ Tool versions used to produce this manifest (recorded for reproducibility): correct git blob for this exact filename/size in the source repo. - How to reproduce: `curl -LO ` and verify MD5/SHA-256 above. -### work/release_20260907.7z (the current `release.yml` pin, since 2026-09) +### work/release_20260912.7z (the current `release.yml` pin, since 2026-09-12) +- Source repo: MiSTer-devel/SD-Installer-Win64_MiSTer (branch: master) +- Committed as TWO split 7z volumes (consecutive byte slices of one archive): + release_20260912.7z.001 (blob 1b6bd927a33fbb282c636949088e3c12a0ae3ddb, 83,886,080 bytes, + MD5 2552d0d897b0ef043e8a7669239c123c) and + release_20260912.7z.002 (blob 85c7248963a2b61f4966f3f1b2ff3b33b42ca011, 42,660,398 bytes, + MD5 70cc944b99b8e2687d7df0fb168d7950) +- Introduced by commit: cd80db9c0ab64ba38be95071a090a80c367d63cf ("Release 20260912.", Sorgelig, 2026-09-12T13:01:42Z) +- Commit-pinned URLs (verified HTTP 200 on 2026-09-12): + https://raw.githubusercontent.com/MiSTer-devel/SD-Installer-Win64_MiSTer/cd80db9c0ab64ba38be95071a090a80c367d63cf/release_20260912.7z.001 + https://raw.githubusercontent.com/MiSTer-devel/SD-Installer-Win64_MiSTer/cd80db9c0ab64ba38be95071a090a80c367d63cf/release_20260912.7z.002 +- Joined (`cat release_20260912.7z.001 release_20260912.7z.002 > release_20260912.7z`): + Size: 126,546,478 bytes + MD5: 7cec2206e2a1133aa307c541219aa08f + SHA-256: 35fcbaca57cd2471b1d353f3dd4bae7c7e67256f8c5c8b2d6d5cbcc78269a7ea + `7z t` passes (`scripts/verify-stock-payload.sh verify-stock`: size/MD5/SHA-256/CRC). +- No `Distribution_MiSTer` `all_releases` mirror (`linux_release_20260912.7z`) existed on + 2026-09-12, and its live db.json still had `"linux": null`. +- Contents: same 24-member layout as 20260907. Delta vs 20260907 is exactly three + members: `files/linux/linux.img` (still kernel 6.18.38-MiSTer modules, + `/MiSTer.version` = `260912`), `files/linux/zImage_dtb` (8,564,005 → 8,626,429 B — + rebuilt with Linux-Kernel_MiSTer PRs #93/#94/#95/#98 and the "Add missing firmwares" + image-creator commit), and `files/MiSTer` (1,162,128 → 1,166,224 B, the 20260912 Main + build carrying Main_MiSTer #1307/#1308 — the reason this pin moved). `uboot.img` and + `updateboot` byte-identical to 20260907 and 20250402 (`verify-uboot` PASS). +- Full note: docs/verification/stock-release-20260912.md. + +### work/release_20260907.7z (the previous `release.yml` pin, 2026-09-10 → 2026-09-12) - Source repo: MiSTer-devel/SD-Installer-Win64_MiSTer (branch: master) - Committed as TWO split 7z volumes (consecutive byte slices of one archive): release_20260907.7z.001 (blob 9847e504acd304b469ac3b3fc8629216f0cb5262, 83,886,080 bytes, diff --git a/docs/renovate.md b/docs/renovate.md index f32a5201..60853074 100644 --- a/docs/renovate.md +++ b/docs/renovate.md @@ -215,8 +215,9 @@ the image. unpacked Buildroot tree. Left manual. - **`release.yml`'s pinned stock reference archive** - (`76fd6f4ced6350b0ad56a7013b41526f47e3a2fb` / - `release_20260907.7z.001` + `.002`, referenced via `raw.githubusercontent.com` + (`cd80db9c0ab64ba38be95071a090a80c367d63cf` / + `release_20260912.7z.001` + `.002` since 2026-09-12; before that `76fd6f4c…` / + `release_20260907`, referenced via `raw.githubusercontent.com` URLs in the `STOCK_RELEASE_URL` env var) — this is **not a dependency Renovate bumps**. It is a compatibility pin that moves only by a deliberate, reviewed change: `uboot.img`/`updateboot` must stay byte-identical to what @@ -224,7 +225,9 @@ the image. `docs/downloader-contract.md` §8/§12), and the auxiliary `files/linux/` payload moves only when stock's does (the 2026-09 bump from `release_20250402` changed exactly one shipped file, `MidiLink.INI`, and left - `uboot.img`/`updateboot` unchanged — + `uboot.img`/`updateboot` unchanged; the 2026-09-12 bump to `release_20260912` + changed only `files/MiSTer` among what we ship, again leaving both boot files + unchanged — `docs/verification/stock-release-20260907.md` §6.2 is the template for the next such bump: re-verify both boot files, re-derive the joined-archive hashes, re-run `verify-stock-payload.sh` end to end). No manager in diff --git a/docs/rt-beta-kernel.md b/docs/rt-beta-kernel.md index a6d6f6ee..cef61758 100644 --- a/docs/rt-beta-kernel.md +++ b/docs/rt-beta-kernel.md @@ -14,8 +14,8 @@ see `linux.hash`), and the kernel release string (`7.2.0-rc7` → **`7.2.0`**, which is the module directory name too). From here the pin tracks **7.2.y** point releases rather than mainline; it does not follow 7.3-rc1. See §10. -The variant builds end-to-end (`make rt`, **38 of the 40 shared + 4 beta-local** -carried patches — **42 entries; the two omissions are `0047` and `0050`, both +The variant builds end-to-end (`make rt`, **36 of the 38 shared + 4 beta-local** +carried patches — **40 entries; the two omissions are `0047` and `0050`, both of which 7.2.x already has in-tree in one form or another, see §2**; three of the beta-local four are the UIO set (§8) and the fourth is the ramoops crash-record reservation (§9)) and **boots and runs MiSTer on a @@ -86,9 +86,9 @@ with the per-variant fragment layered on at build time | File | Role | |---|---| | `configs/fragments/` (`common` + `de10nano` + `kernel-only`) | The kernel-only base stack, shared by every kernel variant. Its toolchain/kernel fragments are the **same files** the image stack uses (since the 2026-09 fragment split — before it, a hand-mirrored copy in `configs/mister_kernel_defconfig`); `scripts/check-kernel-defconfig-sync.sh` asserts that structure holds (CI runs it before every kernel build and as a lint). With no fragment it builds the main 6.18 kernel. | -| `configs/mister_rt.fragment` | Buildroot-config delta, layered on the `de10nano-kernel` fragment stack by `make rt` (kernel version → the 7.2 line, currently **`7.2.3`** — a plain point release, so Buildroot's `-rc` cgit-snapshot path in `linux/linux.mk` does not apply and it fetches the ordinary `linux-7.2.3.tar.xz` from the `v7.x` mirror directory; beta patch dir; kernel-config fragment). Merged onto the `de10nano-kernel` fragment stack (`common` + `de10nano` + `kernel-only`) via `merge_config.sh` by `make rt`. | +| `configs/mister_rt.fragment` | Buildroot-config delta, layered on the `de10nano-kernel` fragment stack by `make rt` (kernel version → the 7.2 line, currently **`7.2.5`** — a plain point release, so Buildroot's `-rc` cgit-snapshot path in `linux/linux.mk` does not apply and it fetches the ordinary `linux-7.2.5.tar.xz` from the `v7.x` mirror directory; beta patch dir; kernel-config fragment). Merged onto the `de10nano-kernel` fragment stack (`common` + `de10nano` + `kernel-only`) via `merge_config.sh` by `make rt`. | | `board/mister/de10nano/linux-rt.fragment` | **Kernel**-config delta layered on the shared `linux.config`: `CONFIG_PREEMPT_RT=y`, the `CONFIG_UIO*` + cmdline set the doorbells need (§8), and the `CONFIG_PSTORE*` set the ramoops node needs (§9) — do not confuse the two fragment layers (RTL8814AU's in-kernel driver comes from `linux.config` itself, inherited — not duplicated here; the same is true of the watchdog, §9.3). | -| `board/mister/de10nano/linux-patches-beta/` | `series` file + **symlinks** to the shared `linux-patches/` — except `0001`, `0015`, `0030`, `0031` and `0037`, which are real re-anchored copies (Buildroot patches at `-F0`; their 6.18 context or APIs drifted on 7.x — see the series header; `0031` since 2026-09-06 for an API delta that crashed, §6). The shared 6.18 patches stay byte-identical to stock. Applies **38 of the 40** shared patches in `linux-patches/` plus **four beta-local patches** (`0043-dts-uio-doorbells`, `0044-dts-uio-fpga-regions`, `0045-uio-writecombine` — see §8 — and `0046-dts-ramoops` — see §9; all real files in `linux-patches-beta/` only, kept out of the shared dir so the stock 6.18 build, which applies that entire directory via `BR2_LINUX_KERNEL_PATCH`, never sees them) — **42 entries**. The two shared patches it omits are `0047-btusb-mercusys-ma530-2c4e-0115` and, as of 2026-09-11, `0050-exfat-dir-readahead-plug`, and both omissions are forced rather than chosen: `0047` backports mainline `ce21a5cf3d1f` (Mercusys MA530/MA550H, USB `2c4e:0115`), whose **first release is 7.2**, so this kernel already carries those two lines in `drivers/bluetooth/btusb.c`. Listing it would not be a harmless double-apply — at `-F0` against a pristine `v7.2` the hunk **fails** (`Hunk #1 FAILED at 786`), breaking `make rt` at patch time. The 6.18 image needs it because 6.18.y never received the commit (no `Cc: stable`), and the whole exclusion disappears the day the stock pin leaves 6.18.y. `0050` is the mirror-image case: it wraps `exfat_dir_readahead()`'s `sb_breadahead()` loop in a block plug, but that function does not exist on 7.x at all — mainline's *own*, differently-shaped fix (`exfat_get_dentry()` + `exfat_blk_readahead()` in `fs/exfat/fatent.c`) is already in v7.2.3. At `-F0` against a pristine v7.2.3 the hunk **fails both hunks** (`Hunk #1 FAILED at 6. Hunk #2 FAILED at 682`). `0050` retires from `linux-patches/` outright the day the 6.18.y pin leaves 6.18.y, same as `0047`. Per the series header, "already in the 7.x tree, verified against the pristine tarball" is the **only** admissible reason to omit a shared patch — "it does not apply" never is on its own (that normally means re-anchor; it is only a valid *exclusion* reason when, as with `0047` and `0050`, the target release already has the same effect another way). ✅ **The five-patch gap closed 2026-08-17**: `0038`–`0042` had landed in the shared dir on 2026-07-24 and gone unlisted here for three weeks, which contradicted the standing rule in §7 item 3 (`0039` remaps NSO N64/Genesis buttons; `0040`/`0041`/`0042` are Main_MiSTer-coupled evdev-name and LED-classdev-name parity patches). Measured rather than assumed, they needed **no re-anchor at all** — plain symlinks, clean at `-F0` on 7.2 final, and `drivers/hid/` compiles for ARM with all five in (§6). (`0031` was a fifth copy until 2026-07-25, when the *shared* patch was re-anchored onto context both trees agree on and the beta entry became a symlink again; the series header explains why that is the preferred move.) `0015` is re-INCLUDED: the earlier "upstreamed in 7.2" finding was wrong (7.2 has no `FAML`/`FAMR` controller types — its left/right *nescon* support is a different thing). ✅ **`0048` and `0049` added 2026-09-11** (fork-sync increment 2026-09 Wave 3, docs/kernel-recon/fork-sync-2026-09/PLAN.md §2.8/§2.10): both plain symlinks, both Main_MiSTer-coupled (input.cpp special-cases), both apply-verified at `-F0` against a pristine v7.2.3 as part of the full 42-entry series replay — `0048` at zero offset, `0049` at offsets only (20/21/21 lines across its three hunks) on top of this series' own `0015`/`0032`/`0034`/`0035`/`0038`–`0041` hid-nintendo stack, zero fuzz either way. `0049` carries an unmerged upstream PR (#92); see its patch header for the re-check procedure once it merges. The separate `linux-patches-upstream/` series (carried for the exported `Linux-Kernel_MiSTer` tree only, never applied by Buildroot — `docs/patch-provenance.md` §12) is unrelated to this count and is not applied to the beta either. | +| `board/mister/de10nano/linux-patches-beta/` | `series` file + **symlinks** to the shared `linux-patches/` — except `0001`, `0015`, `0030`, `0031` and `0037`, which are real re-anchored copies (Buildroot patches at `-F0`; their 6.18 context or APIs drifted on 7.x — see the series header; `0031` since 2026-09-06 for an API delta that crashed, §6). The shared 6.18 patches stay byte-identical to stock. Applies **36 of the 38** shared patches in `linux-patches/` plus **four beta-local patches** (`0043-dts-uio-doorbells`, `0044-dts-uio-fpga-regions`, `0045-uio-writecombine` — see §8 — and `0046-dts-ramoops` — see §9; all real files in `linux-patches-beta/` only, kept out of the shared dir so the stock 6.18 build, which applies that entire directory via `BR2_LINUX_KERNEL_PATCH`, never sees them) — **40 entries** (42 until 2026-09-12, when `0040`/`0041` were retired from the shared series in favour of Main_MiSTer #1307/#1308). The two shared patches it omits are `0047-btusb-mercusys-ma530-2c4e-0115` and, as of 2026-09-11, `0050-exfat-dir-readahead-plug`, and both omissions are forced rather than chosen: `0047` backports mainline `ce21a5cf3d1f` (Mercusys MA530/MA550H, USB `2c4e:0115`), whose **first release is 7.2**, so this kernel already carries those two lines in `drivers/bluetooth/btusb.c`. Listing it would not be a harmless double-apply — at `-F0` against a pristine `v7.2` the hunk **fails** (`Hunk #1 FAILED at 786`), breaking `make rt` at patch time. The 6.18 image needs it because 6.18.y never received the commit (no `Cc: stable`), and the whole exclusion disappears the day the stock pin leaves 6.18.y. `0050` is the mirror-image case: it wraps `exfat_dir_readahead()`'s `sb_breadahead()` loop in a block plug, but that function does not exist on 7.x at all — mainline's *own*, differently-shaped fix (`exfat_get_dentry()` + `exfat_blk_readahead()` in `fs/exfat/fatent.c`) is already in v7.2.3. At `-F0` against a pristine v7.2.3 the hunk **fails both hunks** (`Hunk #1 FAILED at 6. Hunk #2 FAILED at 682`). `0050` retires from `linux-patches/` outright the day the 6.18.y pin leaves 6.18.y, same as `0047`. Per the series header, "already in the 7.x tree, verified against the pristine tarball" is the **only** admissible reason to omit a shared patch — "it does not apply" never is on its own (that normally means re-anchor; it is only a valid *exclusion* reason when, as with `0047` and `0050`, the target release already has the same effect another way). ✅ **The five-patch gap closed 2026-08-17**: `0038`–`0042` had landed in the shared dir on 2026-07-24 and gone unlisted here for three weeks, which contradicted the standing rule in §7 item 3 (`0039` remaps NSO N64/Genesis buttons; `0040`/`0041`/`0042` are Main_MiSTer-coupled evdev-name and LED-classdev-name parity patches). Measured rather than assumed, they needed **no re-anchor at all** — plain symlinks, clean at `-F0` on 7.2 final, and `drivers/hid/` compiles for ARM with all five in (§6). (`0031` was a fifth copy until 2026-07-25, when the *shared* patch was re-anchored onto context both trees agree on and the beta entry became a symlink again; the series header explains why that is the preferred move.) `0015` is re-INCLUDED: the earlier "upstreamed in 7.2" finding was wrong (7.2 has no `FAML`/`FAMR` controller types — its left/right *nescon* support is a different thing). ✅ **`0048` and `0049` added 2026-09-11** (fork-sync increment 2026-09 Wave 3, docs/kernel-recon/fork-sync-2026-09/PLAN.md §2.8/§2.10): both plain symlinks, both Main_MiSTer-coupled (input.cpp special-cases), both apply-verified at `-F0` against a pristine v7.2.3 as part of the full 42-entry series replay — `0048` at zero offset, `0049` at offsets only (20/21/21 lines across its three hunks) on top of this series' own `0015`/`0032`/`0034`/`0035`/`0038`–`0041` hid-nintendo stack, zero fuzz either way. `0049` carries an unmerged upstream PR (#92); see its patch header for the re-check procedure once it merges. The separate `linux-patches-upstream/` series (carried for the exported `Linux-Kernel_MiSTer` tree only, never applied by Buildroot — `docs/patch-provenance.md` §12) is unrelated to this count and is not applied to the beta either. | | `Makefile` (`rt`, `rt-clean`, `rt-menuconfig`) | Builds into `output-rt/` (stage-1 initramfs first — its cpio is embedded into every kernel), reusing the shared dl/ccache; then stages the depmod'd module tree into `work/extra-modules-overlay/`, which the main defconfig's `BR2_ROOTFS_OVERLAY` folds into the ONE shipped `linux.img` at the next `make all`. The main `output/` is never touched by `make rt` itself. | The kernel config is the same `linux.config` + a fragment, and the patch set is @@ -241,7 +241,7 @@ card, and nothing on the card referenced it), and deliberately NOT inside | 7.2 has ARM32 `ARCH_SUPPORTS_RT` in-tree | ✅ verified (`arch/arm/Kconfig`) | | Config layering (fragment → 7.2 config) resolves | ✅ verified (`merge_config.sh` + `olddefconfig`, clean) | | `linux.config` reconciles to 7.2 (criticals survive) | ✅ **after a real fix (2026-07-18)**: the earlier full-config test masked a minimal-config trap — 7.x turned the HID drivers' LED `select`s into `depends on`, so `olddefconfig` silently dropped `NEW_LEDS`/`LEDS_CLASS` **and with them the whole HID controller stack** (`HID_PLAYSTATION`/`HID_NINTENDO` vanished from the config, no error). Fixed by making the LED foundation explicit in `linux.config` (`NEW_LEDS`/`LEDS_CLASS`/`LEDS_TRIGGERS`, no-ops on 6.18); all 19 critical symbols re-audited present | -| **All 42 series entries** (38 of the 40 shared + the 4 beta-local) apply to the pinned **7.2.3** at Buildroot's `patch -F0` (`linux-patches/`; the separate `linux-patches-upstream/` series is never applied to this variant — see §2) | ✅ **re-verified 2026-09-11 on the full 42-entry series** (fork-sync increment 2026-09 Wave 3, adding `0048`/`0049`), replayed with `patch -p1 -F0` in series order against a v7.2.3 tree: **42/42 applied, exit 0, zero hunks taking fuzz**. `0048` lands at zero offset; `0049` lands at offsets only (hunk 1 +20, hunks 2-3 +21) on top of this series' own `0015`/`0032`/`0034`/`0035`/`0038`–`0041` hid-nintendo stack. A separate dry-run confirmed `0050` (the newly-added 6.18-only patch, correctly NOT in this series) still fails both hunks against the same v7.2.3 tree. This re-verification is apply-only; `make rt` has not been re-run on the 42-entry series. ✅ Previously **re-verified 2026-08-17 on the full 40-entry series**, through Buildroot's own `apply-patches.sh` against a freshly extracted pristine `linux-7.2.tar.xz` whose sha256 matched kernel.org's signed manifest (`f9fef3d1…`): **40/40 applied, exit 0, zero hunks taking fuzz** (80 hunks land at an offset, which `-F0` permits). No re-anchor was needed anywhere: the four re-anchored copies (0001, 0015, 0030, 0037) carry over unchanged and, with all four beta-local patches, land at **zero offset**. The offsets are concentrated where they always were (`0017` 18, `0031` 12, `0033` 5, `0042` 5). **This row now measures the whole series** — the standing "⚠ not evidence about `0038`–`0042`" caveat is retired, because those five are in the series as of the same day (§2). Three measurements were taken that day and each is a strict superset of the last: **34/34** on the rc7 → 7.2 bump (70 offsets), **35/35** once `0046` landed (70 offsets — identical distribution, so `0046` costs the rest of the series nothing), **40/40** with `0038`–`0042` symlinked in (80 offsets, the ten new ones all inside the five added patches). Earlier figures (31/31 on rc5; before that 29/29, and a bogus "28/31" measured at `patch`'s default fuzz 2, which Buildroot forbids) predate the 2026-07-20 `0037`/`0030` re-anchors and the beta-local set. ⚠ Applying is not building — see the next row | +| **All series entries** (42 at the time: 38 of the 40 shared + the 4 beta-local; 40 since the 2026-09-12 retirement of `0040`/`0041`, whose absence was re-checked at `-F0` on v7.2.5 — the current pin — for the surviving hid-nintendo stack, and `hid-nintendo.o` cross-compiled `W=1` clean there) apply to the pinned **7.2.3** at Buildroot's `patch -F0` (`linux-patches/`; the separate `linux-patches-upstream/` series is never applied to this variant — see §2) | ✅ **re-verified 2026-09-11 on the full 42-entry series** (fork-sync increment 2026-09 Wave 3, adding `0048`/`0049`), replayed with `patch -p1 -F0` in series order against a v7.2.3 tree: **42/42 applied, exit 0, zero hunks taking fuzz**. `0048` lands at zero offset; `0049` lands at offsets only (hunk 1 +20, hunks 2-3 +21) on top of this series' own `0015`/`0032`/`0034`/`0035`/`0038`–`0041` hid-nintendo stack. A separate dry-run confirmed `0050` (the newly-added 6.18-only patch, correctly NOT in this series) still fails both hunks against the same v7.2.3 tree. This re-verification is apply-only; `make rt` has not been re-run on the 42-entry series. ✅ Previously **re-verified 2026-08-17 on the full 40-entry series**, through Buildroot's own `apply-patches.sh` against a freshly extracted pristine `linux-7.2.tar.xz` whose sha256 matched kernel.org's signed manifest (`f9fef3d1…`): **40/40 applied, exit 0, zero hunks taking fuzz** (80 hunks land at an offset, which `-F0` permits). No re-anchor was needed anywhere: the four re-anchored copies (0001, 0015, 0030, 0037) carry over unchanged and, with all four beta-local patches, land at **zero offset**. The offsets are concentrated where they always were (`0017` 18, `0031` 12, `0033` 5, `0042` 5). **This row now measures the whole series** — the standing "⚠ not evidence about `0038`–`0042`" caveat is retired, because those five are in the series as of the same day (§2). Three measurements were taken that day and each is a strict superset of the last: **34/34** on the rc7 → 7.2 bump (70 offsets), **35/35** once `0046` landed (70 offsets — identical distribution, so `0046` costs the rest of the series nothing), **40/40** with `0038`–`0042` symlinked in (80 offsets, the ten new ones all inside the five added patches). Earlier figures (31/31 on rc5; before that 29/29, and a bogus "28/31" measured at `patch`'s default fuzz 2, which Buildroot forbids) predate the 2026-07-20 `0037`/`0030` re-anchors and the beta-local set. ⚠ Applying is not building — see the next row | | **`0038`–`0042` and `0046` compile on 7.2** (the six the series gained on 2026-08-17) | ✅ **verified twice, 2026-08-17.** First cheaply: a targeted ARM cross-compile of `drivers/hid/`, `drivers/leds/` and `fs/pstore/` on the 40-patch tree with the real config — exit 0, **zero warnings, zero errors**, `hid-nintendo.o` and `hid-playstation.o` (the two files all five HID patches touch) and `fs/pstore/ram.o` (`0046`'s consumer) all built. Then for real, inside the full `make rt` below, with Buildroot's own toolchain rather than the host's — which is the run that counts | | `xone` compiles on 7.2 | ✅ verified (not shipped by the kernel-only variant — §4) | | **The RT kernel compiles and links** | ✅ **re-verified locally on rc5 (2026-07-28), and again on rc7** (the `output-rt` tree for the pinned 7.2-rc7 holds a linked `zImage`, `CONFIG_PREEMPT_RT=y`, kernel release `7.2.0-rc7`) — see the `make rt` row below, which is the same cross-build end to end. Two 7.x API ports were needed back on rc3 and still live in beta-local patch copies — the shared 6.18 patches stay byte-identical to stock: `fbcon_update_vcs()`'s header moved into fbdev core (beta 0001, one-line include delta), and `exfat_remove_entries()` grew a `free_benign` arg (that one was folded back into the shared patch on 2026-07-25, so beta 0031 is a symlink again). Unlike the rc3 → rc4 bump, which re-verified patch application only and left this row resting on CI, the rc4 → rc5 bump was built locally before the pin was pushed. ✅ **Re-verified on 7.2 final, 2026-08-17**, from a clean `make rt-clean` (both toolchains from scratch, no ccache): exit 0, kernel release string **`7.2.0`**, `CONFIG_PREEMPT_RT=y` in the built tree's `.config`, and `.applied_patches_list` records all **34** series entries as they stood that day — the first time the beta-local `0044`/`0045` have been through a real build rather than an apply-check. No 7.x API port was needed beyond the ones already carried. ✅ **Re-verified on the full 40-entry series later the same day**, again from a clean tree: exit 0, release `7.2.0`, `CONFIG_PREEMPT_RT=y`, `.applied_patches_list` 40 entries ending `0044` → `0045` → `0046`. That run is the first to have compiled `0038`–`0042` and `0046` as part of a kernel rather than as an apply-check or a subsystem build. | diff --git a/docs/user/beta-testing.md b/docs/user/beta-testing.md index 2f6b3c47..f26926ef 100644 --- a/docs/user/beta-testing.md +++ b/docs/user/beta-testing.md @@ -31,7 +31,7 @@ rather than a local build. | Works, confirmed on hardware | | |---|---| | Boots to the MiSTer menu; cores load | ✅ | -| The unmodified, stock `MiSTer` binary runs | ✅ | +| The unmodified, stock `MiSTer` binary runs | ✅ — **Release 20260912 or newer** since 2026-09-12: the Switch controller IMU/LED naming fix moved from our kernel to Main_MiSTer (#1307/#1308); an older `MiSTer` on this image shows a phantom IMU pad and dark Switch player/home LEDs. `update_all.sh` brings the binary forward. | | All out-of-tree modules present; no kernel BUG/Oops/panic | ✅ | | Bluetooth — firmware loads, controller pairs | ✅ | | Wi-Fi — WPA3/SAE (PMF required), 5 GHz, auto-connect at boot, via mainline `rtw88` | ✅ | diff --git a/docs/verification/stock-release-20260912.md b/docs/verification/stock-release-20260912.md new file mode 100644 index 00000000..6ab44a7a --- /dev/null +++ b/docs/verification/stock-release-20260912.md @@ -0,0 +1,76 @@ +# Verification of stock release `release_20260912` — a Main_MiSTer bump, and why we pinned it + +Date: 2026-09-12. Companion to [`stock-release-20260907.md`](stock-release-20260907.md), which +remains the full analysis of stock's 6.18 era; this release changes almost nothing that document +measured, so this note records only the pin move and what actually differs. + +## Why the pin moved + +Linux-Kernel_MiSTer PRs #96/#97 (the Switch controller `" IMU"` suffix and the 5.15 +`player1..4`/`home` LED names) were closed in favour of the Main_MiSTer-side fix, +Main_MiSTer #1307/#1308, merged 2026-09-12 and first shipped in **Release 20260912**. The +same PR that retires our kernel patches `0040`/`0041` therefore moves the stock payload pin, so a +tag-built `sdcard.img` never pairs a kernel emitting mainline names with a `files/MiSTer` that +only matches the old ones. (A first-boot `update_all.sh`/`update.sh` would fix that on its own; +the pin move keeps the shipped state consistent regardless.) + +## 1. Artifact identity + +| Item | `release_20260907` (previous pin) | `release_20260912` (pinned now) | +|---|---|---| +| SD-Installer commit | `76fd6f4ced6350b0ad56a7013b41526f47e3a2fb` | `cd80db9c0ab64ba38be95071a090a80c367d63cf` ("Release 20260912.", Sorgelig, 2026-09-12 13:01 UTC) | +| Volumes | `.001` 83,886,080 B + `.002` 34,050,686 B | `.001` 83,886,080 B (blob `1b6bd927…`, MD5 `2552d0d8…`) + `.002` 42,660,398 B (blob `85c72489…`, MD5 `70cc944b…`) | +| Joined archive | 117,936,766 B, MD5 `8cd4edca…`, sha256 `e5bea841…` | **126,546,478 B**, MD5 **`7cec2206e2a1133aa307c541219aa08f`**, sha256 `35fcbaca57cd2471b1d353f3dd4bae7c7e67256f8c5c8b2d6d5cbcc78269a7ea` | +| `Distribution_MiSTer` mirror (`linux_release_.7z`) | exists, byte-identical | **none yet** on 2026-09-12; live db.json still `"linux": null` | +| Members | 24 | 24, same layout | +| `linux.img` | 393,216,000 B, modules `6.18.38-MiSTer`, `/MiSTer.version` `260907` | 393,216,000 B, modules still `6.18.38-MiSTer`, `/MiSTer.version` **`260912`** | +| `zImage_dtb` | 8,564,005 B | **8,626,429 B** — rebuilt from `MiSTer-v6.18` after PRs #93 (`LEDS_CLASS_MULTICOLOR`), #94 (`IP_NF_FILTER`), #95 (NSO N64/Genesis maps), #98 (`MiSTer_fb` `memremap()` check); the image-creator also took "Add missing firmwares" (`b02ec9a1f`) and "Add AIC8800 firmware" (`7843c7036`) | +| `files/MiSTer` | 1,162,128 B (CRC `2AD33899`) | **1,166,224 B** (CRC `20A80ACB`) — `strings` shows `(IMU)`, `:green:player-1`, `:blue:player-5` | +| `uboot.img` | sha256 `e2d46cf9…62a64`, 515,141 B | **identical** | +| `updateboot` | sha256 `6ff2d50a…562f2`, 407 B | **identical** | +| Upstream build inputs | `Linux_Image_creator_MiSTer` `d4e3f51` | `9d9ff03ad` ("Release 20260912.", 2026-09-12 12:55 UTC) | + +## 2. What moved — exactly three members + +`7z l -slt` on both joined archives, compared by path/size/CRC: **only** `files/MiSTer`, +`files/linux/linux.img` and `files/linux/zImage_dtb` differ. The 21 other members +(`MidiLink.INI`, `_samba.sh`, `_user-startup.sh`, `_wpa_supplicant.conf`, `gamecontrollerdb`, +`mt32-rom-data`, `ppp_options`, `soundfonts`, `u-boot.txt_example`, `uboot.img`, `updateboot`, +`menu.rbf`, `MiSTer_example.ini`, `Scripts/update.sh`, the `.exe`, …) are byte-identical. + +Consequences for us: + +- **Shipped payload:** `linux.img` and `zImage_dtb` are ours, never stock's, so the only shipped + file this bump changes is `files/MiSTer` on `sdcard.img` (via `scripts/fetch-sdcard-payload.sh`). + `files/linux/` as we ship it is unchanged. +- **Boot contract:** `uboot.img`/`updateboot` unchanged for the third release running, so the + `STOCK_UBOOT_*`/`STOCK_UPDATEBOOT_*` pins hold ([`downloader-contract.md`](../downloader-contract.md) §8/§12). +- **Kernel-side parity docs** (`stock-release-20260907.md` §2–§5, `docs/kernel-recon/fork-sync-2026-09/`) + are not invalidated: the module set is still `6.18.38-MiSTer`; the rebuilt `zImage_dtb` folds in + the four merged PRs above, which our series already carries or does not need + (`0039` = #95; #98's fix is in our `0001`; #93/#94 are config we already set). + The next fork-sync increment picks up the branch head (`912aa5608`, "hid-playstation: fix + warning.") in the normal way. + +## 3. Verification run (2026-09-12, local) + +With the new `STOCK_*` values exported exactly as `release.yml` now carries them: + +``` +scripts/verify-stock-payload.sh fetch-stock → 2 volumes joined +scripts/verify-stock-payload.sh verify-stock → size/MD5/SHA-256/internal-CRC all match +scripts/verify-stock-payload.sh extract-stock → 13 files, files/linux/* +scripts/verify-stock-payload.sh verify-uboot → uboot.img and updateboot byte-identical to stock +``` + +The joined volumes were also hashed independently before the script ran (same MD5/SHA-256), and +the previous pin's volumes were re-fetched and re-verified against the old values (117,936,766 B, +`8cd4edca…`) to make the member diff above a like-for-like comparison. + +## 4. Places the pin lives (all moved together) + +`.github/workflows/release.yml` (`STOCK_RELEASE_URL/MD5/SHA256/SIZE`, the source of truth), +`scripts/fetch-sdcard-payload.sh` (its `:=` defaults), `scripts/verify-stock-payload.sh` (the +example block in its header), `docs/ci.md` (stock-payload sourcing), `docs/reference-materials.md` +§1, `docs/renovate.md` (the "deliberately not managed" paragraph) and +`docs/downloader-contract.md` §11.1's dated note. diff --git a/scripts/fetch-sdcard-payload.sh b/scripts/fetch-sdcard-payload.sh index 070f2ecb..ea7f1e08 100755 --- a/scripts/fetch-sdcard-payload.sh +++ b/scripts/fetch-sdcard-payload.sh @@ -13,7 +13,7 @@ # # Sources staged, and why each is safe/necessary: # -# 1. The pinned stock release_20260907 archive (SAME URL/MD5/SHA256/size as +# 1. The pinned stock release_20260912 archive (SAME URL/MD5/SHA256/size as # .github/workflows/release.yml — do not let these drift independently; # if release.yml's STOCK_* values ever change, mirror the change here). # Upstream commits it as split 7z volumes (.7z.001 + .7z.002), so @@ -21,7 +21,9 @@ # are concatenated, in order, into one stock_release.7z; the MD5/ # SHA256/size pins are those of the JOINED file (the only form the # on-device 7za ever sees -- docs/verification/stock-release-20260907.md -# §6.2). We verify it byte-for-byte BEFORE extracting anything from it, then +# §6.2; the 2026-09-12 move to release_20260912 is recorded in +# docs/verification/stock-release-20260912.md). We verify it byte-for-byte +# BEFORE extracting anything from it, then # extract more members than release.yml does (which only takes # files/linux/*): files/linux/*, files/MiSTer, files/menu.rbf, # files/MiSTer_example.ini, files/Scripts/update.sh — the Windows- @@ -101,10 +103,10 @@ readonly SDCARD_CORES # itself, once it wires this script in) can export its own copies instead # of us duplicating the literals — but the defaults below are the source of # truth if nothing overrides them. -: "${STOCK_RELEASE_URL:=https://raw.githubusercontent.com/MiSTer-devel/SD-Installer-Win64_MiSTer/76fd6f4ced6350b0ad56a7013b41526f47e3a2fb/release_20260907.7z.001 https://raw.githubusercontent.com/MiSTer-devel/SD-Installer-Win64_MiSTer/76fd6f4ced6350b0ad56a7013b41526f47e3a2fb/release_20260907.7z.002}" -: "${STOCK_RELEASE_MD5:=8cd4edca838fdc226390e3fb04f3ca79}" -: "${STOCK_RELEASE_SHA256:=e5bea8413adc249f420e08a48e5cdab9b8c5da04bf52d81dc5261f0f350adf66}" -: "${STOCK_RELEASE_SIZE:=117936766}" +: "${STOCK_RELEASE_URL:=https://raw.githubusercontent.com/MiSTer-devel/SD-Installer-Win64_MiSTer/cd80db9c0ab64ba38be95071a090a80c367d63cf/release_20260912.7z.001 https://raw.githubusercontent.com/MiSTer-devel/SD-Installer-Win64_MiSTer/cd80db9c0ab64ba38be95071a090a80c367d63cf/release_20260912.7z.002}" +: "${STOCK_RELEASE_MD5:=7cec2206e2a1133aa307c541219aa08f}" +: "${STOCK_RELEASE_SHA256:=35fcbaca57cd2471b1d353f3dd4bae7c7e67256f8c5c8b2d6d5cbcc78269a7ea}" +: "${STOCK_RELEASE_SIZE:=126546478}" : "${STOCK_UBOOT_SHA256:=e2d46cf9fe1ec40ca2c9c7409870249f267e06f70e5736dc6d30b4e21fe62a64}" : "${STOCK_UBOOT_SIZE:=515141}" : "${STOCK_UPDATEBOOT_SHA256:=6ff2d50a080e26d7173b61c52083e9cc42ca658db0c5031b4da1c45c74a562f2}" diff --git a/scripts/verify-stock-payload.sh b/scripts/verify-stock-payload.sh index f801a4a2..aed737db 100755 --- a/scripts/verify-stock-payload.sh +++ b/scripts/verify-stock-payload.sh @@ -24,10 +24,10 @@ # loudly, not silently drift, if release.yml's env block and this script's # caller ever disagree). A local run therefore looks like: # -# export STOCK_RELEASE_URL="https://raw.githubusercontent.com/MiSTer-devel/SD-Installer-Win64_MiSTer/76fd6f4ced6350b0ad56a7013b41526f47e3a2fb/release_20260907.7z.001 https://raw.githubusercontent.com/MiSTer-devel/SD-Installer-Win64_MiSTer/76fd6f4ced6350b0ad56a7013b41526f47e3a2fb/release_20260907.7z.002" -# export STOCK_RELEASE_MD5=8cd4edca838fdc226390e3fb04f3ca79 -# export STOCK_RELEASE_SHA256=e5bea8413adc249f420e08a48e5cdab9b8c5da04bf52d81dc5261f0f350adf66 -# export STOCK_RELEASE_SIZE=117936766 +# export STOCK_RELEASE_URL="https://raw.githubusercontent.com/MiSTer-devel/SD-Installer-Win64_MiSTer/cd80db9c0ab64ba38be95071a090a80c367d63cf/release_20260912.7z.001 https://raw.githubusercontent.com/MiSTer-devel/SD-Installer-Win64_MiSTer/cd80db9c0ab64ba38be95071a090a80c367d63cf/release_20260912.7z.002" +# export STOCK_RELEASE_MD5=7cec2206e2a1133aa307c541219aa08f +# export STOCK_RELEASE_SHA256=35fcbaca57cd2471b1d353f3dd4bae7c7e67256f8c5c8b2d6d5cbcc78269a7ea +# export STOCK_RELEASE_SIZE=126546478 # export STOCK_UBOOT_SHA256=e2d46cf9fe1ec40ca2c9c7409870249f267e06f70e5736dc6d30b4e21fe62a64 # export STOCK_UBOOT_SIZE=515141 # export STOCK_UPDATEBOOT_SHA256=6ff2d50a080e26d7173b61c52083e9cc42ca658db0c5031b4da1c45c74a562f2