Voortgangsrapport: Linux 7.2 - Asahi Linux

Opnieuw 'Think Different' denken

De infrastructuur voor stroombeheer van het Apple Silicon-platform is gecompliceerd. De verantwoordelijkheden zijn verdeeld over meerdere hardwareblokken, waaronder de SMC, PMGR en PMP, die allemaal al eerder op deze blog zijn behandeld. Hoewel ondersteuning voor deze blokken belangrijk is voor het stroomverbruik, is een van de grootste obstakels voor het verbeteren van de batterijduur de applicatiekernen zelf.

Er zijn meerdere manieren om een CPU-kern in "slaapstand" te zetten, en elke manier moet in een specifieke context worden gebruikt. De meest basale manier om een ARM CPU-kern te laten slapen is het gebruik van een Wait For Interrupt (WFI)-instructie. Dit vertelt de kern om te stoppen met werken totdat hij wordt gewekt door een interrupt van een interruptbron. Hoewel dit stroom bespaart doordat de kern stopt met het uitvoeren van code, blijft de kern onder stroom staan en behoudt hij genoeg status om het werk extreem snel te kunnen hervatten. Daarom wordt WFI doorgaans alleen gebruikt voor het parkeren van een kern op een draaiend systeem.

Apple-kernen bevatten een "diepe" WFI-modus, die meer van de kern uitschakelt, maar ten koste gaat van het verlies van de status. Onze downstream cpuidle-driver werkt door WFI in deze modus in te stellen, de status van de kern op te slaan en vervolgens een WFI-loop uit te voeren.

Vendor-specifieke eigenaardigheden in stroombeheer zoals deze komen vaak voor. Gelukkig is er voor kernel-onderhouders een standaardmanier om hiermee om te gaan: de Power State Coordination Interface (PSCI). PSCI definieert een standaardinterface waarmee een besturingssysteem een gedefinieerde set CPU-kernstroombeheerfuncties kan aanroepen die zijn geïmplementeerd door de systeemfirmware, inclusief het voorbereiden van de kernen op de slaapstand.

Om een wildgroei aan vendor-specifieke stroombeheer-hacks in de Linux-kernel te voorkomen, hebben de onderhouders van de arm64 architectuur-specifieke code bepaald dat alle upstream hardware PSCI moet gebruiken voor stroombeheer. Hierdoor kunnen we onze Apple-specifieke cpuidle-driver niet upstreamen. Waarom gebruiken we deze dan nog steeds?

PSCI definieert "conduits" (kanalen) waarlangs aanroepen naar de firmware vanuit de kernel worden verzonden. De twee momenteel ondersteunde conduits in de kernel zijn de SMC (Secure Monitor Call) en HVC (Hypervisor Call) instructies, die worden gebruikt om de uitvoering over te dragen aan een hoger Exception Level. De Linux-kernel verwacht te draaien op EL2, wat betekent dat zijn PSCI-aanroepen moeten overgaan naar firmware die draait op EL3. Echter, Apple's kernen implementeren geen EL3...

Omdat de kernel al draait op EL2 en er geen firmware draait op EL3 om mee te communiceren, zitten we een beetje vast. Linux kan geen SMC- of HVC-instructie utfieren omdat er geen EL3 is om de uitvoering aan over te dragen, wat betekent dat we geen gebruik kunnen maken van PSCI. Het correct kunnen beheren van het stroomverbruik van de CPU-kernen is essentieel voor de batterijduur en efficiëntie, dus de huidige status quo is onacceptabel. Een snelle en vuile oplossing zou zijn om m1n1 de kernel in EL1 te laten laden en een PSCI-implementatie in EL2 te hosten. Hoewel dit theoretisch zou werken, zou het ook veel architecturale functies breken, zoals virtualisatie. Er moet een andere manier zijn...

Als je erover nadenkt, is m1n1 bijna als onze eigen firmware voor Apple Silicon. mBoot (voorheen iBoot) start m1n1 in EL2; m1n1 doet zijn werk en springt vervolgens naar de payload die eraan is gekoppeld. m1n1 reserveert geen geheugen voor zichzelf en heeft geen code die resident moet blijven, dus de payload is vrij om dat geheugen terug te claimen en te overschrijven.

Op productie-systemen van Asahi Linux laadt m1n1 U-Boot in plaats van de kernel direct. We doen dit om gebruik te maken van de UEFI-implementatie van U-Boot, waardoor distributies en gebruikers elke standaard UEFI-bootloader (GRUB, systemd-boot, etc.) kunnen gebruiken die ze willen. UEFI biedt ook een andere functie: Runtime Services. Net zoals de BIOS-interrupts van vroeger, bieden UEFI Runtime Services een manier voor het besturingssysteem om toegang te krijgen tot code die afkomstig is uit de systeemfirmware.

Bij het lezen van de PSCI-standaard zoals gepubliceerd door Arm, valt op dat deze de API bewust definieert zonder referentie naar een specifieke conduit, en SMC en HVC alleen als voorbeelden noemt. Als we dit breed interpreteren, kunnen we concluderen dat andere conduits door de specificatie zijn toegestaan...

Hiervoor heeft Sven gewerkt aan de implementatie van een PSCI-conduit gebaseerd op UEFI Runtime Services. Met het geheugengebied van m1n1 apart gezet, zoals andere firmware-regio's, kan de kernel terugkoppelen naar m1n1 voor PSCI-diensten, zelfs als deze op hetzelfde Exception Level draait. Sven heeft m1n1 al aangepast om zijn geheugen te reserveren en een PSCI-implementatie achter te laten, en de patches voor de kernel om dit mogelijk te maken staan al als RFC op de mailinglijst!

Stop alsjeblieft met 'Think Different' denken

Gezien het feit dat er tot voor kort geen voortgang was in de cpuidle-situatie, zou men kunnen aannemen dat een bepaalde gebeurtenis het werk in deze ruimte heeft versneld. Dat klopt.

De ARM-specificatie schrijft voor dat kernen in WFI-loops alle status moeten behouden. Dit is niet de standaardmodus op Apple Silicon. Op M1 tot en met M3 serie SoC's kan statusbehoud per kern worden geconfigureerd met behulp van chicken bits.

Om redenen die het niet waard zijn om genoemd te worden, stelt Apple nu in mBoot de chicken bits van elke kern in en vergrendelt vervolgens de registers die deze beheren, beginnend bij de M4-serie. Dit maakt ons leven iets makkelijker omdat m1n1 nu marginaal minder werk heeft, maar het betekent ook dat we het CPU-gedrag op laag niveau niet meer kunnen finetunen. Dit is vooral een probleem op de M4, aangezien het aanroepen van WFI ervoor zorgt dat de kern zijn status verliest en alles wat erop draaide crasht.

Yurkea merkte dit op tijdens het bringup-werk voor de M4 en voegde een kernel-commandlineparameter toe om het gedrag van de idle loop configureerbaar te maken. Deze parameter stelt ons in staat om de kernel te vertellen hoe hij kernen in idle loops moet parkeren, inclusief door een basis no-op loop uit te voeren. Dit voorkomt dat M4-machines crashen tijdens de vroege kernel-initialisatie, voordat onze cpuidle-driver is geladen. Zodra de driver het overneemt, slaat hij de verloren status op voordat WFI wordt uitgevoerd. De patches om dit mogelijk te maken staan al in linux-next.

Ze zullen niet stoppen met 'Think Different' denken

Apple neemt zijn reputatie op het gebied van platformbeveiliging zeer serieus. Daarom gaat er veel engineering-inspanning in functies die het exploiteren van kwetsbaarheden in hun ecosysteem onmogelijk maken voor iedereen, behalve voor de meest geavanceerde aanvallers. Een van zulke functies is de Secure Page Table Monitor, of SPTM.

Traditioneel is de kernel van het besturingssysteem direct verantwoordelijk voor het beheren van het geheugen. Dit omvat het afhandelen van geheugenallocaties, virtuele mappingen naar fysieke adressen en MMU/IOMMU-beheer. Een kwetsbaarheid in de code die verantwoordelijk is voor deze operaties zou een aanvaller toegang kunnen geven tot de volledige adresruimte van het platform. Met andere woorden: dan ben je kansloos.

Natuurlijk maakt dit code voor geheugenbeheer een zeer gebruikelijk doelwit voor aanvallers, en aangezien de taak fundamenteel onveilig is (applicaties kunnen willekeurige allocaties willen voor bijna alles), is het ongelooflijk moeilijk om dit correct af te sluiten.

Veel jaar geleden introduceerde Apple de Page Protection Layer (PPL) in XNU. PPL gebruikt de hardware-beveiligingsfuncties van Apple om pagetable-beheer op hardwareniveau te isoleren van de rest van de kernel. Dit werkt zeer goed, maar aanvallers haalden uiteindelijk hun inhaalslag en vonden manieren om binnen PPL te komen die hen volledige toegang tot het systeem gaven.

Apple heeft in het verleden soortgelijke problemen gehad met IOMobileFramebuffer. Zoals vermeld in eerdere blogposts, heeft Apple het IOMFB-probleem (grotendeels) opgelost door het in de firmware van de DCP te plaatsen, achter een IOMMU. Niets in de macOS userspace of in XNU kan dit bereiken, behalve via een gedefinieerde set IPC-functies. Geïnspireerd door deze aanpak is PPL uiteindelijk gemuteerd in SPTM. SPTM neemt PPL over en plaatst het binnen Apple's Guarded Execution Framework (GXF), een set Exception Levels die parallel lopen aan de standaard ARM64 EL1 en EL2 (er is geen GL0). GXF wordt ook geleverd met SPRR, een aangepast pagetable-permissiesysteem dat wordt gebruikt wanneer de CPU code uitvoert in GL1 of GL2.

Wanneer een modern Apple Silicon-apparaat opstart, detecteren iBoot of mBoot of de geconfigureerde boot-payload een XNU-image is. Als dat zo is, laden ze eerst SPTM in GL2. Daar stelt SPTM pagetables en geheugenbeheer in en vergrendelt de controle over deze functies tot GL2. XNU draait vervolgens en gebruikt een ander IPC-protocol om met SPTM te communiceren. Als XNU geen contact kan maken met SPTM, zal het systeem zeer vroeg in de initialisatie crashen (panic) en stoppen.

Dit is problematisch voor ons. Als we proberen XNU onder de m1n1-hypervisor te draaien, zal het crashen omdat SPTM niet is geladen. Als we mBoot configureren om m1n1 als een XNU-binary te behandelen, zal m1n1 crashen omdat het het geheugen niet op de manier kan beheren die nodig is.

Aangezien SPTM verplicht is voor XNU op M4 en hoger, werd de hypervisor op deze machines volledig onfunctioneel. We weten echter niet wanneer we moeten opgeven, wat betekent dat dit het geval was en niet meer is!

SPTM zelf is niet bijzonder speciaal. Het is een ARM64 Mach-O binary die in dezelfde preboot-directory leeft als de OS-specifieke firmware-blobs voor de diverse coprocessoren. Dat betekent dat m1n1 het theoretisch al onder de hypervisor zou kunnen laden, XNU daarnaast zou kunnen laden, en ze vervolgens beiden zou kunnen monitoren! Maar SPTM moet worden uitgevoerd in GL2 met SPRR ingeschakeld. Als we maar wisten hoe die twee werkten...

Dankzij het werk van Sven aan het reverse engineeren van SPRR en GXF, vlak nadat Asahi Linux begon, was hij onlangs in staat om de m1n1-hypervisor te leren hoe hij deze kan emuleren! Hierdoor kunnen we Apple's SPTM-blob precies laden op de manier die XNU verwacht, wat snelle chirurgie uitvoeren op de XNU-binary, deze laden, en vervolgens MMIO-toegang monitoren, net zoals we konden van M1 tot M3! De details van hoe Sven dit heeft bereikt, betekenen dat tracing op deze machines trager is, maar niet onbruikbaar. Dit stelt ons in staat om in de voorzienbare toekomst nieuwe hardware te blijven ondersteunen!

Meer voortgang met de M3!

Er is ook voortgang geboekt bij het brengen van Asahi Linux naar M3-serie machines.

De image signal processor van de webcam bleef grotendeels ongewijzigd, behalve voor één overgeslagen initialisatiebericht specifiek op de M3 Max. chaos_princess voegde ondersteuning hiervoor toe aan de Linux-driver, waarmee volledige webcamondersteuning is gerealiseerd op alle M3-serie apparaten met een ingebouwde webcam.

De ingebouwde microfoons zijn ook licht gewijzigd. Nieuw voor M3-serie apparaten is een "High Frequency" decimator die een nieuwe set coëfficiënten en een veel groter initialisatiebericht vereist. Opnieuw is het chaos_princess gelukt dit in korte tijd uit te vogelen, waardoor microfoonondersteuning is gekomen voor alle uitgeruste M3-serie apparaten.

ATCPHY — het hardwareblok dat verantwoordelijk is voor het onderhandelen van USB3, DisplayPort en Thunderbolt-verbindingen via USB Type-C poorten — is ook licht gewijzigd, wat een nieuwe reeks instellingen bij initialisatie vereist door de overstap naar TSMC's N3-procesnode.

Hoewel onze these dat Apple geen ingrijpende architecturale wijzigingen zou maken puur om het gemak van de wijziging, grotendeels stand heeft gehouden, zijn we natuurlijk toch tegen een paar van dergelijke wijzigingen aangelopen...

Alle M1 tot en met de basis M3-serie apparaten gebruikten een Apple-specifieke Texas Instruments USB-poortcontroller genaamd CD3217 (of ACE2). Deze bevindt zich op de I2C-bus en onderhandelt met USB-apparaten wanneer deze worden ingeplugd. Vanaf de M3 Pro/Max is Apple overgestapt op ACE3. ACE3 gebruikt in plaats daarvan de SPMI-bus, wat meer reverse engineering vereiste. Dankzij de gecombineerde inspanningen van mildsunrise en chaos_princess hebben we ontdekt dat ACE3 vrijwel dezelfde registerset heeft als CD3217, alleen verpakt in een SPMI-interface in plaats van aangesproken via I2C. Zowel de SPMI-interface als ACE3 zelf werken nu in Asahi Linux, waardoor USB 3.0 en Thunderbolt-ondersteuning is gekomen voor alle M3-serie apparaten.

Een enorme wijziging die we verwachtten, was de firmware ABI voor zowel de GPU als de displaycontroller. Aangezien de firmware voor zowel AGX als DCP gekoppeld is aan een specifieke macOS-versie, hoeft Apple zich geen zorgen te maken over het stabiel houden van de interface tussen releases. Dit is een belangrijke reden waarom we specifieke macOS-versies "targeten" voor elke generatie hardware. M3-serie machines zullen targeten op de ABI gevonden in macOS 14.8.3, en ondersteuning voor DCP is nu bijna op functieniveau gelijk aan de bestaande macOS 13.5 ABI die we gebruiken voor M1 en M2!

Met al deze voortgang, bovenop de mijlpalen die al op M3 zijn bereikt, zijn we blij te kunnen aankondigen dat we bijna klaar zijn om een officiële release uit te brengen! We zullen hier in de komende weken meer over zeggen, dus blijf op de hoogte!

Vergeet M4 en M5 niet!

Niet tevreden met het alleen helpen bij M3, heeft Yureka ook gewerkt aan de bringup van M4 en zelfs vroege M5. Naast het WFI-probleem op M4, leden deze SoC's onder een brekende wijziging in de NVMe-controller-firmware van Apple in het macOS 15.x firmware-bundel. Yureka en Sven werkten samen aan het onderzoeken van de wijzigingen en het implementeren ervan in zowel m1n1 als Linux, zodat we nu werkende NVMe hebben op M4 en M5! Yureka is er ook in geslaagd om PCIe in een staat te krijgen waarin apparaten op de bus kunnen worden geënumereerd door Linux, en loste een probleem op dat ervoor zorgde dat Linux vlak na het opstarten crashte wanneer er meer dan één CPU-kern was ingeschakeld. Er werkt nog niet veel meer op M4 en M5, dus we zijn nog niet helemaal klaar om ze in de Asahi Installer te activeren, maar zoals altijd zullen we hier op termijn meer over zeggen.

Desktopvideo is lastig

Vorige keer konden we preliminaire ondersteuning aankondigen voor de Apple Video Decoder, of AVD. Dit hardwareblok versnelt H.264 (AVC), H.265 (HEVC) en VP9 videodecodering op M1 en M2, naast AV1-decodering op M3-machines en hoger. Sindien is de AVD-ondersteuning verder verfijnd door sofus, waarbij AVC, HEVC en VP9 nu grotendeels betrouwbaar werken op alle machines die door Asahi Linux worden ondersteund!

We zijn nu op het punt gekomen waarop we desktop-integratie overwegen, en dat is waar het lastig wordt...

De AVD-hardware is fundamenteel stateless, wat betekent dat het alleen een gecodeerd frame neemt en dit omzet in een videobuffer. De hardware doet geen bitstream-parsing, geen tracking van decodingsessies of enig ander beheer van de decoding-pipeline. Dit leent zich goed voor de V4L2 Stateless API, die is ontworpen met zulke decoders in gedachten. Hoewel deze API meer dan 10 jaar geleden in de upstream kernel is beland, is de userspace traag geweest in het adopteren ervan, buiten gespecialiseerde software voor embedded apparaten. GStreamer heeft basisondersteuning voor V4L2 Stateless, maar FFmpeg (en alles wat daarvan gebruikmaakt) doet dat niet zonder out-of-tree patches. Software voor de desktop, zoals webbrowsers, heeft zich historisch gericht op VA-API, NVDEC en VDPAU. Recentelijk is de focus op de desktop verschoven naar Vulkan Video. Hierdoor is V4L2 Stateless effectief verlaten voordat het voor desktopsoftware überhaupt van start kon gaan.

Alle hoop is echter niet verloren. VA-API is inmiddels bijna universeel in desktopsoftware door de adoptie door zowel AMD als Intel voor hun video-acceleratiehardware. Om te voorkomen dat V4L2 Stateless hardware onbruikbaar is met dergelijke software, heeft Bootlin een vertaallaag van VA-API naar V4L2 Stateless geschreven. Helaas is dit al een tijd geleden verlaten en bouwt het niet meer zonder patches, maar sofus heeft het geforkt en in een werkende staat gebracht voor AVD. Met deze vertaallaag geïnstalleerd en een omgevingsvariabele ingesteld voor de loginsessie, is software die VA-API ondersteunt nu in staat om AVD te gebruiken voor het versnellen van videodecodering! Dit wordt nog niet standaard meegeleverd in Fedora Asahi Remix, en zal niet werken met de video-decoding sandbox van Firefox, maar we hopen snel iets te hebben dat we kunnen distribueren.

De weg naar direct scanout

Het traditionele voordeel van hardware-versnelde videodecodering is de vermindering van de CPU-belasting. Hoewel dit alleen al enorm belangrijk is, zijn er andere plekken waar stroom en tijd verloren gaan tijdens videodecoding. Ten eerste moet de CPU de gedecodeerde framedata kopiëren naar het GPU-geheugen. De GPU moet dat frame vervolgens in de scene componeren zoals aangegeven door de compositor. De uiteindelijke gerenderde scene moet vervolgens worden gekopieerd naar het geheugen van de displaycontroller, en de displaycontroller moet worden geprogrammeerd om de scene te scannen (scan out). Dit alles moet gebeuren op de framerate van de afgespeelde video.

We kunnen dit beter doen. Het DMA-subsyteem van Linux ondersteunt het delen van geheugenregio's tussen meerdere apparaten. In deze context stelt het ons in staat om de meerdere kopieën van dezelfde framebuffer-data van de ene regio naar de andere te elimineren. Dit werkt echter alleen als alle hardwareblokken in de keten hetzelfde framebuffer-formaat ondersteunen. En hier wordt het ingewikkeld.

Framebuffers komen voor in allerlei formaten en maten. Videodata wordt bijvoorbeeld bijna altijd opgeslagen en verzonden in een semi-planair Y’CbCr-formaat, geïnspireerd door de analoge video-opslag- en uitzendstandaarden uit de 20e eeuw. Daarnaast gebruikt grafische hardware bijna altijd een vorm van gespecialiseerde adressering. Pixels staan niet "naast" elkaar in het geheugen, maar zijn tiled om cache-misses en andere prestatieproblemen te verminderen. Bovendien zijn framebuffers vaak gecomprimeerd, wat de geheugenvoetafdruk en de druk op de bus verder verlaagt.

Kortom: het elimineren van framebuffer-kopieën tussen hardwareblokken is niet eenvoudig. Elk hardwareblok moet het eens zijn over het pixelformaat van de framebuffer, de adresseringsmodus en elke toegepaste compressie. Als ze het hier niet over eens kunnen worden, moeten kopieën en conversies in software worden gedaan.

Men zou zich kunnen afvragen waarom zulke "gedeelde" framebuffers niet gewoon kunnen worden gemaakt met "ruwe" pixeldata. Denk aan een 1920x1080 framebuffer met ruwe 8-bit ARGB-pixeldata. Dat is net iets meer dan 66 MiB aan data. Bij 4K loopt dit op tot net onder de 214 MiB. Zelfs zonder de extra straf van kopieën is het lezen en schrijven van zoveel data bij 30, 60, 165 of zelfs 240 frames per seconde een enorme belasting voor de geheugenbus en dus een enorm stroomverbruik. Zelfs als we op een wonderbaarlijke manier een oneindig performante en efficiënte geheugenbus hadden, zou elk hardwareblok in de keten nog steeds genoeg lokale cache of RAM buiten de bus moeten hebben, evenals de rekenkracht om zo'n volume aan data te verwerken. Dit is onhaalbaar.

Gelukkig zijn hardwareleveranciers het hiermee eens, en de meeste "families" van displayhardware lossen dit probleem op door ondersteuning te implementeren voor dezelfde adresserings- en compressieschema's. Hierdoor kunnen hun 3D-engines, displaycontrollers en video-accelerators geheugenefficiënte framebuffers delen zonder eigen massieve lokale caches te hebben of constant de geheugenbus te belasten.

In Linux declareert elke driver welke formaten hij ondersteunt, waarna verschillende delen van de softwarestack onderhandelen en overeenkomen over een gemeenschappelijk formaat voor gedeelde buffers. Gelukkig voor ons koos Apple er hier niet voor om te verschillend te denken. Nou ja, grotendeels.

Apple-hardware gebruikt twee hoofdformaten voor adressering en compressie: AGX (genoemd naar de GPU) en Interchange.

Terwijl het AGX-formaat exclusief binnen AGX zelf wordt gebruikt, wordt het Interchange-formaat ook ondersteund door DCP en AVD. In macOS maakt dit de directe scanout van framebuffers vanuit zowel AVD als AGX mogelijk, waardoor Quartz (de macOS-compositor) er opportunistisch voor kan kiezen om in veel alledaagse scenario's bijna niets te doen. Als er een video wordt afgespeeld en er verder niets gebeurt, kan de GPU volledig worden uitgeschakeld en hoeft de compositor er alleen maar op te letten dat DCP nieuwe frames weergeeft zodra AVD ze genereert. Als een game of applicatie in fullscreen staat, kan de compositor simpelweg het adres van de eigen framebuffer van die applicatie aan DCP doorgeven en al zijn eigen rendering-activiteiten uitschakelen. Het goede nieuws is dat we nu goed op weg zijn om dit in Asahi Linux te kunnen repliceren!

Dankzij het grondwerk van Alyssa en Lina had de AGX-driver al basisondersteuning voor Apple's Interchange framebuffer-formaat; het was alleen nog niet aangesloten. Oliver Bestmann en ik hebben ons aangeboden om Interchange-ondersteuning in de DCP kernel-driver te activeren, evenals in zowel de Asahi als Honeykrisp Mesa-drivers. Samen met het werk dat al is verricht om Y’CbCr en overlay plane-ondersteuning naar DCP te brengen, heeft dit de weg vrijgemaakt voor directe scanout van AGX-gerenderde framebuffers naar DCP! AVD-ondersteuning is in aantocht; sofus onderzoekt momenteel de mogelijkheid om Interchange-formaat buffers uit te voeren.

Hoewel dit fantastisch nieuws is, zijn we nog niet klaar om dit aan gebruikers te leveren. Kwin, de compositor voor KDE Plasma, beschouwt onze setup als "multi GPU" omdat AGX en DCP aparte hardwareblokken zijn. Hierdoor is directe scanout via de DMA-BUF API momenteel volledig uitgeschakeld. Kwin-ontwikkelaars werken actief aan het verbeteren van deze situatie, en directe scanout op setups zoals die van ons zou vanaf Plasma 6.8 mogelijk kunnen worden ingeschakeld!

Diverse upstreaming

Zoals altijd blijven we patches upstreamen. De voortgang is de afgelopen maanden vertraagd, en het lijkt misschien alsof we zelfs achteruit zijn gegaan. Dit komt echter alleen omdat we de meeste dingen al hebben geüpload! Het meeste wat overblijft is ofwel enorm werk dat we nog niet kunnen upstreamen (bijv. GPU, DCP) of nieuwe functies waar we alleen aan hebben kunnen werken omdat we het grootste deel van de upstream-backlog hebben weggewerkt. Desalniettemin hebben we nog wat kleine dingen in de tree staan. Onlangs geüploaden patches bevatten een aantal I2S-perifere wijzigingen gerelateerd aan het functioneel maken van speakersafetyd, de Devicetree-patches die de SMC-gebaseerde hwmon-driver mogelijk maken, en natuurlijk fixes voor alle SMC-firmware interface-wijzigingen die zijn geïntroduceerd door macOS 27.