On Wed, May 29, 2024 at 07:47:13AM +0000, Ricky WU wrote: > We tried this patch as below situation: > 1.keep the SDEX card enter S3 then resume ->PASS > 2. on S3 mode insert the SDEX card then resume -> PASS > 3.on S3 mode remove the SDEX card then resume -> PASS > 4.replace card on S3 mode (different brand) ->PASS > 5.replace card on S3 mode (same brand and same capacity) ->FAIL > Can not see the msg "device replace during system sleep" > > Against 5 we found a issue, most card not declare capability > "PCI_EXT_CAP_ID_DSN", even if there is the capability the config space > value are 0, cause pci_get_dsn() return 0 normally. > However these cards can show the SN on CrystalDiskInfo. Thanks for testing. That's the expected behavior so I went ahead and submitted the patch: https://lore.kernel.org/all/a1afaa12f341d146ecbea27c1743661c71683833.1716992815.git.lukas@xxxxxxxxx/ If vendors neglect to populate the Device Serial Number in config space, it's zero and we cannot use it to detect device replacement. A DSN of "all zeroes" is a reserved value: "The all-zeros EUI-48 value (00-00-00-00-00-00) and EUI-64 value (00-00-00-00-00-00-00-00), though assigned to an organization, have not been and will not be used by that assignee as an EUI. (They can be considered as assigned to the IEEE Registration Authority.)" https://standards-support.ieee.org/hc/en-us/articles/4888705676564-Guidelines-for-Use-of-Extended-Unique-Identifier-EUI-Organizationally-Unique-Identifier-OUI-and-Company-ID-CID The serial numbers of block devices shown by lsblk are not PCI serial numbers, but specific to the NVME or SCSI or ATA layer. I'll look into adding a PCI helper which those layers can call on resume if they detect a change in device identity, but that's independent from the patch I just submitted. Thanks, Lukas
