From: Damien Le Moal <dlemoal@kernel.org>
To: tongzhiwei <tongzhiwei@cmss.chinamobile.com>, cassel@kernel.org
Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ata: libata: preserve sata_spd link cache across ata_dev_init
Date: Thu, 15 Oct 2026 09:59:54 +0200 [thread overview]
Message-ID: <4e87af7b-22e5-4dd4-8270-aa73e3539feb@kernel.org> (raw)
In-Reply-To: <9c6bafea-7eef-42c8-b514-bdb0777b9372@kernel.org>
On 2026/10/15 7:30, Damien Le Moal wrote:
> On 2026/10/10 9:54, tongzhiwei wrote:
>> a hot-unplug goes through
>> ata_eh_schedule_probe() -> ata_dev_init() -> sata_spd = 0.
>> After commit 69f2c9346313 ("ata: libata: Fix sata_down_spd_limit() when no
>> link speed is reported"), when
>> the device is unplugged, every probe lowers sata_spd_limit, which breaks
>> commit 2dc0b46b5ea3 ("libata: sata_down_spd_limit should return if
>> driver has not recorded sstatus speed"). The harm is, when the device
>> is plugged back, it is limited to low speed which will never be recovered.
>>
>> This patch stops zeroing sata_spd in ata_dev_init (sata_spd was
>> introduced in commit 008a78961ec7 ("libata: improve SATA PHY speed down
>> logic")). sata_spd is then written only on a successful reset. At
>> struct ata_port's init time the sata_spd field is zeroed by kzalloc.
>>
>> Fixes: 69f2c9346313 ("ata: libata: Fix sata_down_spd_limit() when no link speed is reported")
>> Assisted-by: LLM
>> Signed-off-by: tongzhiwei <tongzhiwei@cmss.chinamobile.com>
>> ---
>> drivers/ata/libata-core.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>> index f482c0a6d7e9..2ddad2e6ebd2 100644
>> --- a/drivers/ata/libata-core.c
>> +++ b/drivers/ata/libata-core.c
>> @@ -5659,7 +5659,7 @@ void ata_dev_init(struct ata_device *dev)
>>
>> /* SATA spd limit is bound to the attached device, reset together */
>> link->sata_spd_limit = link->hw_sata_spd_limit;
>> - link->sata_spd = 0;
>> + /* link->sata_spd caches last negotiated link speed; not zeroed here */
>
> This contradicts the previous comment, so let's make this consistent. E.g.
> something like:
>
> /*
> * The SATA speed limit is bound to the attached device, so reset it
> * but keep the last negotiated speed indicated by link->sata_spd.
> */
>
> to replace the previous comment.
>
>>
>> /* High bits of dev->flags are used to record warm plug
>> * requests which occur asynchronously. Synchronize using
Looking at the Sashiko comment on this patch, I think it is valid and should be
addressed as well.
--
Damien Le Moal
Western Digital Research
prev parent reply other threads:[~2026-10-15 7:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-10 7:54 tongzhiwei
2026-10-15 5:30 ` Damien Le Moal
2026-10-15 7:59 ` Damien Le Moal [this message]
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=4e87af7b-22e5-4dd4-8270-aa73e3539feb@kernel.org \
--to=dlemoal@kernel.org \
--cc=cassel@kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tongzhiwei@cmss.chinamobile.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
all inboxes | Powered by JetHome®