On 2/15/24 17:01, Andrey Melnikov wrote: > ср, 14 февр. 2024 г. в 21:20, Niklas Cassel <cassel@xxxxxxxxxx>: >> >> We are currently printing the CAP.NP field. >> CAP.NP is a 0's based value indicating the maximum number of ports >> supported by the HBA silicon. Note that the number of ports indicated >> in this field may be more than the number of ports indicated in the >> PI (ports implemented) register. (See AHCI 1.3.1, section 3.1.1 - >> Offset 00h: CAP – HBA Capabilities.) >> >> Print the port_map instead, which is the value read by the PI (ports >> implemented) register (after fixups). >> >> PI (ports implemented) register is a field that has a bit set to '1' >> if that specific port is implemented. This register is allowed to have >> zeroes mixed with ones, i.e. a port in the middle is allowed to be >> unimplemented. (See AHCI 1.3.1, section 3.1.4 - Offset 0Ch: PI – Ports >> Implemented.) >> >> Fix the libata print to only print the number of implemented ports, >> instead of the theoretical number of ports supported by the HBA. > > NAK. > Kernel must report what it got from silicone/addon-board. Different > revisions may implement different numbers of ports. > If you want to report real (usable) ports - add it after the mask. Or print the mask *and* the number of ports. E.g., on my machine, I see: ahci 0000:00:17.0: AHCI 0001.0301 32 slots 8 ports 6 Gbps 0xff impl SATA mode Which would be a lot more human friendly as something like: ahci 0000:00:17.0: AHCI 0001.0301 32 slots 8/8 ports impl (0xff mask) 6 Gbps SATA mode Or ahci 0000:00:17.0: AHCI 0001.0301 32 slots 6 Gbps SATA mode ahci 0000:00:17.0: AHCI 0001.0301 8/8 ports implemented (port mask 0xff) -- Damien Le Moal Western Digital Research
