From: "Russell King (Oracle)" <linux@armlinux.org.uk> To: Corentin Labbe <clabbe.montjoie@gmail.com> 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 Date: Tue, 4 Jan 2022 12:17:11 +0000 [thread overview] Message-ID: <YdQ6x2Mz2lOJOQdp@shell.armlinux.org.uk> (raw) In-Reply-To: <YdQ46conUeZ3Qaac@Red> On Tue, Jan 04, 2022 at 01:09:13PM +0100, Corentin Labbe wrote: > Le Tue, Jan 04, 2022 at 11:41:40AM +0000, Russell King (Oracle) a écrit : > > 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 écrit : > > > > 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=gpio-0:01, irq=POLL) > > > > > So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit > > > > > Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network. > > > > > By not working, I mean kernel started with ip=dhcp 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. Correct - the RGMII delays are not part of the standard 802.3 clause 22 register set, so the generic driver has no knowledge how to change these. > 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=0x1 reg_addr=0x4 value=0x5e1 > mii_write: phy_addr=0x1 reg_addr=0x9 value=0x300 > mii_write: phy_addr=0x1 reg_addr=0x0 value=0x1200 > mii_write: phy_addr=0x1 reg_addr=0x0 value=0x9200 > mii_write: phy_addr=0x1 reg_addr=0x0 value=0x1200 Hmm, it doesn't. The first two register writes set the advertisement. The last three are just the PHY reset. > Does it is possible to dump PHY registers when using generic PHY and > find delay values ? For example ethtool -d eth0 ? Even if that were possible, Marvell PHYs use a paged scheme to access configuration registers, so merely reading the 32 registers would probably not help. However, see my follow-up to my previous reply for some further thoughts. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
WARNING: multiple messages have this Message-ID (diff)
From: "Russell King (Oracle)" <linux@armlinux.org.uk> To: Corentin Labbe <clabbe.montjoie@gmail.com> 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 Date: Tue, 4 Jan 2022 12:17:11 +0000 [thread overview] Message-ID: <YdQ6x2Mz2lOJOQdp@shell.armlinux.org.uk> (raw) In-Reply-To: <YdQ46conUeZ3Qaac@Red> On Tue, Jan 04, 2022 at 01:09:13PM +0100, Corentin Labbe wrote: > Le Tue, Jan 04, 2022 at 11:41:40AM +0000, Russell King (Oracle) a écrit : > > 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 écrit : > > > > 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=gpio-0:01, irq=POLL) > > > > > So booting with CONFIG_MARVELL_PHY=y lead to a non-working network with link set at 1Gbit > > > > > Setting 'max-speed = <100>;' (as current state in mainline dtb) lead to a working network. > > > > > By not working, I mean kernel started with ip=dhcp 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. Correct - the RGMII delays are not part of the standard 802.3 clause 22 register set, so the generic driver has no knowledge how to change these. > 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=0x1 reg_addr=0x4 value=0x5e1 > mii_write: phy_addr=0x1 reg_addr=0x9 value=0x300 > mii_write: phy_addr=0x1 reg_addr=0x0 value=0x1200 > mii_write: phy_addr=0x1 reg_addr=0x0 value=0x9200 > mii_write: phy_addr=0x1 reg_addr=0x0 value=0x1200 Hmm, it doesn't. The first two register writes set the advertisement. The last three are just the PHY reset. > Does it is possible to dump PHY registers when using generic PHY and > find delay values ? For example ethtool -d eth0 ? Even if that were possible, Marvell PHYs use a paged scheme to access configuration registers, so merely reading the 32 registers would probably not help. However, see my follow-up to my previous reply for some further thoughts. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-01-04 12:17 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-04 10:58 net: phy: marvell: network working with generic PHY and not with marvell PHY Corentin Labbe 2022-01-04 10:58 ` Corentin Labbe 2022-01-04 11:14 ` Russell King (Oracle) 2022-01-04 11:14 ` Russell King (Oracle) 2022-01-04 11:33 ` Corentin Labbe 2022-01-04 11:33 ` Corentin Labbe 2022-01-04 11:41 ` Russell King (Oracle) 2022-01-04 11:41 ` Russell King (Oracle) 2022-01-04 12:09 ` Corentin Labbe 2022-01-04 12:09 ` Corentin Labbe 2022-01-04 12:17 ` Russell King (Oracle) [this message] 2022-01-04 12:17 ` Russell King (Oracle) 2022-01-04 12:11 ` Russell King (Oracle) 2022-01-04 12:11 ` Russell King (Oracle) 2022-01-04 13:57 ` Corentin Labbe 2022-01-04 13:57 ` Corentin Labbe 2022-01-04 14:11 ` Corentin Labbe 2022-01-04 14:11 ` Corentin Labbe 2022-01-04 14:27 ` Russell King (Oracle) 2022-01-04 14:27 ` Russell King (Oracle) 2022-01-04 14:46 ` Andrew Lunn 2022-01-04 14:46 ` Andrew Lunn 2022-01-04 14:57 ` Russell King (Oracle) 2022-01-04 14:57 ` Russell King (Oracle) 2022-01-04 15:02 ` Andrew Lunn 2022-01-04 15:02 ` Andrew Lunn 2022-01-04 15:04 ` Corentin Labbe 2022-01-04 15:04 ` Corentin Labbe 2022-01-04 14:36 ` Andrew Lunn 2022-01-04 14:36 ` Andrew Lunn
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YdQ6x2Mz2lOJOQdp@shell.armlinux.org.uk \ --to=linux@armlinux.org.uk \ --cc=andrew@lunn.ch \ --cc=clabbe.montjoie@gmail.com \ --cc=davem@davemloft.net \ --cc=hkallweit1@gmail.com \ --cc=kuba@kernel.org \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=ulli.kroll@googlemail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.