linux-kernel - Re: [PATCH v2 3/3] ata: ahci: Skip 200 ms debounce delay for AMD 300 Series Chipset SATA Controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5fb6af7b-d84f-cbae-7eb1-543f3a7e53e4@molgen.mpg.de>
Date:   Wed, 23 Mar 2022 07:55:48 +0100
From:   Paul Menzel <pmenzel@...gen.mpg.de>
To:     Damien Le Moal <damien.lemoal@...nsource.wdc.com>,
        Mario Limonciello <Mario.Limonciello@....com>
Cc:     Hans de Goede <hdegoede@...hat.com>, linux-ide@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        Nehal-bakulchandra Shah <Nehal-bakulchandra.Shah@....com>
Subject: Re: [PATCH v2 3/3] ata: ahci: Skip 200 ms debounce delay for AMD 300
 Series Chipset SATA Controller

Dear Damien,


Am 23.03.22 um 06:01 schrieb Damien Le Moal:
> On 3/22/22 06:51, Limonciello, Mario wrote:
>> [Public]
>>
>>> -----Original Message-----
>>> From: Paul Menzel <pmenzel@...gen.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.
> 
> Paul,
> 
> 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.

> It would be nice if you can test though.

Of course, I am going to that either way.


Kind regards,

Paul