netdev - RE: [PATCH 1/6] net: phy: add interface modes for XFI, SFI

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] [day] [month] [year] [list]

Message-ID: <DB8PR04MB69858BB3EE29A90D0A74BDA3EC3C0@DB8PR04MB6985.eurprd04.prod.outlook.com>
Date:   Mon, 6 Jan 2020 15:03:44 +0000
From:   "Madalin Bucur (OSS)" <madalin.bucur@....nxp.com>
To:     Andrew Lunn <andrew@...n.ch>,
        "Madalin Bucur (OSS)" <madalin.bucur@....nxp.com>
CC:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>
Subject: RE: [PATCH 1/6] net: phy: add interface modes for XFI, SFI

> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: Monday, January 6, 2020 3:58 PM
> To: Madalin Bucur (OSS) <madalin.bucur@....nxp.com>
> Cc: Russell King - ARM Linux admin <linux@...linux.org.uk>;
> devicetree@...r.kernel.org; davem@...emloft.net; netdev@...r.kernel.org;
> f.fainelli@...il.com; hkallweit1@...il.com; shawnguo@...nel.org
> Subject: Re: [PATCH 1/6] net: phy: add interface modes for XFI, SFI
> 
> > You missed my argument about the device tree describing the HW (thus
> the
> > wires, electrical aspects too) and not configuring a certain protocol
> (the
> > device tree does not configure HW, it describes HW).
> 
> Hi Madalin
> 
> You have lots of different points here. I'm just picking out one.
> 
> I would say this is a grey area. You need to ensure both devices on
> the XFI bus are using the same protocol. There are a few ways you
> could do this:
> 
> The MAC and the PHY tells phylink what each is capable of, and phylink
> picks a common protocol.
> 
> Leave it to the boot loader/firmware and cross your fingers.
> 
> Make a design decision, this board will use protocol X, and put that
> in device tree. It is describing how we expect the hardware to be
> used.
> 
> The Marvell SERDES interfaces are pretty generic. They can be used for
> SATA, USB3, or networking. But these are all protocols running on top
> of SERDES. So would you argue we cannot describe in device tree that
> one SERDES is to be used for USB and another for SATA?
> 
>     Andrew

That's the case with the SERDES on most (all?) SoCs nowadays. I say we
need to describe them as they are used, which, if I believe the SoC
documentation authors, the PHY documentation authors, the board
documentation author, in my case it's XFI. If it were USB3, SATA, and
a description was needed, why should you not describe it as such? I
see a difference between the XFI and the protocol on top. Not much
data will come through a system if the eye diagram is not open, although
the protocol is the same. Unless you get both right, it does not work.
In my case, the 10GBASE-R part is implicit/redundant information, the
electrical part has the potential to add some information to it. On the
other hand, it's not like someone will solder there a different PHY and
hope it will work because it says "xfi" or it says "10gbase-r" somewhere.
There are a hundred other conditions to be met: voltages, power and reset
sequencing, clock frequencies and stability and so on. It was all taken
care by the board designer, we just need to describe it so that SW can
make the best use of it.

I wanted to describe the interfaces as close to the documentation a
developer adding support for a custom board would be likely to use.
For now a blind replace "xgmii" to "10gbase-r" would be enough to get
things going as they already are and avoid a warning in the AQR probing.
But I feel that we'd still be off from the best description we can
and the above mentioned developer would be left a bit puzzled by that.

I also have the concern that this device tree parameter started life
as an MII bus type enumerator and now we say it should describe the
protocol and only that. Sure, XFI is not an MII interface type, as
it's not aligned to the MAC-PHY interface but rather a PHY sub-block
interface but its frequent use by the industry I thought could warrant
a place for it in that list, unless we decide to build something better.

While we're at it, should we have XAUI, RXAUI there or 10GBASE-X4,
10GBASE-X2?

Madalin