4 ms·
It's even more interesting when you can infer why its broken. Let's take the NVMe controller in the MacBook Pro 2016 and later for example: That controller is n
by Dunedan 6y ago
It's even more interesting when you can infer why its broken. Let's take the NVMe controller in the MacBook Pro 2016 and later for example: That controller is not properly detected by Linux and needs a quirk [1] to be identified by its PCI device id instead.
Why is that? Well, Linux usually detects NVMe devices based on their PCI class. The class for NVMe devices is 0x010802. So guess what the Apple controller provides as class id: 0x018002. If you have to compare the ids twice to notice what's different, you're not alone. My guess is that this subtle difference is just a human error made by an Apple engineer, which wasn't caught during QA and macOS simply works around it as well or doesn't use PCI class anyway.
So for the same reason software isn't perfect, hardware (or the firmware powering that hardware) is neither.
[1]: https://github.com/torvalds/linux/blob/b791d1bdf9212d944d749a5c7ff6febdba241771/drivers/nvme/host/pci.c#L3126 https://github.com/torvalds/linux/blob/b791d1bdf9212d944d749...
[2]: https://lists.infradead.org/pipermail/linux-nvme/2017-February/008351.html https://lists.infradead.org/pipermail/linux-nvme/2017-Februa...