Re: [PATCH] ahci: asm1064: correct count of reported ports

From: Damien Le Moal
Date: Tue Feb 13 2024 - 19:09:57 EST


On 2/14/24 03:05, Niklas Cassel wrote:
> On Tue, Feb 13, 2024 at 06:19:10PM +0100, Niklas Cassel wrote:
>> On Thu, Feb 08, 2024 at 10:27:11AM +0300, Andrey Melnikov wrote:
>>>> On 2/7/24 12:58 PM, Andrey Jr. Melnikov wrote:
>>>>
>>>>> The ASM1064 SATA host controller always reports wrongly,
>>>>> that it has 24 ports. But in reality, it only has four ports.
>>>>>
>>>>> before:
>>>>> ahci 0000:04:00.0: SSS flag set, parallel bus scan disabled
>>>>> ahci 0000:04:00.0: AHCI 0001.0301 32 slots 24 ports 6 Gbps 0xffff0f impl SATA mode
>>>>> ahci 0000:04:00.0: flags: 64bit ncq sntf stag pm led only pio sxs deso sadm sds apst
>>>>>
>>>>> after:
>>>>> ahci 0000:04:00.0: ASM1064 has only four ports
>>>>> ahci 0000:04:00.0: forcing port_map 0xffff0f -> 0xf
>>>>> ahci 0000:04:00.0: SSS flag set, parallel bus scan disabled
>>>>> 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
>>>>>
>>>>>
>>>>> Signed-off-by: Andrey Jr. Melnikov <temnota.am@xxxxxxxxx>
>>>>>
>>>>> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
>>>>> index da2e74fce2d9..ec30d8330d16 100644
>>>>> --- a/drivers/ata/ahci.c
>>>>> +++ b/drivers/ata/ahci.c
>>>>> @@ -671,9 +671,14 @@ MODULE_PARM_DESC(mobile_lpm_policy, "Default LPM policy for mobile chipsets");
>>>>> static void ahci_pci_save_initial_config(struct pci_dev *pdev,
>>>>> struct ahci_host_priv *hpriv)
>>>>> {
>>>>> - if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA && pdev->device == 0x1166) {
>>>>> - dev_info(&pdev->dev, "ASM1166 has only six ports\n");
>>>>> - hpriv->saved_port_map = 0x3f;
>>>>> + if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA) {
>>>>> + if (pdev->device == 0x1166) {
>>>>
>>>> Maybe *switch* instead?
>>>
>>> Ok.
>>
>> Hello Andrey,
>>
>> do you intend to send out a v2 that uses a switch instead?
>>
>> And perhaps take Damien's patch as patch 1/2
>> (with Suggested-by: Damien ... of course),
>> so that the before/after print in your commit message shows
>> the override value.
>
> On second thought, just go ahead and respin your patch using a switch,
> as I don't think Damien's patch is fully correct.
>
> He suggested to use hpriv->saved_port_map.
>
> However, that will show the wrong result for platforms using
> hpriv->mask_port_map.
>
> As when hpriv->mask_port_map is used, saved_port_map is not set:
> https://github.com/torvalds/linux/blob/v6.8-rc4/drivers/ata/libahci.c#L536-L548
>
> However, the local variable "port_map" is updated for both
> saved_port_map and mask_port_map cases.
>
> And then at the end:
> hpriv->port_map = port_map;
> https://github.com/torvalds/linux/blob/v6.8-rc4/drivers/ata/libahci.c#L597
>
> So I think we should print hpriv->port_map,
> and not hpriv->saved_port_map.

Indeed, good catch...

> However.. hpriv->port_map is already printed:
> https://github.com/torvalds/linux/blob/v6.8-rc4/drivers/ata/libahci.c#L2617
> in the "0x%x impl" print.
>
> So
>> before:
>> ahci 0000:04:00.0: AHCI 0001.0301 32 slots 24 ports 6 Gbps 0xffff0f impl SATA mode
>
>> after:
>> ahci 0000:04:00.0: AHCI 0001.0301 32 slots 24 ports 6 Gbps 0xf impl SATA mode
>
> Actually prints the number of *implemented* ports.
>
>
> I have to admit that this is a bit confusing.
>
> Personally I would have preferred if we simply printed
> "%u ports", hpriv->port_map,
>
> and simply dropped the "0x%x impl" part of the print,
> but I'm a bit worried that someone parses this print from user space,
> but I guess we must be allowed to improve prints if they are confusing.
>
> Damien, what do you think?

..but port_map is a mask, not a count of ports. So this would still be wrong.
I think we simply need a small helper that look something like:

int ahci_nr_ports(struct ata_host *host)
{
struct ahci_host_priv *hpriv = host->private_data;
int i, n = 0;

for_each_set_bit(i, &hpriv->port_map, AHCI_MAX_PORTS)
n++;

return n;
}

and print that instead together with the mask.

--
Damien Le Moal
Western Digital Research