macbook12-spi-driver

ah, there's also an interesting discussion in an GH issue. They reference the data sheets of the parts mentioned from an iFixit teardown. There's also discussion of disassembling the OSX driver. And here's info on how the author sniffed SPI traffic on Windows. [1] [0] https://github.com/cb22/macbook12-spi-driver/pull/1#issuecom... [1] https://github.com/cb22/macbook12-spi-driver/issues/3#issuec...

Thanks for the link to the WIP driver. Since you have a lot of experience in this area, I'm curious: 1. What's the __1e6 alignment? [0] I've never heard of that. 2. How is the driver author going about writing that driver? Some of the comments seem to allude to analyzing what the Windows driver is doing. Do you think they're disassembling the Windows driver and trying to re-implement a Linux compatible driver in C? I don't see how anyone could implement a driver like this off the bat without some data sheet or existing code to look at. Edit: thanks to people pointing out it's __le16, not __1e6. I need to change my font; even now I can barely tell the 1 and l apart. [0] https://github.com/cb22/macbook12-spi-driver/blob/master/app...

The three primary issues here are: 1) The input devices are on SPI, not USB. Apple's ACPI tables don't provide the GPIO mappings for these things via the standard mechanisms, so the chipset driver won't bind. You then still need another driver for the SPI controller, and there's an out of tree one at https://github.com/cb22/macbook12-spi-driver/ . Longer term, the kernel needs to be able to parse Apple's ACPI tables and that driver needs merging. 2) Apple's NVME hardware uses the wrong PCI device class, possibly because it's not entirely NVME compatible (trying to read 64 bits of mmio register space in one go will fail, for instance). Linux has a specific entry for the older Apple NVME devices, and that may need to be broadened. 3) Having source ID checking enabled when doing IRQ remapping results in the system hanging on boot. It's uncle