Messages in this thread | | | Date | Thu, 31 Mar 2022 16:42:40 +0200 | Subject | Re: [PATCH v2 3/3] ata: ahci: Skip 200 ms debounce delay for AMD 300 Series Chipset SATA Controller | From | Paul Menzel <> |
| |
Dear Damien,
Am 23.03.22 um 09:36 schrieb Paul Menzel:
> Am 23.03.22 um 09:24 schrieb Damien Le Moal: >> On 3/23/22 15:55, Paul Menzel wrote: > >>> Am 23.03.22 um 06:01 schrieb Damien Le Moal: >>>> On 3/22/22 06:51, Limonciello, Mario wrote: > >>>>>> -----Original Message----- >>>>>> From: Paul Menzel <pmenzel@molgen.mpg.de> >>>>>> Sent: Monday, March 21, 2022 16:25 >>> >>> […] >>> >>>>> I seem to recall that we were talking about trying to drop the >>>>> debounce delay for everything, weren't we? >>>>> >>>>> So perhaps it would be right to add a 4th patch in the series to do >>>>> just that. Then If this turns out to be problematic for >>>>> anything other than the controllers in the series that you >>>>> identified as not problematic then that 4th patch can >>>>> potentially be reverted alone? >>>> >>>> Not quite everything :) But you are right, let's try to switch the >>>> default to no delay. I will be posting patches today for that. >>>> With these patches, your patches are not necessary anymore as the AMD >>>> chipset falls under the default no-delay. >>> >>> I am all for improving the situation for all devices, but I am unable to >>> judge the regression potential of changing this, as it affects a lot of >>> devices. I guess it’d would go through the next tree, and hopefully the >>> company QA teams can give it a good spin. I hoped that my patches, as I >>> have tested them, and AMD will hopefully too, could go into the current >>> merge window. >> >> Yes, correct, the plan is to get the generic series queued as soon >> as rc1 so that it can spend plenty of time in linux-next for people >> to test. That will hopefully reduce the risk of breaking things in >> the field. Same for the default LPM change. > > But 5.18 or 5.19? If 5.18, sounds good to me, if 5.19, I’d be great if > my patches go into 5.18 cycle, as they have been tested, and it would > mean the whole change gets tested more widely already. > >> With the default removal of the debounce delay, your patches addressing >> only the AMD adapter are not needed anymore: this adapter will not have a >> debounce delay unless the ATA_LFLAG_DEBOUNCE_DELAY flag is set. > > Yes, I understand.
The merge window for Linux 5.18 is going to close in three days this Sunday. It’d be really great if my patches, tested on hardware, could go into that.
>>>> It would be nice if you can test though. >>> >>> Of course, I am going to that either way. >> >> Series posted with you on CC. Please test ! > > Thank you. I am going to test it in the coming days, and report back. > > Maybe more people should be put in Cc (Dell, Lenovo, IBM, x86 subsystem) > with a request to test this? Thank you for the patches, which are a big improvement. Let’s hope, you can re-roll them, so they get into Linux very soon for everyone’s benefit.
Kind regards,
Paul
| |