On 2/14/24 10:33 PM, Sergei Shtylyov 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>
>> ---
>> drivers/ata/ahci.h | 11 +++++++++++
>> drivers/ata/libahci.c | 2 +-
>> 2 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
>> index df8f8a1a3a34..92d29a059763 100644
>> --- a/drivers/ata/ahci.h
>> +++ b/drivers/ata/ahci.h
>> @@ -455,4 +455,15 @@ static inline int ahci_nr_ports(u32 cap)
>> return (cap & 0x1f) + 1;
>> }
>>
>> +static inline int ahci_nr_ports_in_map(u32 map)
>> +{
>> + unsigned long port_map = map;
>
> Why cast to potentially 64-bit type?
Ah, I figured it's for find_next_bit()....
>
>> + int i, n = 0;
>> +
>> + for_each_set_bit(i, &port_map, AHCI_MAX_PORTS)
>> + n++;
>
> There's hweight32() for that, IIUC.
Yeah, it replaces this whole function... :-)
[...]
MBR, Sergey
