> -----Original Message----- > From: Andrew Lunn <andrew@xxxxxxx> > Sent: Friday, January 3, 2020 7:17 PM > To: Madalin Bucur (OSS) <madalin.bucur@xxxxxxxxxxx> > Cc: Russell King - ARM Linux admin <linux@xxxxxxxxxxxxxxx>; > devicetree@xxxxxxxxxxxxxxx; davem@xxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx; > f.fainelli@xxxxxxxxx; hkallweit1@xxxxxxxxx; shawnguo@xxxxxxxxxx > 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
