Re: Regression from 7627a0edef54 ("ata: ahci: Drop low power policy board type") on reboot (but not cold boot)

[Mario Limonciello <mario.limonciello@amd.com>]

On 3/10/2025 11:24, Niklas Cassel wrote:
> On Sat, Mar 08, 2025 at 11:05:36AM +0100, Eric wrote:
>>> $ sudo lspci -nns 0000:00:11.0
>> 00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD/ATI]
>> SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] (rev 40)
> 
> Ok, so some old ATI controller that seems to have a bunch of
> workarounds.
> 
> Mario, do you know anything about this AHCI controller?

Unfortunately not; this is one of those "Before my time" type of things. 
  Let me add Shyam and Basavaraj, they may know more about it.

Something that comes to my mind though is this patch:

https://lore.kernel.org/linux-pci/20241208074147.22945-1-kaihengf@nvidia.com/

It's been shown to fix several issues where the Linux kernel doesn't put 
the devices into the proper state from the shutdown callbacks.

Maybe it helps here too?

> 
> 
> """
> 3.1.4 Offset 0Ch: PI – Ports Implemented
> 
> This register indicates which ports are exposed by the HBA.
> It is loaded by the BIOS. It indicates which ports that the HBA supports are
> available for software to use. For example, on an HBA that supports 6 ports
> as indicated in CAP.NP, only ports 1 and 3 could be available, with ports
> 0, 2, 4, and 5 being unavailable.
> 
> Software must not read or write to registers within unavailable ports.
> 
> The intent of this register is to allow system vendors to build platforms
> that support less than the full number of ports implemented on the HBA
> silicon.
> """
> 
> 
> It seems quite clear that it is a BIOS bug.
> It is understandable that HBA vendors reuse the same silicon, but I would
> expect BIOS to always write the same value to the PI register.
> 
> 
> 
> Kind regards,
> Niklas