From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BD049C3A5A1 for ; Wed, 28 Aug 2019 05:00:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9B8A922CF4 for ; Wed, 28 Aug 2019 05:00:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726297AbfH1FAz (ORCPT ); Wed, 28 Aug 2019 01:00:55 -0400 Received: from baldur.buserror.net ([165.227.176.147]:49236 "EHLO baldur.buserror.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726052AbfH1FAy (ORCPT ); Wed, 28 Aug 2019 01:00:54 -0400 X-Greylist: delayed 2497 seconds by postgrey-1.27 at vger.kernel.org; Wed, 28 Aug 2019 01:00:54 EDT Received: from [2601:449:8400:7293:12bf:48ff:fe84:c9a0] by baldur.buserror.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i2pQN-0007F3-6K; Tue, 27 Aug 2019 23:19:12 -0500 Message-ID: From: Scott Wood To: Valentin Longchamp , Madalin-cristian Bucur Cc: "linuxppc-dev@lists.ozlabs.org" , "galak@kernel.crashing.org" , "netdev@vger.kernel.org" Date: Tue, 27 Aug 2019 23:19:10 -0500 In-Reply-To: References: <20190714200501.1276-1-valentin@longchamp.me> <2243421e574c72c5e75d27cc0122338e2e0bde63.camel@buserror.net> Organization: Red Hat Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2601:449:8400:7293:12bf:48ff:fe84:c9a0 X-SA-Exim-Rcpt-To: valentin@longchamp.me, madalin.bucur@nxp.com, linuxppc-dev@lists.ozlabs.org, galak@kernel.crashing.org, netdev@vger.kernel.org X-SA-Exim-Mail-From: oss@buserror.net Subject: Re: [PATCH] powerpc/kmcent2: update the ethernet devices' phy properties X-SA-Exim-Version: 4.2.1 (built Tue, 02 Aug 2016 21:08:31 +0000) X-SA-Exim-Scanned: Yes (on baldur.buserror.net) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, 2019-08-08 at 23:09 +0200, Valentin Longchamp wrote: > Le mar. 30 juil. 2019 à 11:44, Madalin-cristian Bucur > a écrit : > > > > > -----Original Message----- > > > > > > > Le dim. 14 juil. 2019 à 22:05, Valentin Longchamp > > > > 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 > > > > > > 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