netdev - Re: net: phy: Dealing with 88e1543 dual-port mode

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:   Fri, 20 Nov 2020 00:40:48 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Tobias Waldekranz <tobias@...dekranz.com>
Cc:     Maxime Chevallier <maxime.chevallier@...tlin.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Antoine Tenart <atenart@...nel.org>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        netdev@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: net: phy: Dealing with 88e1543 dual-port mode

On Fri, Nov 20, 2020 at 01:11:12AM +0100, Tobias Waldekranz wrote:
> On Thu, Nov 19, 2020 at 23:16, Russell King - ARM Linux admin <linux@...linux.org.uk> wrote:
> > On Thu, Nov 19, 2020 at 11:43:39PM +0100, Tobias Waldekranz wrote:
> >> On Thu, Nov 19, 2020 at 16:24, Maxime Chevallier <maxime.chevallier@...tlin.com> wrote:
> >> > I don't think we have a way to distinguish from the DT if we are in
> >> > SGMII-to-Fibre or in SGMII-to-{Copper + Fibre}, since the description is
> >> > the same, we don't have any information in DT about wether or not the
> >> > PHY is wired to a Copper RJ45 port.
> >> >
> >> > Maybe we should have a way to indicate if a PHY is wired to a Copper
> >> > port in DT ?
> >> 
> >> Do you mean something like:
> >> 
> >> SGMII->SGMII (Fibre):
> >> ethernet-phy@0 {
> >>    sfp = <&sfp0>;
> >> };
> >> 
> >> SGMII->MDI (Copper):
> >> ethernet-phy@0 {
> >>     mdi;
> >> };
> >> 
> >> SGMII->Auto Media Detect
> >> ethernet-phy@0 {
> >>     mdi;
> >>     sfp = <&sfp0>;
> >> };
> >
> > This isn't something we could realistically do - think about how many
> > DT files are out there today which would not have this for an existing
> > PHY. The default has to be that today's DT descriptions continue to work
> > as-is, and that includes ones which already support copper and fibre
> > either with or without a sfp property.
> >
> > So, we can't draw any conclusion about whether the fiber interface is
> > wired from whether there is a sfp property or not.
> >
> > We also can't draw a conclusion about whether the copper side is wired
> > using a "mdi" property, or whether there is a "sfp" property or not.
> >
> > The only thing we could realistically do today is to introduce a
> > property like:
> >
> > 	mdi = "disabled" | "okay";
> >
> > to indicate whether the copper port can be used, and maybe something
> > similar for the fiber interface.  Maybe as you suggest, not "okay"
> > but specifying the number of connected pairs would be a good idea,
> > or maybe that should be a separate property?
> 
> Maybe you could have optional media nodes under the PHY instead, so that
> you don't involve the SFP property in the logic (SGMII can be connected
> to lots of things after all):

I think you're advocating calling the fiber interface "SGMII", which
would be totally wrong.

SGMII is a Cisco modification of 802.3 1000base-X to allow 10M and 100M
speeds to be used over a single serdes lane in each direction.

1000base-X is what you run over a fiber link. This is not SGMII. Using
"SGMII" for 1000base-X is incorrect, but a common abuse of the term in
industry. Abusing a term does not make it correct, especially when it
comes to defining further standards.

(This is one of my pet peaves, sorry.)

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!