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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 4 Jan 2022 17:36:55 +0900
From:   Damien Le Moal <damien.lemoal@...nsource.wdc.com>
To:     Paul Menzel <pmenzel@...gen.mpg.de>
Cc:     linux-ide@...r.kernel.org,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Guenter Roeck <groeck@...omium.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/3] ahci: AMD A85 FCH (Hudson D4): Skip 200 ms
 debounce delay in `sata_link_resume()`

On 12/31/21 16:08, Paul Menzel wrote:
> Dear Damien,
> 
> 
> Am 31.12.21 um 01:52 schrieb Damien Le Moal:
>> On 12/30/21 20:08, Paul Menzel wrote:
>>>>>    	board_ahci_nomsi,
>>>>>    	board_ahci_noncq,
>>>>>    	board_ahci_nosntf,
>>>>> @@ -141,6 +142,13 @@ static const struct ata_port_info ahci_port_info[] = {
>>>>>    		.udma_mask	= ATA_UDMA6,
>>>>>    		.port_ops	= &ahci_ops,
>>>>>    	},
>>>>> +	[board_ahci_nodbdelay] = {
>>>>> +		.flags		= AHCI_FLAG_COMMON,
>>>>> +		.link_flags	= ATA_LFLAG_NO_DB_DELAY,
>>>>> +		.pio_mask	= ATA_PIO4,
>>>>> +		.udma_mask	= ATA_UDMA6,
>>>>> +		.port_ops	= &ahci_ops,
>>>>> +	},
>>>>>    	[board_ahci_nomsi] = {
>>>>>    		AHCI_HFLAGS	(AHCI_HFLAG_NO_MSI),
>>>>>    		.flags		= AHCI_FLAG_COMMON,
>>>>> @@ -437,6 +445,7 @@ static const struct pci_device_id ahci_pci_tbl[] = {
>>>>>    		board_ahci_al },
>>>>>    	/* AMD */
>>>>>    	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_HUDSON2_SATA_IDE), board_ahci },
>>>>> +	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_HUDSON2_SATA_AHCI), board_ahci_nodbdelay },
>>>>
>>>> Patch 1 introduces this macro in pci_ids.h, but it is used only here. So
>>>> to keep with the current style in this structure, drop the macro (so
>>>> drop patch 1).
>>>
>>> I wait for your answer of the second patch, and then I am going to sent v4.
>>
>> Let's use the numeric value. No macro definition needed.
> 
> Alright. I am going to follow the maintainers wishes.
> 
>>>>>    	{ PCI_VDEVICE(AMD, 0x7900), board_ahci }, /* AMD CZ */
>>>>>    	{ PCI_VDEVICE(AMD, 0x7901), board_ahci_mobile }, /* AMD Green Sardine */
>>>>>    	/* AMD is using RAID class only for ahci controllers */
>>>
>>> Do you have a AHCI device at hand, where you could also test if
>>> everything works fine without the delay?
>>
>> Unfortunately, I do not have any board with this adapter.
> 
> Sorry, we misunderstand each other. (I wrote a reply to my own patch [1].)
> 
> I think the delay is not necessary for any modern AHCI controller. It’d 
> be great, if you could test, if it’s also true on the systems you have 
> by just skipping the delay.

I need to figure out how to safely test suspend/resume remotely (working
from home) :)

It would indeed be great to have the default as "no delay on resume" and
add the delay only for chipsets that need it. However, it is unclear
which chipset need the delay, right ? So I think we are stuck with
switching chipsets to "no delay" one by one by testing. Once the
majority of drivers are converted, we can reverse the default to be "no
delay" and mark untested drivers as needing the delay.

> 
> 
> Kind regards,
> 
> Paul
> 
> 
> [1]: 
> https://lore.kernel.org/linux-ide/20211227162658.11314-2-pmenzel@molgen.mpg.de/T/#m697d2121463a4c946730e6b83940e12d6d7e6700


-- 
Damien Le Moal
Western Digital Research

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ