From: Phillip Susi <phill@thesusis.net>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: linux-ide@vger.kernel.org
Subject: Re: [PATCH 1/4] libata: only wake a drive once on system resume
Date: Fri, 05 Jan 2024 12:03:31 -0500 [thread overview]
Message-ID: <87y1d3sof0.fsf@vps.thesusis.net> (raw)
In-Reply-To: <f47ef1a9-3bd4-48c2-a7de-2c0e74c55647@kernel.org>
Damien Le Moal <dlemoal@kernel.org> writes:
>> - return;
>> + return AC_ERR_OTHER;
>
> Nope. This is wrong. ata_dev_power_init_tf() returns a bool, not an error. The
> bool indicates if the drive supports power management.
Are you saying it should return AC_ERR_OK? If the drive doesn't support
power management at all, isn't it an error to try to change its power
management state?
> But beside this, I still do not understand what this fixes... Calling again
> ata_dev_power_set_active() will do nothing but issue a check power mode command
> if the drive is already active. So I do not see the need for this added complexity.
If the drive is NOT active because it is PuiS, it would try to start the drive
anyhow, despite the PuiS actively clearing the ATA_EH_SET_ACTVE flag.
Then the VERIFY command fails if the drive requires the SET FEATURES
command to leave PuiS.
My goal here was to make sure that when the PuiS patch clears
ATA_EH_SET_ACTIVE, that it does not get turned back on during a second
round of EH. Then you pointed out that it SHOULD try on the second
round, if the first attempt failed, so I changed the return to be able
to detect the error, and turn ATA_EH_SET_ACTIVE on for the second round.
It occurs to me now that I only ran into this issue once I changed to
actually giving the drive the SLEEP command instead of just setting the
sleeping flag. Once the drive actually went to sleep, it shut down the
sata link, which caused an error interrupt, which triggered a second
round of EH, which then issued the failing VERIFY command until all 5
rounds were used and it gave up. So if I go back to just setting the
sleeping flag instead of actually putting the drive to sleep, I would
not get the error interrupt and would be fine without this patch. But I
can imagine some other cause for a second round of EH on some system
that would still run into this problem.
next prev parent reply other threads:[~2024-01-05 17:03 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-25 15:19 [PATCH 0/1] Only activate drive once during system resume Phillip Susi
2023-12-25 15:19 ` [PATCH 1/1] libata: only wake a drive once on " Phillip Susi
2023-12-30 18:21 ` [PATCH 0/1 v2] Only activate drive once during " Phillip Susi
2023-12-30 18:21 ` [PATCH 1/1] libata: only wake a drive once on " Phillip Susi
2023-12-30 19:42 ` Sergey Shtylyov
2024-01-02 23:17 ` Damien Le Moal
2024-01-03 21:00 ` Phillip Susi
2024-01-04 1:21 ` Damien Le Moal
2024-01-04 14:05 ` Phillip Susi
2024-01-04 22:39 ` [PATCH 1/4] " Phillip Susi
2024-01-04 22:39 ` [PATCH 2/4] libata: don't wake sleeping disk during system suspend Phillip Susi
2024-01-05 12:25 ` Damien Le Moal
2024-01-05 16:18 ` Phillip Susi
2024-01-04 22:39 ` [PATCH 3/4] libata: avoid waking disk for several commands Phillip Susi
2024-01-05 8:46 ` Sergei Shtylyov
2024-01-05 16:24 ` Phillip Susi
2024-01-05 18:33 ` Sergei Shtylyov
2024-01-06 19:49 ` Phillip Susi
2024-01-06 20:29 ` Phillip Susi
2024-01-08 8:57 ` Sergei Shtylyov
2024-01-05 12:29 ` Damien Le Moal
2024-01-05 16:30 ` Phillip Susi
2024-01-06 23:14 ` Damien Le Moal
2024-01-07 17:57 ` Phillip Susi
2024-01-07 18:02 ` [PATCH 0/3] Let sleeping disks lie Phillip Susi
2024-01-07 18:02 ` [PATCH 1/3] libata: avoid waking disk for several commands Phillip Susi
2024-01-08 6:25 ` Damien Le Moal
2024-01-08 13:27 ` Phillip Susi
2024-01-10 2:39 ` Damien Le Moal
2024-01-16 17:06 ` Phillip Susi
2024-01-19 20:43 ` Phillip Susi
2024-01-20 18:08 ` Phillip Susi
2024-01-21 0:37 ` Damien Le Moal
2024-01-21 0:37 ` Damien Le Moal
2024-01-24 16:04 ` Phillip Susi
2024-01-24 21:51 ` Damien Le Moal
2024-02-01 20:01 ` Phillip Susi
2024-02-02 1:08 ` Damien Le Moal
2024-02-02 19:53 ` Phillip Susi
2024-02-02 23:17 ` Damien Le Moal
2024-02-05 19:52 ` Phillip Susi
2024-01-08 8:48 ` Sergey Shtylyov
2024-01-08 13:30 ` Phillip Susi
2024-01-07 18:02 ` [PATCH 2/3] libata: only wake a drive once on system resume Phillip Susi
2024-01-08 6:04 ` Damien Le Moal
2024-01-07 18:02 ` [PATCH 3/3] libata: don't start PuiS disks on resume Phillip Susi
2024-01-08 6:03 ` Damien Le Moal
2024-01-08 13:39 ` Phillip Susi
2024-01-10 2:19 ` Damien Le Moal
2024-01-16 17:13 ` Phillip Susi
2024-01-04 22:39 ` [PATCH 4/4] " Phillip Susi
2024-01-05 8:57 ` Sergei Shtylyov
2024-01-05 12:42 ` Damien Le Moal
2024-01-05 16:44 ` Phillip Susi
2024-01-05 12:13 ` [PATCH 1/4] libata: only wake a drive once on system resume Damien Le Moal
2024-01-05 17:03 ` Phillip Susi [this message]
2024-01-06 23:06 ` Damien Le Moal
2024-01-05 12:44 ` Damien Le Moal
2024-01-09 15:20 ` [PATCH 0/1 v2] Only activate drive once during " Niklas Cassel
2024-01-16 17:23 ` Phillip Susi
2024-01-02 22:46 ` [PATCH 0/1] " Damien Le Moal
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=87y1d3sof0.fsf@vps.thesusis.net \
--to=phill@thesusis.net \
--cc=dlemoal@kernel.org \
--cc=linux-ide@vger.kernel.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).