On 3/31/22 23:42, Paul Menzel wrote: > 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@xxxxxxxxxxxxx> >>>>>>> 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. I am waiting for 5.18-rc1 to rebase the patches and re-post them. Given reviewed-by and tested-by tags, I will queue them for 5.19. With that in mind, I am not planning to apply your previous patches for 5.18, as they would conflict and would only end up being churn since the delay removal by default will undo your changes. -- Damien Le Moal Western Digital Research
