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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 758F1C433EF for ; Tue, 4 Jan 2022 12:10:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=12cksWfZWe0+b68CU3Tj5R4l5CBXJ0vNDyNF2vgGpzw=; b=mAmauTNnrt/2yF B7eQz9zRyclUt1GKSqRUnazRqEgeUzc9Iv6CDEQ9iLcAPBAF0PV1TXKJuoB9+PgUxLZuCgMrU4T9w cV3fUtck7Z7qiCtF2jMz763eSfKZZJehvFLUg75V4ggq8TXEzPxW+8AqzUEH3tzuOGaR/yULkvHbr y6SagWe+QxERR8NCg1nr7VZ6mOL1inRYdVI4aDaxP4wItzIRPMVgYvWfQgDbeMRH37yjgu542pzNk Vns2Xk7mcgeyWAN4rYhzvj2fMYa85mCJyhgg07aNwEcwrZLmRj6bB+XMKgj/dMMGIOBJYm/AUB0Ow 3mpPws/uwwDRoE0HDKlg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n4icz-00BPXt-6C; Tue, 04 Jan 2022 12:09:21 +0000 Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n4icv-00BPWI-NH for linux-arm-kernel@lists.infradead.org; Tue, 04 Jan 2022 12:09:19 +0000 Received: by mail-wm1-x32b.google.com with SMTP id e5so22690784wmq.1 for ; Tue, 04 Jan 2022 04:09:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=jaqyMdJNQ92L1SoQFR/daU3pPOKRwHwALSLpJhqen9k=; b=cwzeN/qob+a0OJuuFE6Z8TOIP7VRVbhH7uHSIj8AD1Nnga/UOoHvCSQgTuicgfCPr0 mNYT5OxcyEYxQ5Gi/kphWklpLzfOoUdcZRKxDApBUxxn5Z2eUsYMwnXjPitVNJ7w+BPs x1pVV2/nFr+SzOYxuvwU6fzs9bXZgrTpkk/dWXiEUbrQasLbAdwGCU/IqfE8DdExlxvF p/MNWRaoZ8ij4rc7tCkdfA6kateTwa+6dom8XitNA2e0RvOBfzdHsXxz9Ww0JFm8phf9 iXES3WbIvuAE+56zqdXplzNblwE72dAKzNvA0GAzBAeVuO2lRyWqTyY8IPwzHWxBOyJK U/Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=jaqyMdJNQ92L1SoQFR/daU3pPOKRwHwALSLpJhqen9k=; b=0jk4KGijNHdICS6vM0otd0rXs6ObgRJtbmUsx+3gOu74q1pHisX5G3gGvIntgUa+Jo R8Xj4HP2kS4DN8sTFHUEV82SaxEmB7FQXI/jQuGARXY4hOd6xeivujkb9FXqntoJg9QY xO9TXsVxq5spqKEAlPiC1ampa8RoUjd9WAvKdvEBz4n1WB2dL0owQCgOyxxWwUEV4GoT EV035GqqFkkFdteidhOeM7lrC/55XRzmQuYVuR88n2h/aCdnL09VdWlpZsu05yi3D6zG 2uQ7FN4r1lrmq0UIO1NHC20+uSGYjhS86sjDQxLISNSrMSt568K4JqkT8nY3WaHk0OSz mWJg== X-Gm-Message-State: AOAM533EM1dmkHM5Fo9qMTdUBni0j6TKYL6//6PQ3hxQosngOYlSMP3N p4hPOHjIdC//HJjLu1ELDUw= X-Google-Smtp-Source: ABdhPJzwtHSsinhDjC9nNlm5oH9ALeaF0WE8I7TlbzhvXxzf+JSyTZJRT/cZ1rNAs0zs5Eic3SCYLw== X-Received: by 2002:a05:600c:3844:: with SMTP id s4mr41619971wmr.124.1641298155935; Tue, 04 Jan 2022 04:09:15 -0800 (PST) Received: from Red ([2a01:cb1d:3d5:a100:264b:feff:fe03:2806]) by smtp.googlemail.com with ESMTPSA id u16sm6807769wrn.24.2022.01.04.04.09.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Jan 2022 04:09:15 -0800 (PST) Date: Tue, 4 Jan 2022 13:09:13 +0100 From: Corentin Labbe To: "Russell King (Oracle)" Cc: linus.walleij@linaro.org, ulli.kroll@googlemail.com, kuba@kernel.org, davem@davemloft.net, andrew@lunn.ch, hkallweit1@gmail.com, linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: net: phy: marvell: network working with generic PHY and not with marvell PHY Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220104_040917_789770_50638222 X-CRM114-Status: GOOD ( 30.34 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Le Tue, Jan 04, 2022 at 11:41:40AM +0000, Russell King (Oracle) a =E9crit : > On Tue, Jan 04, 2022 at 12:33:15PM +0100, Corentin Labbe wrote: > > Le Tue, Jan 04, 2022 at 11:14:46AM +0000, Russell King (Oracle) a =E9cr= it : > > > On Tue, Jan 04, 2022 at 11:58:01AM +0100, Corentin Labbe wrote: > > > > Hello > > > > = > > > > I have a gemini SSI 1328 box which has a cortina ethernet MAC with = a Marvell 88E1118 as given by: > > > > Marvell 88E1118 gpio-0:01: attached PHY driver (mii_bus:phy_addr=3D= gpio-0:01, irq=3DPOLL) > > > > So booting with CONFIG_MARVELL_PHY=3Dy lead to a non-working networ= k with link set at 1Gbit > > > > Setting 'max-speed =3D <100>;' (as current state in mainline dtb) l= ead to a working network. > > > > By not working, I mean kernel started with ip=3Ddhcp cannot get an = IP. > > > = > > > How is the PHY connected to the host (which interface mode?) If it's > > > RGMII, it could be that the wrong RGMII interface mode is specified in > > > DT. > > > = > > = > > The PHY is set as RGMII in DT (arch/arm/boot/dts/gemini-ssi1328.dts) > > The only change to the mainline dtb is removing the max-speed. > = > So, it's using "rgmii" with no delay configured at the PHY with the > speed limited to 100Mbps. You then remove the speed limitation and > it doesn't work at 1Gbps. > = > I think I've seen this on other platforms (imx6 + ar8035) when the > RGMII delay is not correctly configured - it will work at slower > speeds but not 1G. > = > The RGMII spec specifies that there will be a delay - and the delay can > be introduced by either the MAC, PHY or by PCB track routing. It sounds > to me like your boot environment configures the PHY to introduce the > necessary delay, but then, because the DT "rgmii" mode means "no delay > at the PHY" when you use the Marvell driver (which respects that), the > Marvell driver configures the PHY for no delay, resulting in a non- > working situation at 1G. > = > I would suggest checking how the boot environment configures the PHY, > and change the "rgmii" mode in DT to match. There is a description of > the four RGMII modes in Documentation/networking/phy.rst that may help > understand what each one means. > = So if I understand, the generic PHY does not touch delays and so values set= by bootloader are kept. The boot environment give no clue on how the PHY is set. Only debug showed is: PHY 0 Addr 1 Vendor ID: 0x01410e11 mii_write: phy_addr=3D0x1 reg_addr=3D0x4 value=3D0x5e1 = mii_write: phy_addr=3D0x1 reg_addr=3D0x9 value=3D0x300 = mii_write: phy_addr=3D0x1 reg_addr=3D0x0 value=3D0x1200 = mii_write: phy_addr=3D0x1 reg_addr=3D0x0 value=3D0x9200 = mii_write: phy_addr=3D0x1 reg_addr=3D0x0 value=3D0x1200 Does it is possible to dump PHY registers when using generic PHY and find d= elay values ? For example ethtool -d eth0 ? If not, my only choice is to bruteforce all delay values until it works. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel