Skip to content

soc: apple: aop: start AFK endpoints 0x2f and 0x30 for the 27.2 AOP firmware (K116s) - #1645

Open
sithglan wants to merge 1 commit into
aurora-silicon:integration/aurorafrom
sithglan:thomas/k116s-aop-endpoints
Open

sithglan wants to merge 1 commit into
aurora-silicon:integration/aurorafrom
sithglan:thomas/k116s-aop-endpoints

Conversation

@sithglan

@sithglan sithglan commented Nov 12, 2026 •

Copy link
Copy Markdown
Contributor

Base: integration/aurora (050f6a5). One commit.

The 27.2 AOP firmware (AppleAOPAudioFirmware-610.18, K116s) advertises AFK endpoints 0x20-0x27 and 0x29-0x30. Its boot stage setup_endpoints brings them up one at a time and waits for the host's STARTEP on each. The driver started only 0x20-0x2e, so the firmware waited for 0x2f forever ("waiting for endpoint enable, _routing=0x2f" in its log). It never reached system_ready/services_ready and announced no EPIC service at all: no aop-audio, so no sound card, and no sensors.

AFK_ENDPOINT_COUNT goes from 0xf to 0x11. start_afk() still skips an endpoint the firmware does not advertise (has_endpoint()), so older firmware with fewer endpoints is unaffected. Every T6050 machine that moves to the 27.2 stub (J714s and others) needs this.

Tested by Jens on the K116s (27.2, 26B8125): the firmware announces its 20 services and the sound card registers.

Build: arm64, LLVM 22, Rust; drivers/soc/apple/ with Jens's K116s config, no new warnings.

Authorship. Jens Axboe wrote these commits and runs them on his K116s (16-inch MacBook Pro, M5 Pro, OLED; Mac17,12; stub macOS 27.2 26B8125). They come from his K116s bundle of 2026-11-11 (integration/aurora 254c9bd plus 34 commits, kernel 7.3.0 running on the machine). I rebased them onto integration/aurora 050f6a5 and removed the LLM co-author and session trailers. Jens has given his OK: the commits carry his Signed-off-by.

The K116s AOP firmware (27.2, AppleAOPAudioFirmware-610.18) advertises
AFK endpoints 0x20-0x27 and 0x29-0x30. Its boot stage "setup_endpoints"
brings them up one at a time and waits for the host's STARTEP on each
("waiting for endpoint enable, _routing=0x2f" in its log, where the value
is route << 16 | endpoint). The driver only knew 0x20-0x2e, so the
firmware waited for 0x2f (als-temp-2) forever, never reached its
system_ready and services_ready stages and announced no EPIC service: no
aop-audio, so no sound card, and no sensors.

Cover 0x2f and 0x30 (devmotion3). The firmware then announces its 20
services and the card registers.

Signed-off-by: Jens Axboe <axboe@kernel.dk>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants