Re: [PATCH 2/2] Power on ata ports defined in ACPI before probing ports

[Niklas Cassel <cassel@kernel.org>]

On Mon, Oct 06, 2025 at 03:50:35PM +0000, Markus Probst wrote:
> On Mon, 2025-10-06 at 17:07 +0200, Niklas Cassel wrote:
> > On Sun, Oct 05, 2025 at 07:06:07PM +0000, Markus Probst wrote:
> > > some devices (for example every synology nas with "deep sleep"
> > > support)
> > 
> > Some devices?
> > I assume you mean the HBA and not the devices connected to the HBA.
> Embedded devices. There are 2 connectors to a sata disk. One for the
> data connection to the sata controller. Another one to the power supply
> (so the disk gets the power). This patch tells the power supply for the
> disk to give the disk power (if one is defined in acpi).

Ok, please add this to the commit message.


> Synology produces NAS devices. Some of those devices have something
> they call "deep sleep". In this case, if a sata disk gets power is
> controlled by a gpio and is *off by default*.

Please add this to the commit message.

We already have DevSleep, which is a feature implemented in the SATA
specification, where the HBA asserts a signal (DEVSLP, which on some
boards is just a GPIO), while this signal is asserted the device may
completely power down its PHY, and it may also choose to power down
other subsystems, as long as it can meet the exit latency requirements.
(The device should exit DevSleep when the DEVSLP signal is deasserted.)

For more info see e.g.
https://sata-io.org/sites/default/files/documents/SATADevSleep-and-RTD3-WP-037-20120102-2_final.pdf

Since this patch implements something similar to DevSleep, but rather,
IIUC, for the SATA power itself?

How is SATA power supplied tied to a port in ACPI? If you have a desktop
you have a PSU, and don't really know which supply is for which port.


In SATA, we also have PxSCTL (SRC2: SControl) where we can completely
disable a port and port the PHY in offline mode, see:
https://github.com/torvalds/linux/blob/v6.17/drivers/ata/libata-sata.c#L415-L419


So, considering how many ways we already have to disable/power off a port,
you might understand why I think it is extra important that you document
exactly how, and why we need yet another way to disable/power on/off a port.



Kind regards,
Niklas