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.5 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=ham 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 6F295C4CEC9 for ; Sat, 14 Sep 2019 14:30:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3F8CB2081B for ; Sat, 14 Sep 2019 14:30:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389391AbfINOaA (ORCPT ); Sat, 14 Sep 2019 10:30:00 -0400 Received: from baldur.buserror.net ([165.227.176.147]:58918 "EHLO baldur.buserror.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387786AbfINOaA (ORCPT ); Sat, 14 Sep 2019 10:30:00 -0400 Received: from [2601:449:8480:af0: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 1i993g-0001r0-Cz; Sat, 14 Sep 2019 09:29:54 -0500 Message-ID: <3e9b3395eba14da55da8a0198716c47c9082397b.camel@buserror.net> From: Scott Wood To: Madalin-cristian Bucur , Valentin Longchamp Cc: "linuxppc-dev@lists.ozlabs.org" , "galak@kernel.crashing.org" , "netdev@vger.kernel.org" Date: Sat, 14 Sep 2019 09:29:51 -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:8480:af0:12bf:48ff:fe84:c9a0 X-SA-Exim-Rcpt-To: madalin.bucur@nxp.com, valentin@longchamp.me, 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-29 at 11:25 +0000, Madalin-cristian Bucur wrote: > > -----Original Message----- > > From: Scott Wood > > Sent: Wednesday, August 28, 2019 7:19 AM > > To: Valentin Longchamp ; Madalin-cristian Bucur > > > > Cc: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org; > > netdev@vger.kernel.org > > Subject: Re: [PATCH] powerpc/kmcent2: update the ethernet devices' phy > > properties > > > > 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 > > > > Yes, I understand that it's the only option they have, given the inability > to upgrade u-boot (this may prove to be an issue in the future, in other > situations). > > Acked-by: Madalin Bucur Acked-by: Scott Wood -Scott