On 8/29/19 5:30 PM, Dan Williams wrote: > The Linux ahci driver has historically implemented a configuration fixup > for platforms / platform-firmware that fails to enable the ports prior > to OS hand-off at boot. The fixup was originally implemented way back > before ahci moved from drivers/scsi/ to drivers/ata/, and was updated in > 2007 via commit 49f290903935 "ahci: update PCS programming". The quirk > sets a port-enable bitmap in the PCS register at offset 0x92. > > This quirk could be applied generically up until the arrival of the > Denverton (DNV) platform. The DNV AHCI controller architecture supports > more than 6 ports and along with that the PCS register location and > format were updated to allow for more possible ports in the bitmap. DNV > AHCI expands the register to 32-bits and moves it to offset 0x94. > > As it stands there are no known problem reports with existing Linux > trying to set bits at offset 0x92 which indicates that the quirk is not > applicable. Likely it is not applicable on a wider range of platforms, > but it is difficult to discern which platforms if any still depend on > the quirk. > > Rather than try to fix the PCS quirk to consider the DNV register layout > instead require explicit opt-in. The assumption is that the OS driver > need not touch this register, and platforms can be added with a new > boad_ahci_pcs7 board-id when / if problematic platforms are found in the > future. The logic in ahci_intel_pcs_quirk() looks for all Intel AHCI > instances with "legacy" board-ids and otherwise skips the quirk if the > board was matched by class-code. Applied, thanks Dan. -- Jens Axboe
