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: <b035db82-7203-4e30-8457-caa4fa1b4e97@quicinc.com>
Date: Wed, 8 Jan 2025 18:43:49 +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-27 01:14, Andrew Lunn wrote:
> On Thu, Dec 26, 2024 at 11:06:48AM +0800, Yijie Yang wrote:
>>
>>
>> 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.
> 
> If it is typically adopted, why do you need to support falling edge?
> Because we can is not a good reason. Do you have a board with a PHY
> which requires falling edge for some reason?

It's an RX-side feature and is unrelated to the PHY. As I mentioned in 
another email, it's designed to introduce a half-clock cycle delay for 
correct sampling in the IO Macro.

> 
> 	Andrew
> 

-- 
Best Regards,
Yijie