public inbox for linux-ide@vger.kernel.org
 help / color / mirror / Atom feed
From: Damien Le Moal <dlemoal@kernel.org>
To: Patrick Zima <pz.102010@gmail.com>, linux-ide@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [BUG] ata: ahci: regression in f7870e8d345c disables DevSleep for ACS-5 drives on PSC=0/SSC=0/SDS=1 controllers
Date: Mon, 6 Apr 2026 09:30:34 +0200	[thread overview]
Message-ID: <73386b55-933f-42b3-b566-e9f4e3ea001d@kernel.org> (raw)
In-Reply-To: <1350BE53-13DB-4250-B323-7FBA335583BB@gmail.com>

On 2026/04/05 21:01, Patrick Zima wrote:
> Commit f7870e8d345c ("ata: ahci: Disable DIPM if host lacks support") introduced
>   a regression: it disables DIPM — and thereby DevSleep — on drives behind AHCI
>   controllers that have CAP.PSC=0 and CAP.SSC=0 but CAP2.SDS=1 (DevSleep capable).
>   The guard condition is too broad; it treats the absence of Partial/Slumber state
>   bits as grounds to disable DIPM, but DevSleep does not depend on Partial or
>   Slumber being exposed to the OS — only on SDS=1 in CAP2.
> 
>   --- The logic flaw ---
> 
>   The new code (simplified):
> 
>     if (!(cap & HOST_CAP_PART) || !(cap & HOST_CAP_SSC))
>         set ATA_FLAG_NO_DIPM on port
>         → SETFEATURES DISABLE DIPM to all drives with word 78 bit 3 set
> 
>   On a controller with PSC=0, SSC=0 but SDS=1, this fires unconditionally,
>   even though the controller is fully capable of negotiating DevSleep.
>   The flag ATA_FLAG_NO_DIPM then also suppresses ALPM port behaviour at the
>   kernel level — re-enabling DIPM at the drive level via SETFEATURES after the
>   fact does not restore DevSleep.
> 
>   --- Suggested fix ---
> 
>   Gate the DIPM-disable path on the absence of DevSleep support:
> 
>     if (!(cap & HOST_CAP_PART) && !(cap & HOST_CAP_SSC)
>   +     && !(cap2 & HOST_CAP2_SDS)
>         && (ap->flags & ATA_FLAG_DIPM)) {
> 
>   If the controller can do DevSleep (SDS=1), there is no reason to disable
>   DIPM — the power state sequence Active → DevSleep does not require Partial
>   or Slumber to be present.

Instead of sending what looks like an AI generated report, what about you
actually generate a proper patch from the suggested fix and test it ? And send
said patch if the suggested fix works ?


-- 
Damien Le Moal
Western Digital Research

       reply	other threads:[~2026-04-06  7:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1350BE53-13DB-4250-B323-7FBA335583BB@gmail.com>
2026-04-06  7:30 ` Damien Le Moal [this message]
2026-04-06  8:01   ` [BUG] ata: ahci: regression in f7870e8d345c disables DevSleep for ACS-5 drives on PSC=0/SSC=0/SDS=1 controllers Niklas Cassel
     [not found]     ` <F13D8AEB-E819-4322-AD3E-6AD7ECD7EBF0@gmail.com>
2026-04-07  7:48       ` Niklas Cassel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=73386b55-933f-42b3-b566-e9f4e3ea001d@kernel.org \
    --to=dlemoal@kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pz.102010@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox