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
| ||
|
Date: Fri, 17 Jul 2020 08:49:35 +0100 From: Jonathan McDowell <noodles@...th.li> To: Vladimir Oltean <olteanv@...il.com> Cc: Jakub Kicinski <kuba@...nel.org>, Matthew Hagan <mnhagan88@...il.com>, Andrew Lunn <andrew@...n.ch>, Vivien Didelot <vivien.didelot@...il.com>, Florian Fainelli <f.fainelli@...il.com>, "David S. Miller" <davem@...emloft.net>, linux@...linux.org.uk, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, John Crispin <john@...ozen.org>, 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 Fri, Jul 17, 2020 at 01:38:22AM +0300, Vladimir Oltean wrote: > On Thu, Jul 16, 2020 at 03:09:25PM -0700, Jakub Kicinski wrote: > > On Mon, 13 Jul 2020 21:50:26 +0100 Matthew Hagan wrote: > > > +- qca,sgmii-rxclk-falling-edge: If present, sets receive clock phase to > > > + falling edge. > > > +- qca,sgmii-txclk-falling-edge: If present, sets transmit clock phase to > > > + falling edge. > > > > These are not something that other vendors may implement and therefore > > something we may want to make generic? Andrew? > > > > It was asked before whether this device uses source-synchronous clock > for SGMII or if it recovers the clock from the data stream. Just "pass" > was given for a response. > > https://patchwork.ozlabs.org/project/netdev/patch/8ddd76e484e1bedd12c87ea0810826b60e004a65.1591380105.git.noodles@earth.li/ > > One can, in principle, tell easily by examining schematics. If the SGMII > is only connected via RX_P, RX_N, TX_P, TX_N (and optionally there might > be external reference clocks for the SERDES lanes, but these are not > part of the data connection itself), then the clock is recovered from > the serial data stream, and we have no idea what "SGMII delays" are. > > If the schematic shows 2 extra clock signals, one in each transmit > direction, then this is, in Russell King's words, "a new world of RGMII > delay pain but for SGMII". In principle I would fully expect clock skews > to be necessary for any high-speed protocol with source-synchronous > clocking. The problem, really, is that we aren't ready to deal with this > properly. We aren't distinguishing "SGMII with clock" from "SGMII > without clock" in any way. We have no idea who else is using such a > thing. Depending on the magnitude of this new world, it may be wise to > let these bindings go in as-is, or do something more kernel-wide... I don't have the schematic for the device I've been working with, but the switch data sheet just shows 2 differential pairs (input/output) for the SerDes Interface (whereas the RGMII interfaces *are* listed with their clocks). J. -- I just Fedexed my soul to hell. I'm *real* clever.
Powered by blists - more mailing lists