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]
Message-ID: <20200103133523.GA22988@lunn.ch>
Date:   Fri, 3 Jan 2020 14:35:23 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     "Madalin Bucur (OSS)" <madalin.bucur@....nxp.com>,
        "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

> What I might be willing to accept is if we were to introduce
> XFI_10GBASER, XFI_10GBASEW, XFI_10GFC, XFI_G709 and their SFI
> counterparts - but, there would remain one HUGE problem with that,
> which is the total lack of specification of the board characteristics
> required to achieve XFI electrical compliance.

Hi Russell

The four RGMII variants are precedents for mixing protocol and
'electrical' properties, in terms of clock delays. But having four
RGMII variants has been a pain point, implementations getting it
wrong, etc.

So i would avoid mixing them in one property. I would prefer we keep
phy-mode as a protocol property, and we define additional DT
properties to describe the electrical parts of the SERDES interface.

Madalin, what electrical properties do you actually need in DT?  I
guess you need to know if it is using XFI or SFI. But that is only the
start. Do you want to place all the other properties in DT as well, or
are they in a board specific firmware blobs, and you just need to know
if you should use the XFI blob or the SFI blob?

We can probably define a vendor neutral DT property for XFI vs SFI,
but i expect all the other electrical properties are going to be
vendor specific.

       Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ