2015 Macbook testing

[theishshah]

It seems that the driver is primarily non-functional on the 2015model. The trackpad is essentially broken and (possibly random, need more testing) very few keystrokes are registering.

[cb22]

@theishshah interesting; so it was registering some keystrokes? Last I heard about the 2015 model the SPI driver wouldn't bind properly

[theishshah]

Yeah I'm not sure it seems very sporadic. It is possible that it was interpreting input from an external usb device or something, i'm not sure

[mxms0]

Under a stock linux kernel (4.11.0-rc6) with Intel LPSS modules disabled, the keyboard works again with this module on the 2015 model. However, there are a few issues. Typing is kind of slow/laggy, which could be due to systemd, but it seems unlikely. Also there are issues when typing too fast, which may be due to rollover previously mentioned. Also, trackpad doesn't work at all. It appears the data read related to trackpad is correct, but multitouch isn't properly enabled, as there's only one finger's worth of data.

[mxms0]

Update: the typing lag was due to the clock speed being set low. Bumped it up from 400kHz to the 8MHz and now typing is nice and smooth. Key-rollover issues still occur, of course. I've got the trackpad working with the rel_x and rel_y parameters passed from the device, however I'm getting no multitouch data.

[cb22]

@Maximus- interesting you say about bumping up the speed; the multitouch initialization might have to do with the issue mentioned by @roadrunner2 here.

Alternatively, the initialization packet might be difference on the 2015 model. That would need to be decoded from Windows and added to the driver.

[mxms0]

I'm trying to find those packets in the OS X kexts, and I've checked AppleHSSPIHIDDriver, AppleHSSPISupport, AppleIntelLpssDmac, and AppleIntelLpssGspi; I can't find any trace of them, but they may just be stored a bit differently in the binaries. Downloading the windows drivers now.

Also some things I'm not entirely clear on: What's the actual difference between the two machines (2015, and 2016 models)? Why does this work when all Intel LPSS-related kernel modules are disabled? Furthermore, should I care about having LPSS? Battery life seems fine under linux so far.

[roadrunner2]

@Maximus- Try the following patch to see if that fixes your mt-initialization (I'll be pushing the full proper patches in a few days): applespi-init.patch.txt Also, can you show me your DSDT (aml or dsl, patched or not)? And I presume the model is MacBook8,1?

[mxms0]

@roadrunner2 Those patches work. Multitouch is properly enabled. :-)

I have some patches to fix the key rollover issues I'll be posting soon. Good work!

Also attached is my DSDT. dsdt.dsl.txt

(Had to add txt extension to make github happy.)

[roadrunner2]

@Maximus- Thanks for the DSDT - looks like the relevant parts are the same as for the newer MacBook(Pro)'s, so that good.

[roadrunner2]

@Maximus- If you have a moment, could you per chance try out #14? In particular to verify caps-lock led now works (and of course that initialization and speed still good)

[mxms0]

@roadrunner2 Tested it out. Everything seems to be still be working on the 2015 12" Macbook. Caps lock key included :)

[roadrunner2]

@Maximus- Thanks!

[john-morton]

It's alive, it's ALIVE! I can't believe the 2015 12" 8,1 machine I'd put away in a closet for two years (awaiting all of your incredible recent efforts) is now functional. I press the letter 'A' on the keyboard and an 'A' appears on screen - insane! Likewise the track-pad, simply awesome! I'd nearly given up hope... I'm sincerely grateful and would be more than happy to assist any further 'polishing' efforts by submitting verbose logs etc (please just let me know). Further, if there's a way to buy you guys some beers over the Internet, I'm more than happy to. I haven't used this machine in angst yet but my only observation is a slight hover over the track-pad (without touching it) is being picked up and acted on. I'm not sure if this will present an annoyance in the future with the thumbs and hand-rests during typing or if it's mechanical and not a software issue etc. As others have suggested, if there's any way to avoid the DSDT modification and a means to keep up with kernel changes, that'd be the icing on the cake. Again, thank you sincerely to everyone who's contributed! John

[mxms0]

@john-morton the linux ACPI devs have proposed a fix to avoid the DSDT modification, which I've been working on (https://www.spinics.net/lists/linux-spi/msg06968.html).

[john-morton]

@Maximus- yeah, I've been following all of threads and aware of this (and looking forward to seeing what might potentially eventuate). Fingers crossed! ;)

[roadrunner2]

@Maximus- Interesting to hear you're working on something, because so am I 😃 Specifically, I am close to having something working in the applespi driver, where essentially I detect that there's no spi-device, call _DSM to get the info, and then explicitly create an spi-device from that info. While this isn't the better and more comprehensive solution in the core as discussed in the link, it would/will allow folks to use the driver right now until the core has support for this setup. I'd be curious to know what exactly you're doing, and if we should be coordinating or merging or something.

[roadrunner2]

@john-morton, @Maximus- see #29 for a solution for now (pending the better solution in the core).

[sergioabril]

Not strictly a bug related comment, I know, and sorry for that, but I came here looking for a way to start using linux on my macbook 12" 2015 properly, and I'm not sure on how to proceed with this solution. Any quick link to a guide or step-by-step read for noobs on how to compile and load this drivers/modules on an already installed debian distro (dual boot)? I'm still learning, and using an external keyboard every day it's a bit frustrating

[choelzl]

@sergioabril Add the modules "spi_pxa2xx_platform", "intel_lpss_pci" and "applespi" in the mkinitcpio.conf file. Clone this git repo and inside the folder run the following commands :

sudo make all sudo make install

then

reboot

after booting it should work if not try to run inside the cloned git repo

sudo make test

it should work without a reboot now (except if one of the commands gave you an error). If not there

[sergioabril]

@choelzl Thank you for the explanation! These are my first steps with Linux, and I really appreciate it.

I managed to make and load "applespi" after some hours learning a bit more of linux kernel and modules, and then added the "intel_lpss_pci" module aswell (note: I used modprobe, and also added them to /etc/modules just in case, since I've nothing like 'mkinitcpio.conf' anywhere).

However, I have no clue of what to do with "spi_pxa2xx_platform"; it doesn't exist as a module anywhere, and can't load it using modprobe. (I guess I should find the source, maybe on my linux-source folder, and compile it somehow?)

I guess all this is way over my linux knowledge for now... I'll keep on investigating.

But thank you again for trying 👍 (P.S. No, didn't get my keyboard working)

[choelzl]

@sergioabril what kernel and distro do you run ? mkinitcpio is used for arch, in some cases you might look for initramfs in your kernel (/etc/initramfs/initramfs.conf would be the file for example where you add the modules in that case). PS : the "spi_pxaa2xx_platform" module is present in the kernel since kernel 2.6.17 (http://cateee.net/lkddb/web-lkddb/SPI_PXA2XX.html)

[roadrunner2]

@sergioabril The spi_pxa2xx_platform module may be built in, or not build at all - run this to see:

grep PXA2XX /boot/config-`uname -r`

If you see CONFIG_SPI_PXA2XX=y then it's compiled in and you don't need to load it at all; if you get # CONFIG_SPI_PXA2XX is not set then it isn't built at all, and you'll need to either reconfigure and rebuild your kernel or just this module.

Regarding where to add the modules for the ramdisk: assuming Debian uses initramfs-tools/mkinitramfs like Ubuntu does, then you'll need to add the modules to /etc/initramfs-tools/modules.

[sergioabril]

@choelzl I'm using kernel 4.9.0-Kali4-amd64 (Debian 4.9.25-1kali1)

I tried what @roadrunner2 said and the message I got was "CONFIG_SPI_PXA2XX is not set", so I decided to build just the module (after trying to rebuild the hole kernel, I thought it twice).

Apparently, now I have the three modules built and loaded, and all of them appear when I type lsmod. I also added them to the /etc/initramfs-tools/modules and called update-initramfs -u However, keyboard and trackpad are not working yet.

The only message the dmesg throws related to these three modules, is spi_pxa2xx_platform: loading out-of-tree module taints kernel

Where should I be looking for errors or possible problems?

P.S: I also tried adding intremap=nosid to grub, but nothing happened, so I removed it again.

[choelzl]

@sergioabril Does the applespi driver attach it self to the device ? Does your dmesg give any hint about what applespi is doing ? ("dmesg | grep applespi") You should get a message that the module applespi is out of tree module and also taints the kernel... Try rebuilding the driver. Also try a "sudo depmod".

I run on ArchLinux 4.11.4 without any trouble installing, just adding the modules to mkinitcpio.conf and installing applespi and it worked pretty much (the only problem is after every kernel update I have to manualy reinstall the driver)

[sergioabril]

@choelzl no, it's not there; for some reason, dmesg | grep applespi doesn't show anything. I'll try to build it again to see if that changes. Should I add any special boot parameter so it attaches to the device? (e.g. intremap=nosid, etc)

Lucky you with ArchLinux! (Although I might have the same problems on ArchLinux too; I'm probably building it the wrong way). Thanks anyway.

[tudorbarascu]

@sergioabril I'm using debian (kali linux is based on debian) and it works just fine.

[roadrunner2]

@sergioabril The intremap=nosid boot param is definitely needed, in case you don't have that; also, make sure you do not have noapic in your boot params - double check this with cat /proc/cmdline after booting.

Next, verify that the ACPI device exists: what does

ls -l /sys/bus/acpi/devices/APP000D:00/

show? (that directory should exist, and the driver in there should point to appleacpi)

The fact that you see absolutely no messages from applespi indicates that somehow the applespi driver is not being attached to the APP000D device. You can also try (re)loading the module with extra debugging turned on:

sudo rmmod applespi ; sudo modprobe applespi dyndbg=+p

but it's unlikely to show anything either.

[sergioabril]

@roadrunner2 firstly, thank you. I've checked cat /proc/cmdline and noapic is not present. intremap=nosid it is.

Then I verified that APP00D:00 was present.

lastly, I rmmod both modules (pxa2xx and applespi), ran an apt update && upgrade, and downloaded again source + headers. Compiled again both spi_pxa2xx_platform and applespi, and again, even though both are loaded and appear on lsmod, only pxa2xx is showing relevant info on dmesg (applespi doesn't seem to attach).

Is there any specific log I could check to gather more info?

[roadrunner2]

@sergioabril Could you post the output here from the ls -l /sys/bus/acpi/devices/APP000D:00/ command? And you have the intel_lpss_pci module loaded too, right?

Then, can you also post the output here of the following commands:

lspci -nn | grep SPI
ls -l /sys/devices/pci0000:00/0000:00:1e.3/pxa2xx-spi.3/
ls -l /sys/devices/pci0000:00/0000:00:1e.3/pxa2xx-spi.3/spi_master/
ls -l /sys/devices/pci0000:00/0000:00:1e.3/pxa2xx-spi.3/spi_master/spi/

Those last three paths may not exist exactly like that: depending on the pci-id of your SPI controller (as shown by the first command) the 0000:00:1e.3 might be different (it's 0000:<pci-id>), and the pxa2xx-spi.3 might have a different number at the end.

[sergioabril]

@roadrunner2 sure, this is the output of the first command:

ls -l /sys/bus/acpi/devices/APP000D:00/
total 0
-r--r--r-- 1 root root 4096 Jun 13 01:09 adr
-r--r--r-- 1 root root 4096 Jun 13 01:09 hid
-r--r--r-- 1 root root 4096 Jun 13 01:09 modalias
-r--r--r-- 1 root root 4096 Jun 13 01:09 path
drwxr-xr-x 2 root root    0 Jun 13 01:09 power
-r--r--r-- 1 root root 4096 Jun 13 01:09 status
lrwxrwxrwx 1 root root    0 Jun 13 01:06 subsystem -> ../../../../../../bus/acpi
-rw-r--r-- 1 root root 4096 Jun 13 01:06 uevent
-r--r--r-- 1 root root 4096 Jun 13 01:09 uid

Regarding intel_lpss_pci, I added it to be loaded on boot, and it's showing on lsmod (should appear on any other log/place to make sure?)

lspci -nn | grep SPI
00:15.4 Serial bus controller [0c80]: Intel Corporation Wildcat Point-LP Serial IO GSPI Controller #1 [8086:9ce6] (rev 03)

Regarding the last three commands, If I got it right,the pc-id is 00:15.4, and the path to check should be here: /sys/devices/pci0000:00/0000:00:15.4

However, listing that path returns no pxa2xx-spi*, and no even if I tryfind command from parent folder, it doesn't get anything pxa* related anywhere. Can we conclude that pxa2xx_platform is not right then?

ls -l /sys/devices/pci0000:00/0000:00:15.4
total 0
-rw-r--r-- 1 root root 4096 Jun 13 01:27 broken_parity_status
-r--r--r-- 1 root root 4096 Jun 13 01:27 class
-rw-r--r-- 1 root root  256 Jun 13 01:27 config
-r--r--r-- 1 root root 4096 Jun 13 01:27 consistent_dma_mask_bits
-rw-r--r-- 1 root root 4096 Jun 13 01:27 d3cold_allowed
-r--r--r-- 1 root root 4096 Jun 13 01:27 device
-r--r--r-- 1 root root 4096 Jun 13 01:27 dma_mask_bits
-rw-r--r-- 1 root root 4096 Jun 13 01:27 driver_override
-rw-r--r-- 1 root root 4096 Jun 13 01:27 enable
lrwxrwxrwx 1 root root    0 Jun 13 01:27 firmware_node -> ../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT33C1:00
-r--r--r-- 1 root root 4096 Jun 13 01:27 irq
-r--r--r-- 1 root root 4096 Jun 13 01:27 local_cpulist
-r--r--r-- 1 root root 4096 Jun 13 01:27 local_cpus
-r--r--r-- 1 root root 4096 Jun 13 01:27 modalias
-rw-r--r-- 1 root root 4096 Jun 13 01:27 msi_bus
-rw-r--r-- 1 root root 4096 Jun 13 01:27 numa_node
drwxr-xr-x 2 root root    0 Jun 13 01:27 power
--w--w---- 1 root root 4096 Jun 13 01:27 remove
--w--w---- 1 root root 4096 Jun 13 01:27 rescan
-r--r--r-- 1 root root 4096 Jun 13 01:27 resource
-rw------- 1 root root 4096 Jun 13 01:27 resource0
lrwxrwxrwx 1 root root    0 Jun 13 01:27 subsystem -> ../../../bus/pci
-r--r--r-- 1 root root 4096 Jun 13 01:27 subsystem_device
-r--r--r-- 1 root root 4096 Jun 13 01:27 subsystem_vendor
-rw-r--r-- 1 root root 4096 Jun 13 01:27 uevent
-r--r--r-- 1 root root 4096 Jun 13 01:27 vendor

[roadrunner2]

@sergioabril Thanks for this info. Given that SPI controller, I think you may actually be needing the spi-pxa2xx-pci module instead of (or maybe in addition to) the spi-pxa2xx-platform module. So that may be one issue, but it doesn't explain why the appleacpi driver (from the applespi module) is not being attached to the acpi APP000D device. Are there any other errors in the log? Could you attach your dmesg output? (There shouldn't be anything secret in there, but you might want to double check anyway)

[sergioabril]

@roadrunner2 sorry for the late response; believe it or not, my external usb broke and I had to configure ssh with the on-screen keyboard to keep on doing tests remotely. Anyway, I've noticed something:

Depending on the order I decide here /etc/initramfs-tools/modules, when I boot, dmesg shows the loading out-of tree taints kernel... only for the first module listed of applespi/pxa2xx. Let me elaborate:

In the following case, when I do dmesg, it only shows the message for the applespi module, and not for spi_pxa2xx_platform:

#file: /etc/initramfs-tools/modules
intel_lpss_pci
applespi
spi_pxa2xx_plaftorm

If I flip applespi and spi_pxa2xx_platform, being applespi in third place instead of being on second place, after rebooting, dmesg only shows the tainted kernel message for spi_pxa2xx_platform, and not for applespi. Shouldn't appear for both modules no matter what the order is?

I tried loading spi_pxa2xx_pci but nothing appeared to change, so I removed it again.

As for the dmesg, here you have. In this one, it's showing applespi's tainted kernel message: (I didn't remove anything, not sure if there is anything important to hide) https://pastebin.com/3yJpPV8D

And again, thank you.

Edit: Something I'm not sure it's worth noting, is the vermagic shown onmodinfo *modulename*; while most of the modules show 4.9.0-kali4-amd64 SMP mod_unload modversions (applespi included), the pci_pxa2xx_platform module i've built shows 4.9.30 SMP mod_unload modversions.

My uname -a is:Linux kali 4.9.0-kali4-amd64 #1 SMP Debian 4.9.30-1kali1 (2017-06-06) x86_64 GNU/Linux

[roadrunner2]

@sergioabril Taintedness is only reported once, on the first module that causes it, so that's all fine.

The modinfo showing 4.9.30 but the module still getting loaded is odd, but I haven't delved into the details of the version matching stuff.

Thanks for the kernel log - I don't see anything problematic or unusual there. So I'm slowly starting to run out of ideas. Focusing on the fact that we see no applespi probe message at all means that for some reason the acpi core is not recognizing applespi as a driver (btw., just to make sure: the applespi code you compiled includes commit 130f9160c540d50614873750349a2f4ad8a0d4ea, right?). Let's see if the driver is registered as such: does the /sys/bus/acpi/drivers/appleacpi directory exist? If so, what is the output from

ls -l /sys/bus/acpi/drivers/appleacpi/

Also (assuming the above directory exists), try running this command and see if anything shows up in dmesg:

echo APP000D:00 | sudo tee /sys/bus/acpi/drivers/appleacpi/bind

[sergioabril]

@roadrunner2 thanks for the clarification about taintedness kernel, good to know. Yes, I was using that exact commit; but now I'm using the latest one, which I guess is fine: https://github.com/cb22/macbook12-spi-driver/commit/eabd36efee49aec4fb177c045e61513519184ebd

# ls -l /sys/bus/acpi/drivers/appleacpi/
total 0
--w------- 1 root root 4096 Jun 15 11:11 bind
lrwxrwxrwx 1 root root    0 Jun 15 11:11 module -> ../../../../module/applespi
--w------- 1 root root 4096 Jun 15 11:09 uevent
--w------- 1 root root 4096 Jun 15 11:11 unbind

# echo APP000D:00 | sudo tee /sys/bus/acpi/drivers/appleacpi/bind
APP000D:00
tee: /sys/bus/acpi/drivers/appleacpi/bind: No such device

Reinstalling the OS but with spi_pxa2xx_platform included on the kernel would help somehow?

I'm afraid it won't serve you of much, since doesn't seem to show anything useful (I hope I'm wrong though). But anyway, thank you so much; even if we don't sort this out, It's being useful to keep on digging and learning linux!

[roadrunner2]

@sergioabril Ok, so the driver got registered, good. The bind failing is interesting - there was nothing related in the dmesg output? Then let's enable some debug output and see if that gives more info:

echo 'file bus.c +p; file dd.c +p' | sudo tee /sys/kernel/debug/dynamic_debug/control
echo APP000D:00 | sudo tee /sys/bus/acpi/drivers/appleacpi/bind
sudo rmmod applespi && sudo modprobe applespi

Right now I'm ignoring any issue with spi_pxa2xx_platform and just trying to focus on why acpi device won't bind - one thing at a time.

[sergioabril]

@roadrunner2 These are the outputs:

# echo 'file bus.c +p; file dd.c +p' | sudo see /sys/kernel/debug/dynamic_debug/control
Error: no "view" mailcap rules found for type "inode/x-empty"

# echo APP000D:00 | sudo tee /sys/bus/acpi/drivers/appleacpi/bind
APP000D:00
tee: /sys/bus/acpi/drivers/appleacpi/bind: No such device

(And removing and loading applespi module again doesn't output anything).

Also, dmesg after rebooting doesn't tell anything about applespi (apart from taintedness) dmesg: https://pastebin.com/cnDkTLdF

If there is any other log or data I can attach, just let me know

[roadrunner2]

@sergioabril That "no view mailcap rules found" is odd - argh! Sorry, typo: not see, but tee. I just edited my original now comment to fix this. Apologies for the messup. Please try again.

[sergioabril]

@roadrunner2 no problem! using tee instead of see, I get this (am I missing something?):

# echo 'file bus.c +p; file dd.c +p' | sudo tee /sys/kernel/debug/dynamic_debug/control
file bus.c +p; file dd.c +p

# echo APP000D:00 | sudo tee /sys/bus/acpi/drivers/appleacpi/bind
APP000D:00
tee: /sys/bus/acpi/drivers/appleacpi/bind: No such device

And then after rebooting, just in case there is anything new ondmesg: https://pastebin.com/1fpJEDyL

[roadrunner2]

@sergioabril Sorry, don't reboot - that clears the kernel log and resets the dynamic-debug settings. Just run the commands, and then look at dmesg | tail -30 or so.

[sergioabril]

@roadrunner2 Understood! In that case, this is what dmesg shows

[    9.868486] systemd-journald[239]: Successfully sent stream file descriptor to service manager.
[    9.868599] systemd-journald[239]: Successfully sent stream file descriptor to service manager.
[    9.942719] systemd-journald[239]: Successfully sent stream file descriptor to service manager.
[   11.082595] systemd-journald[239]: Successfully sent stream file descriptor to service manager.
[   11.259716] systemd-journald[239]: Successfully sent stream file descriptor to service manager.
[   11.259801] systemd-journald[239]: Successfully sent stream file descriptor to service manager.
[   11.481240] systemd-journald[239]: Successfully sent stream file descriptor to service manager.
[   11.490716] systemd-journald[239]: Successfully sent stream file descriptor to service manager.
[   11.490943] systemd-journald[239]: Successfully sent stream file descriptor to service manager.
[   12.693544] brcmfmac: brcmf_cfg80211_escan_handler: scan not ready, bsscfgidx=0
[   12.693555] brcmfmac: brcmf_fweh_event_worker: event handler failed (69)
[   12.695339] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   16.266360] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   16.539211] systemd-journald[239]: Successfully sent stream file descriptor to service manager.
[   16.642825] systemd-journald[239]: Successfully sent stream file descriptor to service manager.
[   16.649800] systemd-journald[239]: Data hash table of /run/log/journal/b451b4e114a844b3923ba2f9b3b03405/system.journal has a fill level at 75.0 (13472 of 17962 items, 8388608 file size, 622 bytes per hash table item), suggesting rotation.
[   16.649810] systemd-journald[239]: /run/log/journal/b451b4e114a844b3923ba2f9b3b03405/system.journal: Journal header limits reached or header out-of-date, rotating.
[   16.649817] systemd-journald[239]: Rotating...
[   16.651780] systemd-journald[239]: Reserving 17962 entries in hash table.
[   16.651960] systemd-journald[239]: Vacuuming...
[   16.652030] systemd-journald[239]: Vacuuming done, freed 0B of archived journals from /run/log/journal/b451b4e114a844b3923ba2f9b3b03405.
[   20.688697] systemd-journald[239]: Successfully sent stream file descriptor to service manager.
[   20.717633] systemd-journald[239]: Successfully sent stream file descriptor to service manager.
[  105.595529] systemd-journald[239]: Sent WATCHDOG=1 notification.
[  132.501199] bus: 'acpi': remove driver appleacpi
[  132.501247] driver: 'appleacpi': driver_release
[  132.535185] bus: 'acpi': add driver appleacpi

[roadrunner2]

Thanks. Ok, the id match is definitely not happening. Can you show me the output from

cat /sys/bus/acpi/devices/APP000D:00/{adr,hid,modalias,path,status,uevent,uid}

[sergioabril]

@roadrunner2 Sure:

# cat /sys/bus/acpi/devices/APP000D:00/{adr,hid,modalias,path,status,uevent,uid}
0x00000000
APP000D
acpi:APP000D:APPLE-SPI-TOPCASE:
\_SB_.PCI0.SPI1.SPIT
15
MODALIAS=acpi:APP000D:APPLE-SPI-TOPCASE:
2

[roadrunner2]

@sergioabril Thanks. Well, this is really a bit of a head-scratcher: the device is there, has the expected id's (in particular the HID), the driver is registered, but the core is just not managing to match things. I'm going to have to write a dummy module for you that tries to find out more details of what is going on. I'll leave a note here when I have it.

[roadrunner2]

@sergioabril Ok, can you clone my fork of the repo (https://github.com/roadrunner2/macbook12-spi-driver) and run the following:

git checkout origin/debug-acpi
make debug

and send me the resulting debug.out?

[sergioabril]

@roadrunner2 Thanks, here it is the debug.out:

https://pastebin.com/9EFwSh7w

[roadrunner2]

@sergioabril Making a little bit of progress here - for some reason the match_driver flag is false on the acpi_device, which is why the driver isn't being associated with it. So trying to find out why that is false on your setup. Could you do two things please:

• pull the latest code again (pushed an update) and run make debug and send me the output again
• send me your /boot/config-`uname -r`

[sergioabril]

@roadrunner2 Great! Of course, there you go:

/boot/config-4.9.0-kali4-amd64 : https://pastebin.com/ptfEJLv8 debug.out: https://pastebin.com/JTJrMsLG

Edit: looks like both have expired already; let me know if you didn't manage to read them at time, and I'll repeat&upload.

[colbtuck]

I have a similar binding issue on 4.11.5-1-ARCH. Here's what my tests are showing from the previous requests via @roadrunner2 and @sergioabril :

mkinitcpio.conf lsmod pxa2xx-spi.0 appleacpi id-match debug.out

@choelzl you mentioned yours is running without issue. Any ideas where I may have gone wrong?

[roadrunner2]

@sergioabril Thanks for the info - yes, I got it before it expired. @colbtuck Thanks for your info too - looks basically the same as @sergioabril's, though in your case the pxa2xx-spi driver got attached properly and the spi-master device created, so that's one issue solved (will need to take a look at @sergioabril's setup again once we get the acpi issue figured out).

Sorry I haven't responded earlier, but I've run out of ideas to debug this without modifying (and rebuilding) the kernel. I'll create and post a patch in the next few days, but AFAICT it looks like acpi_bus_attach() (in drivers/acpi/scan.c) is not being called for some reason.

And yes, if anybody else has any ideas as to what's going on, please share.

[choelzl]

@roadrunner2 My guess would be that this is linked to distros (some packages have not the same versions for example). @colbtuck For me it worked almost out of the box... Installed manjaro, downloaded latest kernel and header, added modules to mkinitcpio and installed the driver, after reboot it worked... It could be luck ?