![]() ![]() There are certainly proprietary "vendor-specific" extensions to those, but e.g. all PS/2 keyboards or mice are expected to have an identical basic set of functionality and behaviour. It's not like USB which defines device classes and the higher-level layers of the stack, or PS/2 where e.g. The only thing that's constant is that it is a synchronous serial protocol. True, but SPI is really just referring to the physical layer protocol while the layers above can vary considerably and be proprietary. Personally, I'm all for new features but implemented in backwards-compatible or relatively standard ways. Later models of PCs and Macs started using USB internally (which is in some ways more complex, since the existing PS/2 interface was provided by the EC via LPC whereas USB may require an additional controller and definitely requires routing additional signals between it and one of the USB ports on the chipset), but at least they would still work relatively standardly. ![]() keyboard and trackpad looked like standard PS/2 devices. I still remember when the first "Intel Macbooks" came out with nearly identical hardware to a PC laptop of the same era, i.e. They're also extensible, so one does not have to reinvent everything to add additional features. USB and PS/2 are standardised to the point that hardware and software for them are widely available and cheap. Things like this make me wonder if Apple is deliberately going for proprietariness as a sort of vendor-lock-in, because I can't see any other compelling reasons for coming up with a completely different interface for such basic and existing devices. I spend some time while I was at Red Hat trying to keep Apple hardware working ( is an example of what we had to do), but I don't know that anybody's really working terribly hard on it these days. These issues are far from unusual when dealing with Apple hardware ((1) was true for the new Macbook, (2) has been true since Apple introduced NVME, (3) is the kind of weirdness that we've seen on Apple hardware ever since they went Intel), and this particular set of breakage is unsurprising. ![]() (3) is unclear - Windows may be setting up interrupt remapping differently, or it may never enable source ID verification. Windows works fine because Apple provide drivers for (1) and (2). It's unclear what the underlying problem is. Linux has a specific entry for the older Apple NVME devices, and that may need to be broadened.ģ) Having source ID checking enabled when doing IRQ remapping results in the system hanging on boot. Longer term, the kernel needs to be able to parse Apple's ACPI tables and that driver needs merging.Ģ) 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). You then still need another driver for the SPI controller, and there's an out of tree one at. Apple's ACPI tables don't provide the GPIO mappings for these things via the standard mechanisms, so the chipset driver won't bind. 1) The input devices are on SPI, not USB.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |