Marvell 88W8897 quirks - linux-surface/linux-surface GitHub Wiki
The Surface devices using the Marvell 88W8897 PCIe wifi/bluetooth card all suffer from connection instability issues, firmware crashes and powersaving issues.
This is a list that tries to collect all the changes needed for each device using that chip to get wifi and bluetooth working flawlessly:
Valid for all devices
- PCI bridge device may not enter D3 state, otherwise driver crashes after suspend (https://github.com/linux-surface/kernel/pull/44/commits/028e378f453cd9ca6eeb0055ebb5b7b3b793b364)
- To prevent AP-scanning from breaking after suspend and s0ix from breaking during suspend, card needs to be shut down instead of using host-sleep while suspended (https://github.com/linux-surface/kernel/pull/56)
- (seems to be completely fixed on kernel 5.9) Bluetooth prevents powersaving if no Bluetooth-LE device is connected because of LE advertisement report spam, can be fixed by disabling Bluetooth-LE. On older kernels this breaks suspending, so bluetooth has to be disabled during suspend.
Valid for specific device
Surface Book (SB)
- Card reset needs PCI device to be put into D3cold state (https://github.com/linux-surface/kernel/pull/58)
Surface Book 2 (SB2)
- To prevent random firmware crashes during runtime, ASPM L1.2 powersaving state has to be disabled
- Card reset needs PCI device to be put into D3cold state (https://github.com/linux-surface/kernel/pull/58)
Surface 3 (S3)
- Card reset needs calling
_DSM
ACPI method (https://github.com/linux-surface/kernel/pull/58) - To prevent random firmware crashes during runtime, ASPM L1 and all L1 substates need to be disabled
Surface Laptop (SL)
- [needs confirmation] Card reset needs PCI device to be put into D3cold state (https://github.com/linux-surface/kernel/pull/58)
Surface Laptop 2 (SL2)
- [needs confirmation] Card reset needs PCI device to be put into D3cold state (https://github.com/linux-surface/kernel/pull/58)
Surface Pro 3 (SP3)
- Card reset needs calling
_DSM
ACPI method (https://github.com/linux-surface/kernel/pull/58) - To prevent random firmware crashes during runtime, ASPM L1.1 and L1.2 substates need to be disabled
Surface Pro 4 (SP4)
- [needs confirmation] Card reset needs PCI device to be put into D3cold state (https://github.com/linux-surface/kernel/pull/58)
Surface Pro 5 / 2017 (SP5)
- To prevent random firmware crashes during runtime, ASPM L1.2 powersaving state has to be disabled
- pc10 powersaving state will only be entered when ignoring the LTR messages on SPA or after resetting the PCI bridge device, the card seems to always report an LTR latency that's lower than what we can archive.
- Card reset needs PCI device to be put into D3cold state (https://github.com/linux-surface/kernel/pull/58)
Surface Pro 6 (SP6)
- [needs confirmation] Card reset needs PCI device to be put into D3cold state (https://github.com/linux-surface/kernel/pull/58)
Various notes
- Newer firmwares always report an excessively high LTR value (probably trying to work around performance problems), preventing the chipset from entering PC10 or S0ix powersaving during runtime
- Disabling ASPM L1.2 or ASPM+PCIPM L1.2 has no effect on allowed powersaving states during both runtime and suspend
- Disabling L1.2 and ASPM L1.1 makes the chipset inhibit S0ix powersaving during runtime (appears to force-disable power gating of the southport used by wifi)
- Disabling L1.2 and ASPM+PCIPM L1.1 makes the chipset inhibit S0ix powersaving during both runtime and suspend
- A script from Launchpad to set ASPM to L0, in case of
pcie_aspm
kernel parameter is not working (https://launchpadlibrarian.net/405591349/disable_wireless_aspm.sh) - When the card gets reset, the firmware disables all ASPM L1 substates by itself. It only writes to its own PCI configuration space though, ignoring the configuration space of the parent device, that means the L1 substates on the bridge device are still enabled. This seems to trick the chipset into thinking all L1 substates are still enabled and thus it won't impose limits on the powersaving states the can be archived. The firmware crashes during runtime are still gone though.