This is a (currently WIP) driver for Apple's custom HID-over-SPI transport (nothing to do with the new [[ https://learn.microsoft.com/en-us/windows-hardware/drivers/hid/hid-over-spi | HID-over-SPI Microsoft spec]], completely bespoke and predates it by half a decade).
First, a history lesson to understand which models this is for. Apple MacBooks have a "fun" history with HID transports…
- initially: the input controller is just hanging off of good old USB
- 2015, MacBookPro12,1: the input controller gained an SPI connection directly to the Intel SoC, but USB is still supported, an ACPI call switches the controller to start working on SPI instead of USB **← atopcase_acpi included here is for this**
- 2016-2018: the input controller only has an SPI connection **← atopcase_acpi included here is for this**
- 2018-2020: the input controller is no longer connected directly to the SoC and instead input goes through the Apple T2 security chip which apparently presents a custom USB host controller interface, see [[ https://github.com/t2linux/apple-bce-drv | apple-bce-drv for Linux with its "vhci" ]]
- 2020-2021: the input controller is directly connected to the Apple M1 series SoC **← later someone will be able to write an atopcase_fdt attachment for this**
- 2022-now: the input controller is now *inside* the Apple M2 series SoC, so instead of a bus like SPI, a simple FIFO called "dockchannel" is used… with a complex completely new HID transport over it
---
Sadly I no longer have access to the machine I've been testing this on (a MacBookPro12,1).
Now that the prerequisites have landed (thanks @wulf), I am publishing the driver in its current state—basically as it was when I was still testing it, just with more comments and ifdefs, so it should *work* at least—to get some help finishing it.
To finish this driver, I need help from two kinds of people:
- people with access to 2015-2018 (pre-T2) MacBooks for testing, with a -CURRENT install on some drive booting on that machine (message me using the discord/matrix/telegram linked on my [[ https://val.packett.cool/ | website ]] at the bottom)
- kernel experts to take a look at the code, especially to deal with the big ACPI issue here – the problem is that our device (that we probe by the ACPI id APP000D) is a **sibling** of the `spibus` under which we actually need to be, and to make that attachment-at-a-distance work I needed to hack the `acpi_pci_update_device` because it was tripping an assertion. ugh.
(and if someone is both a kernel developer and an owner of such a machine, that would be a dream :D)