Re: [PATCH] ata: libata-sata: retry hardreset when device detected but PHY not established

[yangxingui <yangxingui@huawei.com>]

On 2026/4/29 9:36, Damien Le Moal wrote:
> On 4/29/26 10:14, yangxingui wrote:
>>
>>
>> On 2026/4/27 12:45, Damien Le Moal wrote:
>>> On 4/27/26 10:51 AM, yangxingui wrote:
>>>>
>>>>
>>>> On 2026/4/26 6:53, Damien Le Moal wrote:
>>>>> On 4/25/26 15:04, Xingui Yang wrote:
>>>>>> When sata_link_hardreset() detects that the link is offline, it currently
>>>>>> returns immediately without distinguishing the reason. According to SATA
>>>>>> specification, the SStatus register's det filed (bits 0-3) indicates:
>>>>>>      - 0x0: No device detected, PHY not communicating
>>>>>>      - 0x1: Device detected but PHY communication not established
>>>>>>      - 0x3: Device detected and PHY communication established
>>>>>>
>>>>>> This patch helps improve device detection reliability and adds a check
>>>>>> when the link is offline but det filed shows 0x1, return -EAGAIN to
>>>>>> trigger retry, rather than giving up immediately.
>>>>>>
>>>>>> Signed-off-by: Xingui Yang <yangxingui@huawei.com>
>>>>>
>>>>> This is a pure ATA patch so please CC the linux-ide list, not the linux-scsi
>>>>> list.
>>>>
>>>> Ok.
>>>>>
>>>>> Also, please check your mail setup: your email was in my Junk folder.
>>>>
>>>> Well, patche was sent using the git send command.
>>>
>>> Not git send-email, your smtp server. It probably has something wrong with
>>> DMARC. All your emails endup in my junk folder.
>>
>> Alright, it might be related to the company's SMTP server, but this
>> configuration is fixed, and I'm not quite sure how to fix it yet.
>>
>>>
>>>>> This is preceeded by a call to sata_link_resume(), which calls
>>>>> sata_link_debounce() and that function makes sure that DET is stable. So if
>>>>> after that DET still shows that their is no PHY, there is likely a big problem
>>>>> with it and it is super slow to be established.
>>>>>
>>>>> In this case, I do not think that doing another hardreset is the right thing to
>>>>> do. Have you tried increasing the deadline for hardreset ? That deadline is used
>>>>> as the limit for the link debounce too.
>>>>>
>>>>> Do you have a specific controller/device where you see this issue ? What exactly
>>>>> is the hardware setup where you see this issue ?
>>>>
>>>> Our customer imports and verifies a new disk, there is an occasional failure in
>>>> performing a hard reset on the disk and no exception log is generated for
>>>> resume and debounce.
>>>
>>> Does this hold for all disks or for only one or some models ?
>>
>> It may be some models, It is not found on other disks.
> 
> Some model ? Which one ?

When the disk is properly connected, the log is as follows:

[   22.658068][ T1297] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 
300)
[   22.665083][ T1297] ata1.00: ATA-10: S1XE240S3N6Y9TC1AP, F66002.0, 
max UDMA/100
[   22.727017][  T806] scsi 0:0:0:0: Direct-Access     ATA 
S1XE240S3N6Y9TC1 02.0 PQ: 0 ANSI: 5
> 
> And please remove linux-scsi from your emails for this topic.

Ok.

Thanks,
Xingui
.