On 3/23/22 17:43, Paul Menzel wrote: > Dear Damien, > > > Thank you for sending these patches. > > Am 23.03.22 um 09:17 schrieb Damien Le Moal: >> This series removes the long link debounce delays by default for all >> adapters, except for those known to require these delays >> (e.g. ata_piix). > > Is it know, or just a theory? > >> The first 2 patches are code cleanup improving the interface of several >> functions handling delays. >> >> Patch 3 removes the long delay in sata_link_resume() and reverses the >> link flag ATA_LFLAG_NO_DEBOUNCE_DELAY to ATA_LFLAG_DEBOUNCE_DELAY for >> adapters to request the delay if needed. >> >> Patch 4 improves sata_link_debounce() by shortening the link stability >> test, unless the link has the ATA_LFLAG_DEBOUNCE_DELAY flag set. >> >> This series was tested on a machine with 2 AHCI adapters (Intel and >> Marvell) with a port-multiplier box attached to cover that case too. > > It’d be great if you gave an example benchmark. No need for a benchmark. This is not hot path stuff. This code runs only during device discovery on boot and on resume after suspend. So apply the patches and reboot, check dmesg if you see errors or not and if your disks are all there. Same after a suspend+resume. > >> Comments and lots of testing are welcome ! >> >> Damien Le Moal (4): >> ata: libata-sata: Simplify sata_link_resume() interface >> ata: libata-sata: Introduce struct sata_deb_timing >> ata: libata-sata: Remove debounce delay by default >> ata: libata-sata: Improve sata_link_debounce() > > […] > > I am wondering how sure we can be, there won’t be any regressions? Not > having the boot disk detected is quite a serious issue/regression, and > it should be made easy for users to fix that without having to rebuild > the Linux kernel. A Linux kernel CLI parameter to enable the delay would > be helpful for effected users. > > > Kind regards, > > Paul -- Damien Le Moal Western Digital Research
