When a device attached to an expander phy experiences a linkrate change
(e.g., due to cable reconnection or negotiation), the current code in
sas_rediscover_dev() treats it as "broadcast flutter" and takes no action
if the SAS address and device type remain unchanged.

However, for drivers like hisi_sas, the ITCT entry needs to be updated
to reflect the new linkrate. Without this update, the hardware continues
using stale linkrate information, which can cause performance issues or
protocol errors.

This series introduces a new LLDD callback lldd_dev_info_update() to
notify the low-level driver when a device's information changes, allowing
the driver to update its hardware structures accordingly. The callback
is designed to be extensible for future device information updates beyond
linkrate changes.

Changes from v1:
- Split into three patches.

Xingui Yang (3):
  scsi: libsas: refactor sas_ex_to_ata() using new helper
    sas_ex_to_dev()
  scsi: libsas: add lldd_dev_info_update callback for device info
    changes
  scsi: hisi_sas: add support for dev info update notification

 drivers/scsi/hisi_sas/hisi_sas_main.c | 16 ++++++++++++++++
 drivers/scsi/libsas/sas_discover.c    | 12 ++++++++++++
 drivers/scsi/libsas/sas_expander.c    | 25 +++++++++++++++++++------
 drivers/scsi/libsas/sas_internal.h    |  2 ++
 include/scsi/libsas.h                 |  1 +
 5 files changed, 50 insertions(+), 6 deletions(-)

-- 
2.43.0

On 13/05/2026 03:16, Xingui Yang wrote:
> When a device attached to an expander phy experiences a linkrate change
> (e.g., due to cable reconnection or negotiation), the current code in
> sas_rediscover_dev() treats it as "broadcast flutter" and takes no action
> if the SAS address and device type remain unchanged.

Can sas_rediscover_dev() check the linkrate (vs expected) to understand 
that this flutter has renegotiated the linkrate and then consider it not 
just a flutter?

> 
> However, for drivers like hisi_sas, the ITCT entry needs to be updated
> to reflect the new linkrate. Without this update, the hardware continues
> using stale linkrate information, which can cause performance issues or
> protocol errors.
> 
> This series introduces a new LLDD callback lldd_dev_info_update() to
> notify the low-level driver when a device's information changes, allowing
> the driver to update its hardware structures accordingly. The callback
> is designed to be extensible for future device information updates beyond
> linkrate changes.
> 
> Changes from v1:
> - Split into three patches.
> 
> Xingui Yang (3):
>    scsi: libsas: refactor sas_ex_to_ata() using new helper
>      sas_ex_to_dev()
>    scsi: libsas: add lldd_dev_info_update callback for device info
>      changes
>    scsi: hisi_sas: add support for dev info update notification
> 
>   drivers/scsi/hisi_sas/hisi_sas_main.c | 16 ++++++++++++++++
>   drivers/scsi/libsas/sas_discover.c    | 12 ++++++++++++
>   drivers/scsi/libsas/sas_expander.c    | 25 +++++++++++++++++++------
>   drivers/scsi/libsas/sas_internal.h    |  2 ++
>   include/scsi/libsas.h                 |  1 +
>   5 files changed, 50 insertions(+), 6 deletions(-)
>

On 2026/5/13 15:29, John Garry wrote:
> On 13/05/2026 03:16, Xingui Yang wrote:
>> When a device attached to an expander phy experiences a linkrate change
>> (e.g., due to cable reconnection or negotiation), the current code in
>> sas_rediscover_dev() treats it as "broadcast flutter" and takes no action
>> if the SAS address and device type remain unchanged.
> 
> Can sas_rediscover_dev() check the linkrate (vs expected) to understand 
> that this flutter has renegotiated the linkrate and then consider it not 
> just a flutter?

Hi, John
Theoretically, it is possible. As early as 2019, Jason attempted to 
propose the solution you mentioned. He conducted a relatively 
comprehensive assessment for flutter, including scenarios where the SAS 
address changes or the ATA ID changes. However, in actual use, such 
situations almost never occur unless there is an extremely short time 
window during which the drive is swapped or a new SATA drive is 
replaced. Because this solution is associated with other modifications 
and may have significant impacts, it has not been adopted.

https://lore.kernel.org/linux-scsi/20190130082412.9357-6-yanaijie@huawei.com/

Currently, scenarios involving changes in linkrate are relatively more 
common, and such situations can be easily reproduced by manually 
adjusting the linkrate by sysfs. Therefore, a less impactful synchronous 
update solution was adopted.

Thanks.
Xingui

On 13/05/2026 09:14, yangxingui wrote:
> 
> 
> 
> On 2026/5/13 15:29, John Garry wrote:
>> On 13/05/2026 03:16, Xingui Yang wrote:
>>> When a device attached to an expander phy experiences a linkrate change
>>> (e.g., due to cable reconnection or negotiation), the current code in
>>> sas_rediscover_dev() treats it as "broadcast flutter" and takes no 
>>> action
>>> if the SAS address and device type remain unchanged.
>>
>> Can sas_rediscover_dev() check the linkrate (vs expected) to 
>> understand that this flutter has renegotiated the linkrate and then 
>> consider it not just a flutter?
> 
> Hi, John
> Theoretically, it is possible. As early as 2019, Jason attempted to 
> propose the solution you mentioned. He conducted a relatively 
> comprehensive assessment for flutter, including scenarios where the SAS 
> address changes or the ATA ID changes. However, in actual use, such 
> situations almost never occur unless there is an extremely short time 
> window during which the drive is swapped or a new SATA drive is 
> replaced. Because this solution is associated with other modifications 
> and may have significant impacts, it has not been adopted.
> 
> https://urldefense.com/v3/__https://lore.kernel.org/linux- 
> scsi/20190130082412.9357-6-yanaijie@huawei.com/__;!!ACWV5N9M2RV99hQ! 
> K7CIIOxMVXErIMxcZlvm10YX3EVqp0rhSbh_ARyqnaFDmtaqqJtoLTJQui0- 
> Ox_URh97f8oyREG8htBVo2aC3Ew$
> Currently, scenarios involving changes in linkrate are relatively more 
> common, and such situations can be easily reproduced by manually 
> adjusting the linkrate by sysfs. Therefore, a less impactful synchronous 
> update solution was adopted.
> 

What Jason did was to check if same device for flutter, which is not 
really the same thing as what you want.

I just don't like these special case callbacks which you propose, as 
they seem fragile and too specialized.

Is it possible to just check the linkrate and mark the device as gone 
and rediscover when this flutter occurs occurs?

On 2026/5/14 17:35, John Garry wrote:
> On 13/05/2026 09:14, yangxingui wrote:
>>
>>
>>
>> On 2026/5/13 15:29, John Garry wrote:
>>> On 13/05/2026 03:16, Xingui Yang wrote:
>>>> When a device attached to an expander phy experiences a linkrate change
>>>> (e.g., due to cable reconnection or negotiation), the current code in
>>>> sas_rediscover_dev() treats it as "broadcast flutter" and takes no 
>>>> action
>>>> if the SAS address and device type remain unchanged.
>>>
>>> Can sas_rediscover_dev() check the linkrate (vs expected) to 
>>> understand that this flutter has renegotiated the linkrate and then 
>>> consider it not just a flutter?
>>
>> Hi, John
>> Theoretically, it is possible. As early as 2019, Jason attempted to 
>> propose the solution you mentioned. He conducted a relatively 
>> comprehensive assessment for flutter, including scenarios where the 
>> SAS address changes or the ATA ID changes. However, in actual use, 
>> such situations almost never occur unless there is an extremely short 
>> time window during which the drive is swapped or a new SATA drive is 
>> replaced. Because this solution is associated with other modifications 
>> and may have significant impacts, it has not been adopted.
>>
>> https://urldefense.com/v3/__https://lore.kernel.org/linux- 
>> scsi/20190130082412.9357-6-yanaijie@huawei.com/__;!!ACWV5N9M2RV99hQ! 
>> K7CIIOxMVXErIMxcZlvm10YX3EVqp0rhSbh_ARyqnaFDmtaqqJtoLTJQui0- 
>> Ox_URh97f8oyREG8htBVo2aC3Ew$
>> Currently, scenarios involving changes in linkrate are relatively more 
>> common, and such situations can be easily reproduced by manually 
>> adjusting the linkrate by sysfs. Therefore, a less impactful 
>> synchronous update solution was adopted.
>>
> 
> What Jason did was to check if same device for flutter, which is not 
> really the same thing as what you want.
> 
> I just don't like these special case callbacks which you propose, as 
> they seem fragile and too specialized.
> 
> Is it possible to just check the linkrate and mark the device as gone 
> and rediscover when this flutter occurs occurs?

Hi, John.
I have updated a new version according to your suggestions.

Thanks,
Xingui
.

On 2026/5/14 17:35, John Garry wrote:
> On 13/05/2026 09:14, yangxingui wrote:
>>
>>
>>
>> On 2026/5/13 15:29, John Garry wrote:
>>> On 13/05/2026 03:16, Xingui Yang wrote:
>>>> When a device attached to an expander phy experiences a linkrate change
>>>> (e.g., due to cable reconnection or negotiation), the current code in
>>>> sas_rediscover_dev() treats it as "broadcast flutter" and takes no 
>>>> action
>>>> if the SAS address and device type remain unchanged.
>>>
>>> Can sas_rediscover_dev() check the linkrate (vs expected) to 
>>> understand that this flutter has renegotiated the linkrate and then 
>>> consider it not just a flutter?
>>
>> Hi, John
>> Theoretically, it is possible. As early as 2019, Jason attempted to 
>> propose the solution you mentioned. He conducted a relatively 
>> comprehensive assessment for flutter, including scenarios where the 
>> SAS address changes or the ATA ID changes. However, in actual use, 
>> such situations almost never occur unless there is an extremely short 
>> time window during which the drive is swapped or a new SATA drive is 
>> replaced. Because this solution is associated with other modifications 
>> and may have significant impacts, it has not been adopted.
>>
>> https://urldefense.com/v3/__https://lore.kernel.org/linux- 
>> scsi/20190130082412.9357-6-yanaijie@huawei.com/__;!!ACWV5N9M2RV99hQ! 
>> K7CIIOxMVXErIMxcZlvm10YX3EVqp0rhSbh_ARyqnaFDmtaqqJtoLTJQui0- 
>> Ox_URh97f8oyREG8htBVo2aC3Ew$
>> Currently, scenarios involving changes in linkrate are relatively more 
>> common, and such situations can be easily reproduced by manually 
>> adjusting the linkrate by sysfs. Therefore, a less impactful 
>> synchronous update solution was adopted.
>>
> 
> What Jason did was to check if same device for flutter, which is not 
> really the same thing as what you want.

Yes. Jason's modification check items include whether the link rate 
changes and whether the devices are the same.

> 
> I just don't like these special case callbacks which you propose, as 
> they seem fragile and too specialized.
Yes, perhaps, but the information about the remote device is obtained 
through smp discover. lldd cannot directly obtain information changes, 
so a notification call has been added to update it.

> 
> Is it possible to just check the linkrate and mark the device as gone 
> and rediscover when this flutter occurs occurs?

Of course, if you suggest doing so, Jason's related patch has also been 
verified to solve this issue.

Thanks,
Xingui