On Thu, 2019-08-08 at 23:09 +0200, Valentin Longchamp wrote: > Le mar. 30 juil. 2019 à 11:44, Madalin-cristian Bucur > <madalin.bu...@nxp.com> a écrit : > > > > > -----Original Message----- > > > > > > > Le dim. 14 juil. 2019 à 22:05, Valentin Longchamp > > > > <valen...@longchamp.me> a écrit : > > > > > > > > > > Change all phy-connection-type properties to phy-mode that are > > > > > better > > > > > supported by the fman driver. > > > > > > > > > > Use the more readable fixed-link node for the 2 sgmii links. > > > > > > > > > > Change the RGMII link to rgmii-id as the clock delays are added by > > > > > the > > > > > phy. > > > > > > > > > > Signed-off-by: Valentin Longchamp <valen...@longchamp.me> > > > > > > I don't see any other uses of phy-mode in arch/powerpc/boot/dts/fsl, and > > > I see > > > lots of phy-connection-type with fman. Madalin, does this patch look > > > OK? > > > > > > -Scott > > > > Hi, > > > > we are using "phy-connection-type" not "phy-mode" for the NXP (former > > Freescale) > > DPAA platforms. While the two seem to be interchangeable ("phy-mode" seems > > to be > > more recent, looking at the device tree bindings), the driver code in > > Linux seems > > to use one or the other, not both so one should stick with the variant the > > driver > > is using. To make things more complex, there may be dependencies in > > bootloaders, > > I see code in u-boot using only "phy-connection-type" or only "phy-mode". > > > > I'd leave "phy-connection-type" as is. > > So I have finally had time to have a look and now I understand what > happens. You are right, there are bootloader dependencies: u-boot > calls fdt_fixup_phy_connection() that somehow in our case adds (or > changes if already in the device tree) the phy-connection-type > property to a wrong value ! By having a phy-mode in the device tree, > that is not changed by u-boot and by chance picked up by the kernel > fman driver (of_get_phy_mode() ) over phy-connection-mode, the below > patch fixes it for us. > > I agree with you, it's not correct to have both phy-connection-type > and phy-mode. Ideally, u-boot on the board should be reworked so that > it does not perform the above wrong fixup. However, in an "unfixed" > .dtb (I have disabled fdt_fixup_phy_connection), the device tree in > the end only has either phy-connection-type or phy-mode, according to > what was chosen in the .dts file. And the fman driver works well with > both (thanks to the call to of_get_phy_mode() ). I would therefore > argue that even if all other DPAA platforms use phy-connection-type, > phy-mode is valid as well. (Furthermore we already have hundreds of > such boards in the field and we don't really support "remote" u-boot > update, so the u-boot fix is going to be difficult for us to pull). > > Valentin
Madalin, are you OK with the patch given this explanation? -Scott