> -----Original Message----- > From: Andrew Lunn <andrew@xxxxxxx> > Sent: Monday, January 6, 2020 3:58 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 > > > 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
