devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan McDowell <noodles@earth.li>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
	Matthew Hagan <mnhagan88@gmail.com>, Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	linux@armlinux.org.uk, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, John Crispin <john@phrozen.org>,
	Rob Herring <robh+dt@kernel.org>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH 2/2] dt-bindings: net: dsa: qca8k: Add PORT0_PAD_CTRL properties
Date: Fri, 17 Jul 2020 08:49:35 +0100	[thread overview]
Message-ID: <20200717074934.GH23489@earth.li> (raw)
In-Reply-To: <20200716223822.yptldqqn36fbp2i7@skbuf>

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.

  reply	other threads:[~2020-07-17  7:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2e1776f997441792a44cd35a16f1e69f848816ce.1594668793.git.mnhagan88@gmail.com>
2020-07-13 20:50 ` [PATCH 2/2] dt-bindings: net: dsa: qca8k: Add PORT0_PAD_CTRL properties Matthew Hagan
2020-07-16 22:09   ` Jakub Kicinski
2020-07-16 22:32     ` Andrew Lunn
2020-07-17 19:26       ` Matthew Hagan
2020-07-17 20:02         ` Florian Fainelli
2020-07-18 13:00         ` Vladimir Oltean
2020-07-21  1:59         ` Rob Herring
2020-07-16 22:38     ` Vladimir Oltean
2020-07-17  7:49       ` Jonathan McDowell [this message]
2020-07-17 20:29     ` Matthew Hagan
2020-07-17 20:39       ` Florian Fainelli
2020-07-17 20:48         ` John Crispin
2020-07-17 20:44       ` John Crispin
2020-07-18 13:20         ` Russell King - ARM Linux admin
2020-07-18 14:44           ` Andrew Lunn
2020-07-18 15:08             ` Russell King - ARM Linux admin
2020-07-18 15:34           ` Matthew Hagan
2020-07-16 22:19   ` Florian Fainelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200717074934.GH23489@earth.li \
    --to=noodles@earth.li \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=john@phrozen.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mnhagan88@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=vivien.didelot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).