On 2/19/24 19:48, Niklas Cassel wrote: > 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. > > Suggested-by: Damien Le Moal <dlemoal@xxxxxxxxxx> > Signed-off-by: Niklas Cassel <cassel@xxxxxxxxxx> > --- > Changes since V1: > -Use hweight32(). Thank you Sergei. > > drivers/ata/libahci.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c > index fca376f03c9e..ef31d234e7b6 100644 > --- a/drivers/ata/libahci.c > +++ b/drivers/ata/libahci.c > @@ -2630,7 +2630,7 @@ void ahci_print_info(struct ata_host *host, const char *scc_s) > vers & 0xff, > > ((cap >> 8) & 0x1f) + 1, > - (cap & 0x1f) + 1, > + hweight32(impl), Looks good. But we could also print "%u/%u ports", keeping the max port number from cap ((cap & 0x1f) + 1) and the actual port count implemented (hweight32(impl)). This would be less confusing/more informational as the maximum number of ports for the adapter may still be equal to (cap & 0x1f) + 1 even though a lower number of ports is implemented. > speed_s, > impl, > scc_s); -- Damien Le Moal Western Digital Research
