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

Date:   Mon, 6 Jan 2020 09:34:26 +0000
From:   "Madalin Bucur (OSS)" <madalin.bucur@....nxp.com>
To:     Andrew Lunn <andrew@...n.ch>,
        Russell King - ARM Linux admin <linux@...linux.org.uk>,
        "Madalin Bucur (OSS)" <madalin.bucur@....nxp.com>
CC:     "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: Friday, January 3, 2020 7:17 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
> 
> > There are many things pushed down to u-boot so the Linux driver has
> less
> > work to do, that's one of the reasons there is little left there.
> 
> I prefer barebox. Which is a problem, since it sounds like Ethernet
> will be broken on your boards if i swap to it.

It may be, but customers had success porting that support of various
other bootloaders. Most of this is loading the firmware and device-tree
fix-ups but there may be some minor tweaks of the platforms done in
u-boot that need porting.

> If you are going to offload setting up the hardware, please do it to
> firmware. That is independent of the bootloader. The Marvell SoCs do
> this for their low level SERDES setup, making SMC calls into the
> firmware.
> 
> https://patchwork.kernel.org/cover/10880297/

Firmware has the (dis)advantage of usually being closed source, having
settings done in open source code makes everyone's life easier, but the
one's who needs to send that upstream :)
Firmware does allow any hacks to go unnoticed so it may be preferable by
some in that respect. Ideally it should all be done in the drivers, in
plain sight, imho.

> > Ideally this dependency should be removed but then we'd need to make
> > a clearer distinction. As you've noticed, currently I don't even
> > need to distinguish XFI from SFI because for basic scenarios the
> > code does the same thing.  Problem is, if I select a common
> > denominator now, and later I need to make this distinction, I'll
> > need to update device trees, code, etc. Just like "xgmii" was just
> > fine as a placeholder until recently. I'd rather use a correct
> > description now.
> 
> So it seems like you need two properties. You need a property to tell
> your bootloader how to configure the electrical properties of the
> SERDES, XFI, SFI, etc.

That's what the RCW (reset configuration word) does, it's the first thing
read from FLASH by the SoC on boot (you can consider it a sort of firmware).

> 
> And you need a property to configure the protocol running over the
> SERDES, which is phy-mode.
> 
> 	Andrew

The protocol is clear and related to the speed, some other aspects we do
need to control, such as AN on the system interface, that we need to
disable for 2500Gbps Ethernet, or to know which PCS we need to talk to
in case of QSGMII and so on. Also many resources (FIFOs, internal controller
tasks, DMAs) are sized accordingly to the interface type by SW. The protocol
is the least of my concerns here. I'm using the electrical interface type
to derive a series of parameters for the SW (including what PCS block I talk
to). Used to be "xgmii" (incorrect), today it may be just as well "10gbase-kr"
(still incorrect), tomorrow it may be "10gbase-r" (incomplete, it says nothing
about the HW) or "xfi" (sufficient for this particular HW, maybe incomplete for
others). So we do need to decide if we are going to separate the HW/electrical
description that has a place in the device tree and the SW configuration that
has no place there.

Regards,
Madalin