MacBookAir6,x and 7,x (Mid-2013/Early-2014 and Early-2015/2017) support

[newperson1746]

Hi, I have this very peculiar Macbook Air:

$ sudo dmidecode | grep -i mac
        MCE (Machine check exception)
        MCA (Machine check architecture)
    Product Name: MacBookAir7,2
    Family: Mac
    Product Name: Mac-937CB26E2E02BB01
    Version: MacBookAir7,2
    Version: Mac-937CB26E2E02BB01

I believe that MacBook Air 6,2 (2014) also has spi input devices, but you normally don't see them as unless apple_set_os detects macOS, it exposes the USB interface of the input devices. Touchpad and Keyboard work in USB mode (applespi outputs something about device is in usb mode when booted normally via uefi grub) but using apple_set_os.efi to trick the efi into thinking its macOS results in the raw spi device being exposed. It uses AppleIntelLPSS and AppleIntelHSSPI just like the normal MacBook8,1. It has a Wildcat Point GSPI Controller with identical pci id's to the MacBook8,1:

$ sudo lspci -nnk | grep -i spi
00:15.4 Serial bus controller [0c80]: Intel Corporation Wildcat Point-LP Serial IO GSPI Controller #1 [8086:9ce6] (rev 03)
    Subsystem: Intel Corporation Wildcat Point-LP Serial IO GSPI Controller [8086:9ce6]
    Kernel driver in use: pxa2xx_spi_pci
    Kernel modules: spi_pxa2xx_pci

$ cat /etc/initramfs-tools/modules
# List of modules that you want to include in your initramfs.
# They will be loaded at boot time in the order below.
#
# Syntax:  module_name [args ...]
#
# You must run update-initramfs(8) to effect this change.
#
# Examples:
#
# raid1
# sd_mod

spi_pxa2xx_platform
spi_pxa2xx_pci
applespi

Some progress does occur when booting:

$ sudo dmesg | grep -i spi
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-15-generic.efi.signed root=UUID=fe6baa00-1e02-4a13-bd0f-81652cd6024e ro acpi_osi=Darwin i915.modeset=1 pti=off applespi.debug=0x7 applespi.dyndbg=+p irqpoll
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-15-generic.efi.signed root=UUID=fe6baa00-1e02-4a13-bd0f-81652cd6024e ro acpi_osi=Darwin i915.modeset=1 pti=off applespi.debug=0x7 applespi.dyndbg=+p irqpoll
[    1.486690] applespi: loading out-of-tree module taints kernel.
[    1.488824] applespi: module verification failed: signature and/or required key missing - tainting kernel
[    5.079223] applespi: SPI settings: spi_cs_delay=10 reset_a2r_usec=10 reset_rec_usec=10
[    5.136477] input: Apple SPI Keyboard as /devices/pci0000:00/0000:00:15.4/pxa2xx-spi.0/spi_master/spi0/spi-APP000D:00/input/input10
[    5.136576] input: Apple SPI Touchpad as /devices/pci0000:00/0000:00:15.4/pxa2xx-spi.0/spi_master/spi0/spi-APP000D:00/input/input11
[    5.136723] applespi: spi-device probe done: spi-APP000D:00

However, it does not appear to find any master spi controllers or the like. Xinput shows some shenanigans too:

$ xinput
⎡ Virtual core pointer                      id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ Mitsumi Electric Apple Optical USB Mouse  id=10   [slave  pointer  (2)]
⎜   ↳ Apple SPI Touchpad                        id=14   [slave  pointer  (2)]
⎣ Virtual core keyboard                     id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Power Button                              id=6    [slave  keyboard (3)]
    ↳ Video Bus                                 id=7    [slave  keyboard (3)]
    ↳ Power Button                              id=8    [slave  keyboard (3)]
    ↳ Sleep Button                              id=9    [slave  keyboard (3)]
    ↳ Logitech USB Keyboard                     id=11   [slave  keyboard (3)]
    ↳ Logitech USB Keyboard                     id=12   [slave  keyboard (3)]
    ↳ Apple SPI Keyboard                        id=13   [slave  keyboard (3)]

But, they don't work on any part of linux boot or after, except on the grub screen.xinput test 13 and xinput test 14 do nothing.

Amusingly, the keyboard backlight works without any additional work (it turns on during boot.) Using apple_set_os.efi is beneficial since it unlocks some thunderbolt functionalities in linux that normally are reserved for macOS, and it would be nice to get it to work on one more device, and there is also the added benefit of a few more EFI features that work with this trick.

Thanks for doing this awesome work on this driver! It has helped so many people with their new devices, and I hope we can get this to work on this peculiar Air.

[roadrunner2]

Given the dmesg and other info above, it looks like the SPI interface is properly enabled (and the USB interface disabled), so that's good. And especially the fact that the keyboard backlight is working is encouraging (does the caps-lock light also work, btw?).

Now to look at the keyboard and touchpad, can you enable debugging in the driver of the keyboard inputs:

echo 0x100 | sudo tee /sys/module/applespi/parameters/debug

And let me know what you see in dmesg when you type on the keyboard (there should basically be an applespi "Keyboard Event" packet dump for every key action) - this should let us know whether the driver is receiving and processing keyboard events or not.

Assuming keyboard events are being received, the next thing to do might be to take a look at libinput's info (assuming you're setup is using libinput): does running libinput-debug-events show any keyboard or touchpad activity?

[newperson1746]

About the backlight: it actually worked in spi mode even before I did anything with applespi (even back when I ran 16.04 with kernel 4.10, the backlight worked even though actual keyboard input didn't.) This is apparent after looking at /sys/class/leds:

/sys/class/leds$ ls
input17::capslock  input17::kana     input17::scrolllock  smc::kbd_backlight
input17::compose   input17::numlock  input4::capslock     spi::kbd_backlight

echo'ing values to the brightness file in spi::kbd_backlight does nothing. echo'ing values to the brightness file in smc::kbd_backlight DOES work perfectly (range of 0-255 brightness levels, nice!) So it appears here that the keyboard backlight is controlled by applesmc, and I confirmed this theory by booting without applespi. Keyboard backlight remains adjustable, while the spi::kbd_backlight device disappears. This might be a key difference between the Macbook8,1 and MacBookAir7,2: the keyboard backlight is controlled by applesmc in MacBookAir, while it is controlled by bcm5974 on MacBook8,1? That's why there's the spi backlight device I assume.

I am not sure how to test the caps lock key on the keyboard, I tried poking around in /sys/class/leds/input4::capslock but to no avail. (input17 is my usb keyboard)

Anyways, so I went ahead and ran the command exactly as you said.

$ echo 0x100 | sudo tee /sys/module/applespi/parameters/debug
0x100

I then did $ dmesg -w for a tail -f like experience (automatically updates as syslog does) and hit keys on the keyboard (I tried every single one.) No packet dumps appeared. After mashing a bunch of keys, here's all there is on applespi:

$ sudo dmesg | grep -i applespi
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-15-generic.efi.signed root=UUID=fe6baa00-1e02-4a13-bd0f-81652cd6024e ro acpi_osi=Darwin i915.modeset=1 pti=off applespi.debug=0x7 applespi.dyndbg=+p
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-15-generic.efi.signed root=UUID=fe6baa00-1e02-4a13-bd0f-81652cd6024e ro acpi_osi=Darwin i915.modeset=1 pti=off applespi.debug=0x7 applespi.dyndbg=+p
[    1.566145] applespi: loading out-of-tree module taints kernel.
[    1.567789] applespi: module verification failed: signature and/or required key missing - tainting kernel
[    1.605546] applespi: SPI settings: spi_cs_delay=10 reset_a2r_usec=10 reset_rec_usec=10
[    1.666454] applespi: spi-device probe done: spi-APP000D:00

It appears like it is not receiving the packets. Interesting... Any thoughts?

Also, thank you a lot for taking time to write a driver for proprietary hardware. A lot of people appreciate you, and it is wonderful that you took the time to do it. Thanks!

FYI: System is Ubuntu 18.04 development branch, stock kernel 4.15.0-15 from ubuntu.

[roadrunner2]

Thanks. So, no keyboard packets. Hmm: can you turn on a bit more debugging:

echo 0xd00 | sudo tee /sys/module/applespi/parameters/debug

This will also print the interrupts received and dump any unknown packets.

[newperson1746]

Yup:

$ echo 0xd00 | sudo tee /sys/module/applespi/parameters/debug
0xd00

$ dmesg | grep -i spi
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-15-generic.efi.signed root=UUID=fe6baa00-1e02-4a13-bd0f-81652cd6024e ro acpi_osi=Darwin i915.modeset=1 pti=off applespi.debug=0x7 applespi.dyndbg=+p
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-15-generic.efi.signed root=UUID=fe6baa00-1e02-4a13-bd0f-81652cd6024e ro acpi_osi=Darwin i915.modeset=1 pti=off applespi.debug=0x7 applespi.dyndbg=+p
[    1.566145] applespi: loading out-of-tree module taints kernel.
[    1.567789] applespi: module verification failed: signature and/or required key missing - tainting kernel
[    1.605546] applespi: SPI settings: spi_cs_delay=10 reset_a2r_usec=10 reset_rec_usec=10
[    1.664089] input: Apple SPI Keyboard as /devices/pci0000:00/0000:00:15.4/pxa2xx-spi.0/spi_master/spi0/spi-APP000D:00/input/input4
[    1.665280] input: Apple SPI Touchpad as /devices/pci0000:00/0000:00:15.4/pxa2xx-spi.0/spi_master/spi0/spi-APP000D:00/input/input5
[    1.666454] applespi: spi-device probe done: spi-APP000D:00

just mashed all the keys... should I reboot to activate something I missed? Maybe a Linux 4.17-git kernel? Also, last couple of lines from boot, maybe the applesmc has something to do, unlikely...

$ dmesg
[   38.532660] Bluetooth: RFCOMM TTY layer initialized
[   38.532664] Bluetooth: RFCOMM socket layer initialized
[   38.532670] Bluetooth: RFCOMM ver 1.11
[   39.670838] rfkill: input handler disabled
[ 1028.261246] applesmc: send_byte(0x40, 0x0300) fail: 0x40
[ 1028.261247] applesmc: F0Mn: write data fail

[roadrunner2]

Wow, no interrupts. Can you check your DSDT and see what GPE it declares for the keyboard/touchpad? (look for the APP000D device, and then the _GPE attribute in there) - alternatively, apply the following patch to the driver and check the dmesg output after (re)loading it:

--- a/applespi.c
+++ b/applespi.c
@@ -1678,6 +1678,7 @@ static int applespi_probe(struct spi_device *spi)
                       acpi_format_exception(result));
                return -ENODEV;
        }
+       pr_info("GPE: %llx\n", gpe);
        applespi->gpe = (int)gpe;

        result = acpi_install_gpe_handler(NULL, applespi->gpe,

Next, given the GPE, show me the output of

cat /sys/firmware/acpi/interrupts/gpe<gpe-num-from-above-in-hex>

(on my system, the GPE is 0x17, btw).

[newperson1746]

Yup, thankfully I have a hackintosh background, so I speak ACPI and AML now :) I extracted it from the DSDT. My steps:

/sys/firmware/acpi/tables$ sudo apt install acpica-tools
/sys/firmware/acpi/tables$ sudo cp DSDT ~/Desktop
/sys/firmware/acpi/tables$ cd ~/Desktop
~/Desktop$ sudo chmod 777 DSDT
~/Desktop$ iasl -da -dl DSDT
~/Desktop$ grep -A 8 -B 8 -ira APP000d DSDT.dsl
                    Return (ConcatenateResTemplate (RBUF, DBUF))
                }
            }

            Scope (\_SB.PCI0.SPI1)
            {
                Device (SPIT)
                {
                    Name (_HID, EisaId ("APP000D"))  // _HID: Hardware ID
                    Name (_CID, "apple-spi-topcase")  // _CID: Compatible ID
                    Name (_DDN, "apple-spi-topcase")  // _DDN: DOS Device Name
                    Name (_GPE, 0x1C)  // _GPE: General Purpose Events
                    Name (_UID, 0x02)  // _UID: Unique ID
                    Name (_ADR, 0x00)  // _ADR: Address
                    Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
                    {
                        If (OSDW ())

GPE=0x1C I would gladly provide anything from the MacBookAir if you need. Anything I can do to help.

EDIT: also looked at a dsdt from a MacBookAir6,2: https://github.com/Ramalama2/Apple/blob/master/1.%20Tables/MacBookAir6.2/DSDT.dsl

It also has the same GPE and has the spi device defined in exactly the same way (not surprising, since 2014 is a processor bump of 2013 (same id of MacBookAir6,x), and 2017 is a processor bump of 2015 (same id of MacBookAir7,2 since only 13 inch is available.) 6,x is Haswell, 7,x is Broadwell. A fix for this would fix 4 generations and 4 years' worth of MacBook Airs, so if this gets worked out all those would work. Just FYI.

[roadrunner2]

What is the output of

cat /sys/firmware/acpi/interrupts/gpe1C

[newperson1746]

Sorry about the delay! Here:

/sys/firmware/acpi/interrupts$ cat gpe1C
       1     STS enabled      unmasked

[roadrunner2]

Thanks. Hmm, so the GPE is enabled, but apparently not being triggered (well, it was only triggered once, so obviously not on each keyboard/touchpad event, like we expect). As this point I'm not really sure how to proceed. We could in theory re-introduce polling of the keyboard/touchpad, but for various reasons I really don't think we want to go there. Instead, the question is how to get this interrupt/GPE working.

Btw., does the output (or anything else) change if you manually clear the status?

echo clear | sudo tee /sys/firmware/acpi/interrupts/gpe1C
cat /sys/firmware/acpi/interrupts/gpe1C

[newperson1746]

I've been busy, sorry... The only change appears to be from:

/sys/firmware/acpi/interrupts$ cat gpe1C
       1     STS enabled      unmasked

To:

/sys/firmware/acpi/interrupts$ echo clear | sudo tee gpe1C
clear
/sys/firmware/acpi/interrupts$ cat gpe1C
       1         enabled      unmasked

dmesg shows no change, xinput still doesn't show any data from either SPI device, and dmesg shows no change. This is really a head-scratcher. I can patch the ACPI tables if necessary, I've already done so on an older Mac on Ubuntu to fix thunderbolt (with the _OSI call patching to report Darwin every time.)

Knowing that the interrupts are over GPIO, maybe we need to enable them via a special method in the ACPI tables?

FYI the MacBookAir6,2 tables in the github link are identical to mine, so that's a good way to look at the DSDT if we need to. Sorry if I'm dragging this too far, it's a lot, I know, and I appreciate your work.

Also, from reading applespi.c directly, I noticed this:

* The keyboard and touchpad controller on the MacBook8,1, MacBook9,1 and
 * MacBookPro12,1 can be driven either by USB or SPI. However the USB pins
 * are only connected on the MacBookPro12,1, all others need this driver.
 * The interface is selected using ACPI methods:
 *
 * * UIEN ("USB Interface Enable"): If invoked with argument 1, disables SPI
 *   and enables USB. If invoked with argument 0, disables USB.
 * * UIST ("USB Interface Status"): Returns 1 if USB is enabled, 0 otherwise.
 * * SIEN ("SPI Interface Enable"): If invoked with argument 1, disables USB
 *   and enables SPI. If invoked with argument 0, disables SPI.
 * * SIST ("SPI Interface Status"): Returns 1 if SPI is enabled, 0 otherwise.
 * * ISOL: Resets the four GPIO pins used for SPI. Intended to be invoked with
 *   argument 1, then once more with argument 0.
 *
 * UIEN and UIST are only provided on the MacBookPro12,1.

Later, I noticed this:

static struct applespi_tp_info applespi_default_info = {
    -5087, 5579, -182, 6089
};

From my amateur knowledge of C, I think you are using a conditional statement to determine model info from DMI like this pseudocode:

if {dmi_matches(MacBookPro13,2, MacBookPro13,1, etc)}
then 
applespi_info = specific-info-about-each-one
else 
applespi_default_info = default-info

It looks like you are special-casing each model that needs specific info to work, and using the default values (that are known to work) for all the other models.

Going back to the first copy and pasted comment, it says that only MacBookPro12,1 has both spi and usb interfaces. The MacBook Airs since 2013 have both spi and usb interfaces, very much like the 12,1 Macbook Pro (and we know because my trackpad and keyboard work without apple_set_os and appear as USB devices.) Since the MacBookPro models are special-cased, perhaps a quick fix in the code would help? As to that I don't know sadly how.

MacBookPro12,1 is not special-cased, so how is the logic in the code flowing for the MacBook Air? Maybe finding out how the Air goes through the code would help us understand what needs to be fixed? Maybe seeing how each dmi statement returns for the Air would help see what code ends up being run for the Air. Just suggestions.

Lastly, I saw that you forked this repo and you updated it more recently that cb22. Should I clone and compile your fork instead? I am currently using cb22 in my DKMS script and his version is the one I'm working with.

I appreciate your work, truly. You have done something awesome, thanks for the driver and sorry to ask so many questions!

[l1k]

@newperson1746: That code comment that the MBP12,1 is the only machine with both, USB and SPI, was written by me and is clearly erroneous. I thought that's the case but I recently came across a video by Louis Rossmann which proves that MacBook Airs also had this. Feel free to submit a pull request rectifying the incorrect code comment.

Could you provide a little more detail which Thunderbolt functionalities are enabled by apple_set_os?

[l1k]

The MBA6,2 DSDT linked above seems to be missing the device properties and _CRS resources for the SPIT device (clock etc), I guess we need to define defaults for this case. :-(

[newperson1746]

Yeah, that's what I thought too... About the thunderbolt functionalities: I came across this article here that details the DSDT's checks. I can verify that not setting acpi_osi=Darwin will result in the thunderbolt controller being powered down by Linux (or at least, I can't hotplug the thunderbolt --> ethernet adapter, I have to have it plugged in before GRUB2 efi.) Setting acpi_osi=Darwin enables thunderbolt hotplug and I can hotplug the ethernet adapter as I wish. Thunderbolt also keeps on working after sleep.

Should the PR go to cb22/macbook12-spi-driver or roadrunner2/macbook12-spi-driver? roadrunner's fork was updated more recently.

[roadrunner2]

@newperson1746 Sorry, I missed your edits. Regarding the code and the applespi_default_info: those values are "just" the range of x/y values the touchpad reports - while we'll quite possibly need to figure out those for the macbook air (though they well might be the same as those for the macbook's), we don't need to worry about them until we get the interrupt/gpe issue worked out.

Regarding the repo's: my clone is mainly for two things, 1) the touchbar driver, and 2) things that aren't ready/meant to be pulled into the main repo. So please submit your PR to cb22's repo.

[l1k]

@newperson1746: Could you add a debug printk to applespi's ->probe routine to output the max_speed_hz of the SPI device? Since there are no device properties in the ACPI namespace on the MBA6, I'd expect max_speed_hz to be zero. However acpi_register_spi_device() bails out if it's zero. So why is the driver probing at all? Maybe on the MBA7 those device properties are present? Could you upload an acpidump of your MBA7 somewhere?

If you're talking to the device with the wrong clock, it wouldn't be surprising if the GPE never fires.

As for Thunderbolt, since commit torvalds/linux@7bc5a2b it should no longer be necessary to pass acpi_osi=Darwin on Macs as that's the default. Quite the opposite, one has to turn the Darwin OSI string off if one doesn't want to use Thunderbolt. Also, the ACPI OSI protocol is a separate thing from the EFI apple_set_os protocol. I'm not aware that the latter has any influence on Thunderbolt. However I agree that it would be good to have MBA support in the applespi driver.

[newperson1746]

Here are all the ACPI tables, including the dynamic ones (from /sys/firmware/acpi/tables and /sys/firmware/acpi/tables/dynamic) and disassembled in the ./disassembled folder using iasl -da -dl. I am not too great at writing C, so could you give me a hand in adding printk? Sorry to have gone this far in problem-reporting without having real C experience... AllACPI.zip

I think I confused apple_set_os and acpi_osi=Darwin. You are right about not needing to pass OSI anymore. apple_set_os basically enables the discrete gpu in dual-gpu macbook pros, enables the raw battery protocol (instead of the acpi-compliant one, but it works in linux nonetheless) and switches the keyboard + trackpad (bcm5974) into SPI mode. Also note that the keyboard backlight turns on and is controllable as an led with range 0-255 in /sys/class/leds/smc::kbd_backlight, even without applespi loaded (applesmc must control the backlight through the SMC, and not the actual keyboard interface.)

Well, it's great to see great people working on a great driver. Thank you for your support.

[roadrunner2]

Thanks for the DSDT - that looks good, i.e. it contains the expected _DSM method for the spi device, from which we extract various parameters for the SPI driver. And that explains why the applespi driver loads fine.

It's not really necessary now, but just for kicks, here is basically the patch @l1k was asking for:

--- a/applespi.c
+++ b/applespi.c
@@ -1638,6 +1638,16 @@ static int applespi_probe(struct spi_device *spi)
        if (result)
                return result;

+       {
+               struct acpi_device *adev = ACPI_COMPANION(&applespi->spi->dev);
+               const union acpi_object *o;
+
+               if (!acpi_dev_get_property(adev, "spiSclkPeriod", ACPI_TYPE_BUFFER, &o))
+                       pr_info("spiSclkPeriod: %llu\n", *(u64 *)o->buffer.pointer);
+               else
+                       pr_warn("Property spiSclkPeriod not found\n");
+       }
+
        /* set up touchpad dimensions */
        applespi->tp_info = *(struct applespi_tp_info *)
                        dmi_first_match(applespi_touchpad_infos)->driver_data;

Compiling and loading the new driver should result in a 'spiSclkPeriod: 125' message in dmesg.

[newperson1746]

Hi everyone, It's been a while. I wanted to see how everything was in the current state of the driver. I am using the exact same laptop with the exact same Ubuntu install with the 4.18.3 kernel and applespi as a dkms module, exactly like it was a couple months ago. I want to help out (now that I have some time!)

The log from a boot with the spi controller enabled with apple_set_os:

https://pastebin.com/bSe05QLx

The Caps Lock messages then loop along with the -110 errors. How should I begin?

[roadrunner2]

Sorry for the delay. First of all: what version exactly of applespi are you running?

Next, either something's changed or I misread things last time, because your latest log seems to indicate the GPE is being received and handled - great! Though to confirm, could you enable a few more debug bits? I'm guessing you're booting with something like applespi.debug=0xf on the kernel command line? If so, then please try applespi.debug=0xff - this should also explicitly log whenever our GPE handler is invoked.

Finally, the problem now appears to be that the SPI device (keyboard/touchpad) is not responding. I see several potential reasons for this:

• the clock frequency is too high (though I think we are getting it correctly from the DSDT)
• additional delays are necessary between the different transfers (we can insert/increase them and see if it helps)
• the keyboard/touchpad SPI interface is not properly enabled (but we do call SIEN ACPI method for this)

To double check the SIEN call, can you apply the following patch and then send me the dmesg output after reloading/rebooting?

--- a/applespi.c
+++ b/applespi.c
@@ -799,6 +799,7 @@ static int applespi_enable_spi(struct applespi_data *applespi)

        /* check if SPI is already enabled, so we can skip the delay below */
        result = acpi_evaluate_integer(applespi->sist, NULL, NULL, &spi_status);
+       pr_info("SIST before: res=%d sts=%llu\n", result, spi_status);
        if (ACPI_SUCCESS(result) && spi_status)
                return 0;

@@ -809,6 +810,9 @@ static int applespi_enable_spi(struct applespi_data *applespi)
                return -ENODEV;
        }

+       result = acpi_evaluate_integer(applespi->sist, NULL, NULL, &spi_status);
+       pr_info("SIST after: res=%d sts=%llu\n", result, spi_status);
+
        /*
         * Allow the SPI interface to come up before returning. Without this
         * delay, the SPI commands to enable multitouch mode may not reach