linux-kernel - Re: [PATCH 2/2] dt-bindings: net: dsa: qca8k: Add PORT0_PAD

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]

Date:   Sat, 18 Jul 2020 16:34:44 +0100
From:   Matthew Hagan <mnhagan88@...il.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        John Crispin <john@...ozen.org>
Cc:     Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, Jonathan McDowell <noodles@...th.li>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org
Subject: Re: [PATCH 2/2] dt-bindings: net: dsa: qca8k: Add PORT0_PAD_CTRL
 properties



On 18/07/2020 14:20, Russell King - ARM Linux admin wrote:
> On Fri, Jul 17, 2020 at 10:44:19PM +0200, John Crispin wrote:
>> in regards to the sgmii clk skew. I never understood the electrics fully I
>> am afraid, but without the patch it simply does not work. my eletcric foo is
>> unfortunately is not sufficient to understand the "whys" I am afraid.
> 
> Do you happen to know what frequency the clock is?  Is it 1.25GHz or
> 625MHz?  It sounds like it may be 1.25GHz if the edge is important.
> 
> If the clock is 1.25GHz, the "why" is because of hazards (it has
> nothing to do with delays in RGMII being propagated to SGMII).
> 
> Quite simply, a flip-flop suffers from metastability if the clock and
> data inputs change at about the same time.  Amongst the parametrics of
> flip-flops will be a data setup time, and a data hold time, referenced
> to the clock signal.
> 
> If the data changes within the setup and hold times of the clock
> changing, then the output of the flip-flop is unpredictable - it can
> latch a logic 1 or a logic 0, or oscillate between the two until
> settling on one state.
> 
> So, if data is clocked out on the rising edge of a clock signal, and
> clocked in on the rising edge of a clock signal - and the data and
> clock edges arrive within the setup and hold times at the flip-flop
> that is clocking the data in, there is a metastability hazard, and
> the data bit that is latched is unpredictable.
>
With default settings, in my case, the device will work at first, though
eventually problems arise with loss of connectivity, but constant
activity on the individual port led.

> One way to solve this is to clock data out on one edge, and clock data
> in on the opposite edge - this is used on buses such as SPI.  Other
> buses such as I2C define minimum separation between transitions between
> the SDA and SCL signals.
> 
Is there any case where it would matter which way round the clocks are,
or is it only relevant that they are on opposite edges? Why not do this
by default for qca8k devices?

> These solutions don't work with RGMII - the RGMII TXC clocks data on
> both edges.  The only solution there is to ensure a delay is introduced
> between the data and clock changes seen at the receiver - which can be
> done by introducing delays at the transmitter or at the receiver, or by
> serpentine routing of the traces to induce delays to separate the clock
> and data transitions sufficiently to avoid metastability.
> 
> If the clock is 625MHz (as with some Marvell devices for SGMII) then
> both clock edges are used, and both edges are used just like RGMII.
> Therefore, the same considerations as RGMII apply there to ensure that
> the data setup and hold times are not violated.
> 
By default, both tx and rx are set to rising edge.

Matthew