netdev - Re: [PATCH 07/10] dt-bindings: phy: add DT binding for Microsemi Ocelot SerDes muxing

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 6 Aug 2018 14:47:59 +0200
From:   Quentin Schulz <quentin.schulz@...tlin.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     alexandre.belloni@...tlin.com, ralf@...ux-mips.org,
        paul.burton@...s.com, jhogan@...nel.org, robh+dt@...nel.org,
        mark.rutland@....com, davem@...emloft.net, kishon@...com,
        f.fainelli@...il.com, linux-mips@...ux-mips.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, allan.nielsen@...rosemi.com,
        thomas.petazzoni@...tlin.com
Subject: Re: [PATCH 07/10] dt-bindings: phy: add DT binding for Microsemi
 Ocelot SerDes muxing

Hi Andrew,

On Wed, Aug 01, 2018 at 04:31:47PM +0200, Andrew Lunn wrote:
> > > Maybe this should be serdes-mux? The SERDES itself should have some
> > > registers somewhere. If you ever decide to make use of phylink,
> > > e.g. to support SFP, you are going to need to know if the SERDES is
> > > up. So you might need to add the actual SERDES device, in addition to
> > > the mux for the SERDES.
> > > 
> > 
> > I'm not sure to follow.
> > 
> > To be honest, I might have mislead you. The whole configuration of the
> > serdes is in the hsio register address space. For now, muxing is the
> > only reason there is a driver for the serdes but there are other things
> > that can be configured (though not used yet): de/serializer, input/output
> > buffers, PLL, ... configuration registers for the SerDes.
> 
> When you are using the SERDES for networking, you need to know if the
> SERDES has achieved sync. For example, when the SERDES connects to an
> optical SFP module, the SERDES bit stream continues unmodified over
> the optical link to the SERDES in the peer. The optical module can
> tell you if it is receiving optical power, but it cannot tell you if
> the optical signal makes any sense. The SERDES however knows how to
> decode the bitstream, sync to it, etc. So you need some registers in
> the SERDES to get this status information. Typically, you can also get
> access to the SGMII/1000Base-X code word, so you can do
> auto-negotiation, or know if you need to send each bit 10 or 100 times
> in order to do 100Mbps or 10Mbps. If you are connecting to a PHY which
> can do > 1Gbps, you need to change the SERDES between SGMII,
> 1000Base-X, 2500Base-X, etc. Before you can say the link is up, you
> want the PHY to tell you it has link to its peer PHY, and you want to
> know the SERDES is ready. Typically the SERDES is last, since you
> don't know what to configure the SERDES to until the PHY is finished
> negotiating the link to its peer.
> 
> If you look at any of the Marvell SERDES interfaces, found in PHYs or
> switches, there are dozens of registers for controlling the SERDES.
> 
> Now, it could be we don't have a clear definition of what a SERDES
> is. The Marvell documents has a lot in its definition of SERDES, where
> as what you could be purely a 'dumb' parallel to serial convert, and
> all the rest of the logic is in the Ethernet MAC and the PCIe device?
> 
> Now, back to my original point. Where are the registers for 'the rest
> of this logic'? If they are in the MAC address space, we don't have a
> problem. If they are somewhere else, maybe you will need to add
> another device. What is this device called? That is why i'm trying to
> differentiate between the 'SERDES-MUX' and the 'SERDES'.
> 

If I've correctly read the datasheet of the switch, the sync status bit
is in the MAC address space. Same for 1000BASE-X/SGMII, autonegotiation.

The point I was trying to make was that this driver isn't only for
"muxing". There are also a handful of registers for
(electronically-related ?) features of SerDes (e.g. "control of phase
regulator logic", "deserializer phase control", a few
thresholds/hysteresis/frequencies, etc...

I understand that "serdes" isn't also fully matching the work done by
this driver as some features are handled within the MAC controller
address space.

Let me know if something bothers you/does not make sense,
Thanks,
Quentin

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)