lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aOeffbuAIxeuimHC@ryzen>
Date: Thu, 9 Oct 2025 13:41:49 +0200
From: Niklas Cassel <cassel@...nel.org>
To: Markus Probst <markus.probst@...teo.de>
Cc: Damien Le Moal <dlemoal@...nel.org>,
	"James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	linux-ide@...r.kernel.org, linux-scsi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] Power on ata ports defined in ACPI before probing
 ports

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ