netdev - Re: [PATCH 0/3] Support tuning the RX sampling swap of the MAC.

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: <2aa2c6dd-e3f2-4b9b-8572-20b801edef81@quicinc.com>
Date: Thu, 26 Dec 2024 11:06:48 +0800
From: Yijie Yang <quic_yijiyang@...cinc.com>
To: Andrew Lunn <andrew@...n.ch>
CC: Vinod Koul <vkoul@...nel.org>, Andrew Lunn <andrew+netdev@...n.ch>,
        "David
 S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>, Jakub
 Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, Rob Herring
	<robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley
	<conor+dt@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio
	<konradybcio@...nel.org>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Jose Abreu <joabreu@...opsys.com>,
        Maxime Coquelin
	<mcoquelin.stm32@...il.com>, <netdev@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        <linux-stm32@...md-mailman.stormreply.com>,
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 0/3] Support tuning the RX sampling swap of the MAC.



On 2024-12-26 01:49, Andrew Lunn wrote:
> On Wed, Dec 25, 2024 at 06:04:44PM +0800, Yijie Yang wrote:
>> The Ethernet MAC requires precise sampling times at Rx, but signals on the
>> Rx side after transmission on the board may vary due to different hardware
>> layouts. The RGMII_CONFIG2_RX_PROG_SWAP can be used to switch the sampling
>> occasion between the rising edge and falling edge of the clock to meet the
>> sampling requirements.
> 
> The RGMII specification says that RD[3:0] pins are sampled on the
> rising edge for bits 3:0 and falling edge for bits 7:4.
> 
> Given this is part of the standard, why would you want to do anything
> else?
> 
> Is this maybe another symptom of having the RGMII delays messed up?
> 
> Anyway, i don't see a need for this property, unless you are working
> with a PHY which breaks the RGMII standard, and has its clock
> reversed?

Please correct me if there are any errors. As described in the Intel and 
TI design guidelines, Dual Data Rate (DDR), which samples at both edges 
of the clock, is primarily used for 1Gbps speeds. For 100Mbps and 10Mbps 
speeds, Single Data Rate (SDR), which samples at the rising edge of the 
clock, is typically adopted.
This patch set introduces such a flag mainly for 100M/10M speeds, as 
described in the cover letter.

> 
> 	Andrew

-- 
Best Regards,
Yijie