netdev - Re: [PATCH net 1/3] amd-xgbe: Yellow carp devices do not need rrc

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] [day] [month] [year] [list]

Date:   Sat, 8 Oct 2022 23:57:46 +0530
From:   Raju Rangoju <Raju.Rangoju@....com>
To:     Jakub Kicinski <kuba@...nel.org>,
        Tom Lendacky <thomas.lendacky@....com>
Cc:     Shyam-sundar.S-k@....com, davem@...emloft.net,
        netdev@...r.kernel.org, rrangoju@....com
Subject: Re: [PATCH net 1/3] amd-xgbe: Yellow carp devices do not need rrc



On 10/7/2022 5:56 AM, Jakub Kicinski wrote:
> On Thu, 6 Oct 2022 09:32:34 -0500 Tom Lendacky wrote:
>> On 10/6/22 08:54, Raju Rangoju wrote:
>>> Yellow carp devices disables the CDR workaround path,
>>> receiver reset cycle is not needed in such cases.
>>> Hence, avoid issuing rrc on Yellow carp platforms.
> 
> Not entirely clear why this is a Fix, TBH.
> 
> What harm comes from doing the reset? You need to describe
> the user-observable harm if the patch is a fix.

Link stability issues are noticed if RRC is issued on Yellow carp 
platforms. Since the CDR workaround is disabled on these platforms, the 
Receiver Reset Cycle is not needed.

> 
>>> Fixes: 47f164deab22 ("amd-xgbe: Add PCI device support")
>>
>> That is the wrong Fixes: tag. Yellow Carp support was added with commit
>>
>> dbb6c58b5a61 ("net: amd-xgbe: Add Support for Yellow Carp Ethernet device")
>>
>> However, the changes to allow updating the version data were made with
>>
>> 6f60ecf233f9 ("net: amd-xgbe: Disable the CDR workaround path for Yellow Carp Devices")
>>
>> so that is the tag most likely needed should you want this to be able to
>> go to stable.
> 
> FWIW the Fixes tag should point to the commit where the bug is
> introduced, not where the patch will apply. The automation will
> figure out where it applies.
> 
>> With a change to the Fixes: tag:
>>
>> Acked-by: Tom Lendacky <thomas.lendacky@....com>
> 
> These devices are only present on SoCs? Changing global data during
> probe looks odd.
>