Re: [PATCH v3 2/2] scsi: libsas: Add linkrate and sas_addr change detection in rediscover

[yangxingui <yangxingui@huawei.com>]

On 2026/5/22 17:16, John Garry wrote:
> On 21/05/2026 10:04, yangxingui wrote:
>>>
>>> Can this be reused (to lose and find the device with updated info)? 
>>> Or why not good enough?
>>>
>>> I don't know why you need full revalidation.
>>
>> Hi, John
>> As the commit log. The existing pattern (unregister + 
>> sas_discover_new) handles the "replace" case where the SAS address 
>> changes completely, implying a different device.
>> For the flutter case where we detect linkrate/sas_addr changes,
> 
> Can you please clarify this: you say that the existing pattern handles 
> "replace" case where the SAS address changes completely, and then 
> flutter case covers sas_addr changes.
> 
> What is the difference in the SAS address changes between the two cases?
> 
Hi, John

The difference is in when the SAS address change is detected:
Replace case:
- Detected immediately by the initial SMP DISCOVER response
- New SAS address differs from stored phy->attached_sas_addr

Flutter case:
- Initial SMP DISCOVER shows SAS address matching stored 
phy->attached_sas_addr
- Linkrate may change
- After sas_ex_phy_discover() refreshes phy info, child device address 
and linkrate may mismatched with refreshed phy info

Additional issue with Replace flow:
The existing replace code path also suffers from the same sysfs_warn_dup 
issue I mentioned earlier. sas_unregister_devs_sas_addr() only marks the 
device as gone and adds it to destroy_list. The actual sysfs cleanup 
happens later in sas_destruct_devices(). Calling sas_discover_new() 
immediately after unregister causes sysfs duplicate directory errors.

We need to optimize the replace process.

Thanks,
Xingui