From: Sergey Shtylyov <s.shtylyov@omp.ru>
To: Niklas Cassel <cassel@kernel.org>
Cc: Damien Le Moal <dlemoal@kernel.org>, <linux-ide@vger.kernel.org>,
Dieter Mummenschanz <dmummenschanz@web.de>,
Wang Zhihao <wangzhihao9@hotmail.com>,
linux-regressions <regressions@lists.linux.dev>
Subject: Re: [PATCH 2/2] ata: libata-core: Revert "ata: libata-core: Fix ata_pci_shutdown_one()"
Date: Sat, 24 Feb 2024 00:04:46 +0300 [thread overview]
Message-ID: <d5b331ba-dc2a-f212-e2b2-f5485cff5801@omp.ru> (raw)
In-Reply-To: <ZdNzvAdKKsQapx8a@x1-carbon>
On 2/19/24 6:29 PM, Niklas Cassel wrote:
[...]
>>> This reverts commit fd3a6837d8e18cb7be80dcca1283276290336a7a.
>>>
>>> Several users have signaled issues with commit fd3a6837d8e1 ("ata:
>>> libata-core: Fix ata_pci_shutdown_one()") which causes failure of the
>>> system SoC to go to a low power state. The reason for this problem
>>> is not well understood but given that this patch is harmless with the
>>> improvements to ata_dev_power_set_standby(), restore it to allow system
>>> lower power state transitions.
>>>
>>> For regular system shutdown, ata_dev_power_set_standby() will be
>>> executed twice: once the scsi device is removed and another when
>>> ata_pci_shutdown_one() executes and EH completes unloading the devices.
>>> Make the second call to ata_dev_power_set_standby() do nothing by using
>>> ata_dev_power_is_active() and return if the device is already in
>>> standby.
>>>
>>> Fixes: fd3a6837d8e1 ("ata: libata-core: Fix ata_pci_shutdown_one()")
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
>>> ---
>>> drivers/ata/libata-core.c | 75 +++++++++++++++++++++++----------------
>>> 1 file changed, 45 insertions(+), 30 deletions(-)
>>>
>>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>>> index d9f80f4f70f5..20a366942626 100644
>>> --- a/drivers/ata/libata-core.c
>>> +++ b/drivers/ata/libata-core.c
>>> @@ -2001,6 +2001,33 @@ bool ata_dev_power_init_tf(struct ata_device *dev, struct ata_taskfile *tf,
>>> return true;
>>> }
>>>
>>> +static bool ata_dev_power_is_active(struct ata_device *dev)
>>> +{
>>> + struct ata_taskfile tf;
>>> + unsigned int err_mask;
>>> +
>>> + ata_tf_init(dev, &tf);
>>> + tf.flags |= ATA_TFLAG_DEVICE | ATA_TFLAG_ISADDR;
>>
>> Why set ATA_TFLAG_ISADDR, BTW? This command doesn't use any taskfile
>> regs but the device/head reg. Material for a fix, I guess... :-)
>>
>>> + tf.protocol = ATA_PROT_NODATA;
>>> + tf.command = ATA_CMD_CHK_POWER;
>>> +
>> [...]
>
> Looking at the definition of the flag:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/libata.h?h=v6.8-rc5#n76
>
> "enable r/w to nsect/lba regs"
I'm afraid this comment doesn't reflect the reality in its r/w part --
if you look at e.g. ata_sff_tf_read(), you'll see that it always reads
all the legacy taskfile and only checks ATA_TFLAG_LBA48 in order to
determine whether it should read the HOBs as well...
> This function does read from the nsect reg:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c?h=v6.8-rc5#n2069
>
> So I would prefer to keep it as it.
IMO, it doesn't make much sense -- unless you assume that the device
could leave that reg unset as a result of this command...
> Basically the whole motto for libata right now:
> "If it ain't broke, don't fix it."
Do you realize that each taskfile reg access takes e.g. 900-990 ns on
the Intel PIIX/ICH (the part # was 82371/82801) IDE controllers (with 33
MHz PCI bus)? Luckily, we just have to write (almost?) whole taskfile on
the read/write commands anyway...
> Sure, if we look at:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-sff.c?h=v6.8-rc5#n343
>
> it seems that flags ATA_TFLAG_ISADDR, ATA_TFLAG_LBA48, and ATA_TFLAG_DEVICE
> is used to "guard" if these regs should be written to the TF.
>
>
> However, if we look at:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-sff.c?h=v6.8-rc5#n392
>
> is seems that only flag ATA_TFLAG_LBA48 is used to "guard" if the regs should
> be read from the TF.
Luckily, we have to read back the whole taskfile only on the read/write
errors...
> So it looks like the intention was that these flags should be used
> to guard if certain TF regs should be written or read, but in reality,
> only some of the flags are actually for guarding reads.
> (While all of the flags are used for guarding writes.)
So you're seeing that inconsistency (I mentioned) yourself... :-)
> Personally, I don't really see the point of using flags to guard writes
> to the host controller. Why would we want to skip writing certain TF regs?
>
> The struct ata_taskfile should be zero-initialized before filling it with
TBH, I generally hate how libata implemented the taskfile accessors
and I hate how *struct* ata_taskfile looks too... :-)
> a command, so why not always write all TF regs and remove these flags?
To stop wasting a good microsecond per a reg R/W cycle, perhaps? :-)
Anyway, the ATA standards clearly describe what the regs are used by
each command and what to expect on a normal/erratic command completion...
In drivers/ide/ we finanally ended up with 8-bit reg validity flags,
each bit corresponding to an individual taskfile reg:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=60f85019c6c8c1aebf3485a313e0da094bc95d07
> Anyway, why touch it now and risk introducing regressions on some old PATA
> hardware?
Do you realize that drivers/ide/ wasn't writing out the whole taskfile
when issuing this particular command since:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d364c7f50b3bb6dc77259974038567b821e2cf0a
If there were regressions, we would have seen them a long time ago,
no? :-)
> Kind regards,
> Niklas
MBR, Sergey
next prev parent reply other threads:[~2024-02-23 21:04 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-11 11:51 [PATCH 0/2] Power management fixes Damien Le Moal
2024-01-11 11:51 ` [PATCH 1/2] ata: libata-core: Do not try to set sleeping devices to standby Damien Le Moal
2024-02-14 11:03 ` Niklas Cassel
2024-01-11 11:51 ` [PATCH 2/2] ata: libata-core: Revert "ata: libata-core: Fix ata_pci_shutdown_one()" Damien Le Moal
2024-01-11 18:10 ` Sergei Shtylyov
2024-01-11 23:13 ` Damien Le Moal
2024-02-19 15:29 ` Niklas Cassel
2024-02-23 21:04 ` Sergey Shtylyov [this message]
2024-02-26 9:28 ` Niklas Cassel
[not found] ` <DU0P251MB082515FC8FE77424231B475CF4682@DU0P251MB0825.EURP251.PROD.OUTLOOK.COM>
2024-01-22 8:49 ` [PATCH 0/2] Power management fixes Damien Le Moal
[not found] ` <trinity-0be6e8a8-e6d3-4d60-be0d-59592a9edd65-1706010022623@3c-app-webde-bap10>
2024-01-23 11:52 ` Aw: " Damien Le Moal
[not found] ` <trinity-0df92d73-be55-433c-bdb2-4387f7ea590b-1706686178879@3c-app-webde-bap43>
2024-01-31 7:38 ` Aw: " Damien Le Moal
2024-01-31 11:49 ` Niklas Cassel
2024-01-31 12:09 ` Damien Le Moal
2024-02-01 7:12 ` Aw: " Dieter Mummenschanz
2024-02-01 8:09 ` Damien Le Moal
2024-02-01 7:10 ` Dieter Mummenschanz
2024-02-01 10:51 ` Niklas Cassel
2024-02-02 14:53 ` Aw: " Dieter Mummenschanz
2024-02-05 19:00 ` Niklas Cassel
[not found] ` <trinity-0bc8e6ea-7808-4508-af3a-be22281abf24-1707231996854@3c-app-webde-bs42>
2024-02-06 21:46 ` Niklas Cassel
2024-02-08 14:37 ` Aw: " Dieter Mummenschanz
2024-02-13 20:02 ` 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=d5b331ba-dc2a-f212-e2b2-f5485cff5801@omp.ru \
--to=s.shtylyov@omp.ru \
--cc=cassel@kernel.org \
--cc=dlemoal@kernel.org \
--cc=dmummenschanz@web.de \
--cc=linux-ide@vger.kernel.org \
--cc=regressions@lists.linux.dev \
--cc=wangzhihao9@hotmail.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;
as well as URLs for NNTP newsgroup(s).