Hello ASMedia developers, We are facing some issues with some of your HBAs, e.g. ASM1166 and ASM1064. The first problem was that e.g. ASM1064 reports more ports than the physical number of ports, see: https://bugzilla.kernel.org/show_bug.cgi?id=211873 https://bugzilla.kernel.org/show_bug.cgi?id=218346 This was fixed in: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/ata?id=0077a504e1a4468669fd2e011108db49133db56e and https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/ata?id=9815e39617541ef52d0dfac4be274ad378c6dc09 For some PCIe cards with ASM1064, like the Delock 90073 16 port sata controller. (It contains 4x ASM1064, each connected to one PCIe lane.) So the port map went from: 0xffff0f : 1111 1111 1111 1111 0000 1111 to 0xf : 1111 These virtual ports, which are not backed by a physical port, causes the boot time to be significantly increased (by 3-4 minutes), waiting for timeouts on these virtual ports. >From reading the ASM1064 datasheet, it only seems to support 4 ports, so it seems like a AHCI spec violation to define more ports than what is physically provided by the HBA silicon. For other PCIe cards with ASM1064, e.g. https://www.ebay.com/itm/204230341609 There are 4x JMicron JMB575 Port Multipliers (PMP) embedded on the PCIe card itself (presumably one for each physical port on the ASM1064). For this card, the virtual ports do not seem to cause an increased boot time. Both of these cards have the same PCIe device and vendor IDs (the ASMedia one), so it is not trivial to quirk them based on that. Looking at the boot logs for ASM1064 (the one with the JMB575 PMPs) on kernel v6.8: ahci 0000:04:00.0: AHCI 0001.0301 32 slots 24 ports 6 Gbps 0xf impl SATA mode ahci 0000:04:00.0: flags: 64bit ncq sntf stag pm led only pio sxs deso sadm sds apst We can see that the HBA does not advertise PMP support. CAP.SPM (Supports Port Multiplier)) is not set. According to the ASM1064 datasheet, the HBA is supposed to support PMP, so this seems to be another instance where the AHCI specification is not followed. If we quirk the ASM1064, to set the CAP.SPM bit in CAP, we still can not detect a PMP on port0-port3: ahci 0000:04:00.0: ASM1064 has only four ports ahci 0000:04:00.0: controller can do PMP, turning on CAP_PMP ahci 0000:04:00.0: forcing port_map 0xffff0f -> 0xf ahci 0000:04:00.0: AHCI 0001.0301 32 slots 24 ports 6 Gbps 0xf impl SATA mode ahci 0000:04:00.0: flags: 64bit ncq sntf stag pm led only pmp pio sxs deso sadm sds apst ata7: SATA max UDMA/133 abar m8192@0xfcd80000 port 0xfcd80100 irq 41 lpm-pol 0 ata8: SATA max UDMA/133 abar m8192@0xfcd80000 port 0xfcd80180 irq 41 lpm-pol 0 ata9: SATA max UDMA/133 abar m8192@0xfcd80000 port 0xfcd80200 irq 41 lpm-pol 0 ata10: SATA max UDMA/133 abar m8192@0xfcd80000 port 0xfcd80280 irq 41 lpm-pol 0 [ 0.919020] ata7: SATA link down (SStatus 0 SControl 330) [ 2.787201] ata8: SATA link down (SStatus 0 SControl 330) [ 3.100522] ata9: SATA link down (SStatus 0 SControl 330) [ 3.413890] ata10: SATA link down (SStatus 0 SControl 330) I was expecting link up and PMP class code detected on port0-port3. On which ports are the PMPs connected then? How are you supposed to talk to the PMP (i.e. send PMP read and PMP write commands). We need to be able to read out the PMP device and vendor ID of the PMP, and to enumerate the devices behind the PMP according to AHCI and SATA-IO specs. It appears that ASM1064 is violating these specifications, and instead being able to enumerate the devices behind a PMP according to the specs, ASM1064 firmware tries to hide the fact that a PMP is connected to one of the ports. A third example is here: https://lore.kernel.org/linux-ide/CADUzMVaFcD26QiBK_eKCbtC5Ot-+hAruNbUx+2pQNTKtMhDGRA@xxxxxxxxxxxxxx/ A user plugging in an external PMP (so not a PMP embedded on the PCIe card). We need to be able to read the PMP device and vendor ID, in order to apply the correct PMP quirks, see sata_pmp_quirks(). So trying to hide which PMP that is connected is bad, not only because it violates the specs, but also because it stops us from providing the proper quirks for the connected PMP. Could you please tell us how we can communicate with the PMPs directly? (Regardless if they are external PMPs or PMPs embedded on the PCIe card.) Kind regards, Niklas
