| Message ID | 20230714063027.74489-1-naoki@radxa.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: dts: rockchip: rock-3a: make ethernet work | expand |
Am Freitag, 14. Juli 2023, 08:30:27 CEST schrieb FUKAUMI Naoki: > ethernet on Radxa ROCK 3A is not working by following error: > > rk_gmac-dwmac fe010000.ethernet eth0: no phy at addr -1 > rk_gmac-dwmac fe010000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) > > to fix this problem, align related properties with vendor kernel > https://github.com/radxa/kernel/blob/linux-5.10-gen-rkr4.1/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts > > Fixes: 22a442e6586c ("arm64: dts: rockchip: add basic dts for the radxa rock3 model a") > Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> There also is a second patch in the mix adding the gmac1_clkin ef9f4b4a5020 ("arm64: dts: rockchip: Add support of external clock to ethernet node on Rock 3A SBC") And this patch does the exact opposite as the original nodes. Can someone please mention board versions? Or did the gmac1 never really work in the first place? Thanks Heiko > --- > .../boot/dts/rockchip/rk3568-rock-3a.dts | 32 ++++++------------- > 1 file changed, 10 insertions(+), 22 deletions(-) > > diff --git a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts > index 917f5b2b8aab..f9381ab9629b 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts > +++ b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts > @@ -32,13 +32,6 @@ hdmi_con_in: endpoint { > }; > }; > > - gmac1_clkin: external-gmac1-clock { > - compatible = "fixed-clock"; > - clock-frequency = <125000000>; > - clock-output-names = "gmac1_clkin"; > - #clock-cells = <0>; > - }; > - > leds { > compatible = "gpio-leds"; > > @@ -256,18 +249,24 @@ &cpu3 { > > &gmac1 { > assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>; > - assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>, <&gmac1_clkin>; > - clock_in_out = "input"; > + assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>; > + assigned-clock-rates = <0>, <125000000>; > + clock_in_out = "output"; > phy-handle = <&rgmii_phy1>; > - phy-mode = "rgmii-id"; > + phy-mode = "rgmii"; > phy-supply = <&vcc_3v3>; > pinctrl-names = "default"; > pinctrl-0 = <&gmac1m1_miim > &gmac1m1_tx_bus2 > &gmac1m1_rx_bus2 > &gmac1m1_rgmii_clk > - &gmac1m1_clkinout > &gmac1m1_rgmii_bus>; > + snps,reset-gpio = <&gpio3 RK_PB0 GPIO_ACTIVE_LOW>; > + snps,reset-active-low; > + /* Reset time is 20ms, 100ms for rtl8211f */ > + snps,reset-delays-us = <0 20000 100000>; > + tx_delay = <0x42>; > + rx_delay = <0x28>; > status = "okay"; > }; > > @@ -588,11 +587,6 @@ &mdio1 { > rgmii_phy1: ethernet-phy@0 { > compatible = "ethernet-phy-ieee802.3-c22"; > reg = <0x0>; > - pinctrl-names = "default"; > - pinctrl-0 = <ð_phy_rst>; > - reset-assert-us = <20000>; > - reset-deassert-us = <100000>; > - reset-gpios = <&gpio3 RK_PB0 GPIO_ACTIVE_LOW>; > }; > }; > > @@ -630,12 +624,6 @@ vcc_mipi_en: vcc_mipi_en { > }; > }; > > - ethernet { > - eth_phy_rst: eth_phy_rst { > - rockchip,pins = <3 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>; > - }; > - }; > - > hym8563 { > hym8563_int: hym8563-int { > rockchip,pins = <0 RK_PD3 RK_FUNC_GPIO &pcfg_pull_up>; >
On 2023-07-14 17:46, Heiko Stuebner wrote: > Am Freitag, 14. Juli 2023, 08:30:27 CEST schrieb FUKAUMI Naoki: >> ethernet on Radxa ROCK 3A is not working by following error: >> >> rk_gmac-dwmac fe010000.ethernet eth0: no phy at addr -1 >> rk_gmac-dwmac fe010000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) >> >> to fix this problem, align related properties with vendor kernel >> https://github.com/radxa/kernel/blob/linux-5.10-gen-rkr4.1/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >> >> Fixes: 22a442e6586c ("arm64: dts: rockchip: add basic dts for the radxa rock3 model a") >> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> > > There also is a second patch in the mix adding the gmac1_clkin > ef9f4b4a5020 ("arm64: dts: rockchip: Add support of external clock to ethernet node on Rock 3A SBC") > > And this patch does the exact opposite as the original nodes. > Can someone please mention board versions? Or did the gmac1 never > really work in the first place? Ethernet have worked and probably still works booting with vendor U-Boot. However, when booting using mainline U-Boot the ethernet PHY is never initialized or reset due to lack of a ethernet gmac driver for rk35xx. With an early work-in-progress gmac driver the ethernet PHY is working same as with vendor U-Boot, and the ethernet PHY is identified. This revert from using reset-gpios to using the deprecated snps,reset-gpio is probably the wrong way forward. I suspect there is a bug in net/phy/mdio_device.c on how reset-gpios is asserted/deasserted, it works differently than how I would expect it to work, and also differs in how U-Boot handles reset-gpios. Some earlier findings regarding this reset issue: https://github.com/Kwiboo/linux-rockchip/compare/rk3568-eth-phy-reset~2...rk3568-eth-phy-reset Will try to get a proper patch/rfc out later this weekend or early next week after re-testing that on latest kernel. Regards, Jonas > > > Thanks > Heiko > >> --- >> .../boot/dts/rockchip/rk3568-rock-3a.dts | 32 ++++++------------- >> 1 file changed, 10 insertions(+), 22 deletions(-) >> >> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >> index 917f5b2b8aab..f9381ab9629b 100644 >> --- a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >> +++ b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >> @@ -32,13 +32,6 @@ hdmi_con_in: endpoint { >> }; >> }; >> >> - gmac1_clkin: external-gmac1-clock { >> - compatible = "fixed-clock"; >> - clock-frequency = <125000000>; >> - clock-output-names = "gmac1_clkin"; >> - #clock-cells = <0>; >> - }; >> - >> leds { >> compatible = "gpio-leds"; >> >> @@ -256,18 +249,24 @@ &cpu3 { >> >> &gmac1 { >> assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>; >> - assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>, <&gmac1_clkin>; >> - clock_in_out = "input"; >> + assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>; >> + assigned-clock-rates = <0>, <125000000>; >> + clock_in_out = "output"; >> phy-handle = <&rgmii_phy1>; >> - phy-mode = "rgmii-id"; >> + phy-mode = "rgmii"; >> phy-supply = <&vcc_3v3>; >> pinctrl-names = "default"; >> pinctrl-0 = <&gmac1m1_miim >> &gmac1m1_tx_bus2 >> &gmac1m1_rx_bus2 >> &gmac1m1_rgmii_clk >> - &gmac1m1_clkinout >> &gmac1m1_rgmii_bus>; >> + snps,reset-gpio = <&gpio3 RK_PB0 GPIO_ACTIVE_LOW>; >> + snps,reset-active-low; >> + /* Reset time is 20ms, 100ms for rtl8211f */ >> + snps,reset-delays-us = <0 20000 100000>; >> + tx_delay = <0x42>; >> + rx_delay = <0x28>; >> status = "okay"; >> }; >> >> @@ -588,11 +587,6 @@ &mdio1 { >> rgmii_phy1: ethernet-phy@0 { >> compatible = "ethernet-phy-ieee802.3-c22"; >> reg = <0x0>; >> - pinctrl-names = "default"; >> - pinctrl-0 = <ð_phy_rst>; >> - reset-assert-us = <20000>; >> - reset-deassert-us = <100000>; >> - reset-gpios = <&gpio3 RK_PB0 GPIO_ACTIVE_LOW>; >> }; >> }; >> >> @@ -630,12 +624,6 @@ vcc_mipi_en: vcc_mipi_en { >> }; >> }; >> >> - ethernet { >> - eth_phy_rst: eth_phy_rst { >> - rockchip,pins = <3 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>; >> - }; >> - }; >> - >> hym8563 { >> hym8563_int: hym8563-int { >> rockchip,pins = <0 RK_PD3 RK_FUNC_GPIO &pcfg_pull_up>; >> > > > > > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip >
hi, On 7/15/23 01:24, Jonas Karlman wrote: > On 2023-07-14 17:46, Heiko Stuebner wrote: >> Am Freitag, 14. Juli 2023, 08:30:27 CEST schrieb FUKAUMI Naoki: >>> ethernet on Radxa ROCK 3A is not working by following error: >>> >>> rk_gmac-dwmac fe010000.ethernet eth0: no phy at addr -1 >>> rk_gmac-dwmac fe010000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) >>> >>> to fix this problem, align related properties with vendor kernel >>> https://github.com/radxa/kernel/blob/linux-5.10-gen-rkr4.1/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >>> >>> Fixes: 22a442e6586c ("arm64: dts: rockchip: add basic dts for the radxa rock3 model a") >>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> >> >> There also is a second patch in the mix adding the gmac1_clkin >> ef9f4b4a5020 ("arm64: dts: rockchip: Add support of external clock to ethernet node on Rock 3A SBC") >> >> And this patch does the exact opposite as the original nodes. >> Can someone please mention board versions? Or did the gmac1 never >> really work in the first place? > > Ethernet have worked and probably still works booting with vendor U-Boot. > > However, when booting using mainline U-Boot the ethernet PHY is never > initialized or reset due to lack of a ethernet gmac driver for rk35xx. surely I'm using mainline u-boot. > With an early work-in-progress gmac driver the ethernet PHY is working > same as with vendor U-Boot, and the ethernet PHY is identified. > > This revert from using reset-gpios to using the deprecated > snps,reset-gpio is probably the wrong way forward. > > I suspect there is a bug in net/phy/mdio_device.c on how reset-gpios > is asserted/deasserted, it works differently than how I would expect it > to work, and also differs in how U-Boot handles reset-gpios. > > Some earlier findings regarding this reset issue: > https://github.com/Kwiboo/linux-rockchip/compare/rk3568-eth-phy-reset~2...rk3568-eth-phy-reset > > Will try to get a proper patch/rfc out later this weekend or early next > week after re-testing that on latest kernel. thank you so much for your awesome work! Best regards, FUKAUMI Naoki > Regards, > Jonas > >> >> >> Thanks >> Heiko >> >>> --- >>> .../boot/dts/rockchip/rk3568-rock-3a.dts | 32 ++++++------------- >>> 1 file changed, 10 insertions(+), 22 deletions(-) >>> >>> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >>> index 917f5b2b8aab..f9381ab9629b 100644 >>> --- a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >>> +++ b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >>> @@ -32,13 +32,6 @@ hdmi_con_in: endpoint { >>> }; >>> }; >>> >>> - gmac1_clkin: external-gmac1-clock { >>> - compatible = "fixed-clock"; >>> - clock-frequency = <125000000>; >>> - clock-output-names = "gmac1_clkin"; >>> - #clock-cells = <0>; >>> - }; >>> - >>> leds { >>> compatible = "gpio-leds"; >>> >>> @@ -256,18 +249,24 @@ &cpu3 { >>> >>> &gmac1 { >>> assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>; >>> - assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>, <&gmac1_clkin>; >>> - clock_in_out = "input"; >>> + assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>; >>> + assigned-clock-rates = <0>, <125000000>; >>> + clock_in_out = "output"; >>> phy-handle = <&rgmii_phy1>; >>> - phy-mode = "rgmii-id"; >>> + phy-mode = "rgmii"; >>> phy-supply = <&vcc_3v3>; >>> pinctrl-names = "default"; >>> pinctrl-0 = <&gmac1m1_miim >>> &gmac1m1_tx_bus2 >>> &gmac1m1_rx_bus2 >>> &gmac1m1_rgmii_clk >>> - &gmac1m1_clkinout >>> &gmac1m1_rgmii_bus>; >>> + snps,reset-gpio = <&gpio3 RK_PB0 GPIO_ACTIVE_LOW>; >>> + snps,reset-active-low; >>> + /* Reset time is 20ms, 100ms for rtl8211f */ >>> + snps,reset-delays-us = <0 20000 100000>; >>> + tx_delay = <0x42>; >>> + rx_delay = <0x28>; >>> status = "okay"; >>> }; >>> >>> @@ -588,11 +587,6 @@ &mdio1 { >>> rgmii_phy1: ethernet-phy@0 { >>> compatible = "ethernet-phy-ieee802.3-c22"; >>> reg = <0x0>; >>> - pinctrl-names = "default"; >>> - pinctrl-0 = <ð_phy_rst>; >>> - reset-assert-us = <20000>; >>> - reset-deassert-us = <100000>; >>> - reset-gpios = <&gpio3 RK_PB0 GPIO_ACTIVE_LOW>; >>> }; >>> }; >>> >>> @@ -630,12 +624,6 @@ vcc_mipi_en: vcc_mipi_en { >>> }; >>> }; >>> >>> - ethernet { >>> - eth_phy_rst: eth_phy_rst { >>> - rockchip,pins = <3 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>; >>> - }; >>> - }; >>> - >>> hym8563 { >>> hym8563_int: hym8563-int { >>> rockchip,pins = <0 RK_PD3 RK_FUNC_GPIO &pcfg_pull_up>; >>> >> >> >> >> >> >> _______________________________________________ >> Linux-rockchip mailing list >> Linux-rockchip@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-rockchip >> >
On 2023-07-15 06:49, FUKAUMI Naoki wrote: > hi, > > On 7/15/23 01:24, Jonas Karlman wrote: >> On 2023-07-14 17:46, Heiko Stuebner wrote: >>> Am Freitag, 14. Juli 2023, 08:30:27 CEST schrieb FUKAUMI Naoki: >>>> ethernet on Radxa ROCK 3A is not working by following error: >>>> >>>> rk_gmac-dwmac fe010000.ethernet eth0: no phy at addr -1 >>>> rk_gmac-dwmac fe010000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) >>>> >>>> to fix this problem, align related properties with vendor kernel >>>> https://github.com/radxa/kernel/blob/linux-5.10-gen-rkr4.1/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >>>> >>>> Fixes: 22a442e6586c ("arm64: dts: rockchip: add basic dts for the radxa rock3 model a") >>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> >>> >>> There also is a second patch in the mix adding the gmac1_clkin >>> ef9f4b4a5020 ("arm64: dts: rockchip: Add support of external clock to ethernet node on Rock 3A SBC") >>> >>> And this patch does the exact opposite as the original nodes. >>> Can someone please mention board versions? Or did the gmac1 never >>> really work in the first place? >> >> Ethernet have worked and probably still works booting with vendor U-Boot. >> >> However, when booting using mainline U-Boot the ethernet PHY is never >> initialized or reset due to lack of a ethernet gmac driver for rk35xx. > > surely I'm using mainline u-boot. > >> With an early work-in-progress gmac driver the ethernet PHY is working >> same as with vendor U-Boot, and the ethernet PHY is identified. >> >> This revert from using reset-gpios to using the deprecated >> snps,reset-gpio is probably the wrong way forward. >> >> I suspect there is a bug in net/phy/mdio_device.c on how reset-gpios >> is asserted/deasserted, it works differently than how I would expect it >> to work, and also differs in how U-Boot handles reset-gpios. >> >> Some earlier findings regarding this reset issue: >> https://github.com/Kwiboo/linux-rockchip/compare/rk3568-eth-phy-reset~2...rk3568-eth-phy-reset >> >> Will try to get a proper patch/rfc out later this weekend or early next >> week after re-testing that on latest kernel. > > thank you so much for your awesome work! Thanks, made some progress on tracking down the root cause. From what I have discovered so far there is a chicken-and-egg problem: - phy needs to be reset or phy_id read back as 0xffffffff on mdio bus - phy device is not created because a valid phy_id is not read back - phy device needs to be created before it can be reset Possible workarounds so far: - phy is reset in U-Boot - very early work-in-progress at https://github.com/Kwiboo/u-boot-rockchip/commit/6ee80f9a895a32551cf30dd4252a4960ed80dfc9 - phy is reset using mdio bus reset - similar to old https://github.com/Kwiboo/linux-rockchip/commit/8597fcfa0c5c792dabb44a2db7b283c56c99ec6a - phy is reset using deprecated snps,reset-gpio - similar to mdio bus reset Regards, Jonas > > Best regards, > FUKAUMI Naoki > >> Regards, >> Jonas >> >>> >>> >>> Thanks >>> Heiko >>> >>>> --- >>>> .../boot/dts/rockchip/rk3568-rock-3a.dts | 32 ++++++------------- >>>> 1 file changed, 10 insertions(+), 22 deletions(-) >>>> >>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >>>> index 917f5b2b8aab..f9381ab9629b 100644 >>>> --- a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >>>> +++ b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >>>> @@ -32,13 +32,6 @@ hdmi_con_in: endpoint { >>>> }; >>>> }; >>>> >>>> - gmac1_clkin: external-gmac1-clock { >>>> - compatible = "fixed-clock"; >>>> - clock-frequency = <125000000>; >>>> - clock-output-names = "gmac1_clkin"; >>>> - #clock-cells = <0>; >>>> - }; >>>> - >>>> leds { >>>> compatible = "gpio-leds"; >>>> >>>> @@ -256,18 +249,24 @@ &cpu3 { >>>> >>>> &gmac1 { >>>> assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>; >>>> - assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>, <&gmac1_clkin>; >>>> - clock_in_out = "input"; >>>> + assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>; >>>> + assigned-clock-rates = <0>, <125000000>; >>>> + clock_in_out = "output"; >>>> phy-handle = <&rgmii_phy1>; >>>> - phy-mode = "rgmii-id"; >>>> + phy-mode = "rgmii"; >>>> phy-supply = <&vcc_3v3>; >>>> pinctrl-names = "default"; >>>> pinctrl-0 = <&gmac1m1_miim >>>> &gmac1m1_tx_bus2 >>>> &gmac1m1_rx_bus2 >>>> &gmac1m1_rgmii_clk >>>> - &gmac1m1_clkinout >>>> &gmac1m1_rgmii_bus>; >>>> + snps,reset-gpio = <&gpio3 RK_PB0 GPIO_ACTIVE_LOW>; >>>> + snps,reset-active-low; >>>> + /* Reset time is 20ms, 100ms for rtl8211f */ >>>> + snps,reset-delays-us = <0 20000 100000>; >>>> + tx_delay = <0x42>; >>>> + rx_delay = <0x28>; >>>> status = "okay"; >>>> }; >>>> >>>> @@ -588,11 +587,6 @@ &mdio1 { >>>> rgmii_phy1: ethernet-phy@0 { >>>> compatible = "ethernet-phy-ieee802.3-c22"; >>>> reg = <0x0>; >>>> - pinctrl-names = "default"; >>>> - pinctrl-0 = <ð_phy_rst>; >>>> - reset-assert-us = <20000>; >>>> - reset-deassert-us = <100000>; >>>> - reset-gpios = <&gpio3 RK_PB0 GPIO_ACTIVE_LOW>; >>>> }; >>>> }; >>>> >>>> @@ -630,12 +624,6 @@ vcc_mipi_en: vcc_mipi_en { >>>> }; >>>> }; >>>> >>>> - ethernet { >>>> - eth_phy_rst: eth_phy_rst { >>>> - rockchip,pins = <3 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>; >>>> - }; >>>> - }; >>>> - >>>> hym8563 { >>>> hym8563_int: hym8563-int { >>>> rockchip,pins = <0 RK_PD3 RK_FUNC_GPIO &pcfg_pull_up>; >>>>
Hi all, In addition to what has been already said: On 7/16/23 15:50, Jonas Karlman wrote: > On 2023-07-15 06:49, FUKAUMI Naoki wrote: >> hi, >> >> On 7/15/23 01:24, Jonas Karlman wrote: >>> On 2023-07-14 17:46, Heiko Stuebner wrote: >>>> Am Freitag, 14. Juli 2023, 08:30:27 CEST schrieb FUKAUMI Naoki: >>>>> ethernet on Radxa ROCK 3A is not working by following error: >>>>> >>>>> rk_gmac-dwmac fe010000.ethernet eth0: no phy at addr -1 >>>>> rk_gmac-dwmac fe010000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) >>>>> >>>>> to fix this problem, align related properties with vendor kernel >>>>> https://github.com/radxa/kernel/blob/linux-5.10-gen-rkr4.1/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >>>>> >>>>> Fixes: 22a442e6586c ("arm64: dts: rockchip: add basic dts for the radxa rock3 model a") >>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> >>>> >>>> There also is a second patch in the mix adding the gmac1_clkin >>>> ef9f4b4a5020 ("arm64: dts: rockchip: Add support of external clock to ethernet node on Rock 3A SBC") >>>> >>>> And this patch does the exact opposite as the original nodes. >>>> Can someone please mention board versions? Or did the gmac1 never >>>> really work in the first place? As far as I know all schematics versions state that the PHY produces the clock (see the most recent schematics here: https://dl.radxa.com/rock3/docs/hw/3a/ROCK-3A-V1.3-SCH.pdf) Although using the internal MAC clock works as well, using the gmac1_clkin is most probably the correct way. >>> Ethernet have worked and probably still works booting with vendor U-Boot. >>> >>> However, when booting using mainline U-Boot the ethernet PHY is never >>> initialized or reset due to lack of a ethernet gmac driver for rk35xx. >> >> surely I'm using mainline u-boot. Ah, this might explain why I never experienced this issue: I am using mainline barebox with GMAC support. >>> With an early work-in-progress gmac driver the ethernet PHY is working >>> same as with vendor U-Boot, and the ethernet PHY is identified. >>> >>> This revert from using reset-gpios to using the deprecated >>> snps,reset-gpio is probably the wrong way forward. >>> >>> I suspect there is a bug in net/phy/mdio_device.c on how reset-gpios >>> is asserted/deasserted, it works differently than how I would expect it >>> to work, and also differs in how U-Boot handles reset-gpios. >>> >>> Some earlier findings regarding this reset issue: >>> https://github.com/Kwiboo/linux-rockchip/compare/rk3568-eth-phy-reset~2...rk3568-eth-phy-reset >>> >>> Will try to get a proper patch/rfc out later this weekend or early next >>> week after re-testing that on latest kernel. >> >> thank you so much for your awesome work! > > Thanks, made some progress on tracking down the root cause. > From what I have discovered so far there is a chicken-and-egg problem: > > - phy needs to be reset or phy_id read back as 0xffffffff on mdio bus > - phy device is not created because a valid phy_id is not read back > - phy device needs to be created before it can be reset > > Possible workarounds so far: > - phy is reset in U-Boot > - very early work-in-progress at https://github.com/Kwiboo/u-boot-rockchip/commit/6ee80f9a895a32551cf30dd4252a4960ed80dfc9 > - phy is reset using mdio bus reset > - similar to old https://github.com/Kwiboo/linux-rockchip/commit/8597fcfa0c5c792dabb44a2db7b283c56c99ec6a > - phy is reset using deprecated snps,reset-gpio > - similar to mdio bus reset There was a similar discussion here: https://lore.kernel.org/all/CAMdYzYo_DGiO0UxJEb3xues7Um=X9AgPvz+Xp_YWb9pp9HaScg@mail.gmail.com/ The approach that moves the reset to the MDIO bus has been mentioned there as well. On the first glance this approach looks reasonable to me. Best regards, Michael > [...] >>>>> --- >>>>> .../boot/dts/rockchip/rk3568-rock-3a.dts | 32 ++++++------------- >>>>> 1 file changed, 10 insertions(+), 22 deletions(-) >>>>> >>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >>>>> index 917f5b2b8aab..f9381ab9629b 100644 >>>>> --- a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >>>>> @@ -32,13 +32,6 @@ hdmi_con_in: endpoint { >>>>> }; >>>>> }; >>>>> >>>>> - gmac1_clkin: external-gmac1-clock { >>>>> - compatible = "fixed-clock"; >>>>> - clock-frequency = <125000000>; >>>>> - clock-output-names = "gmac1_clkin"; >>>>> - #clock-cells = <0>; >>>>> - }; >>>>> - >>>>> leds { >>>>> compatible = "gpio-leds"; >>>>> >>>>> @@ -256,18 +249,24 @@ &cpu3 { >>>>> >>>>> &gmac1 { >>>>> assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>; >>>>> - assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>, <&gmac1_clkin>; >>>>> - clock_in_out = "input"; >>>>> + assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>; >>>>> + assigned-clock-rates = <0>, <125000000>; >>>>> + clock_in_out = "output"; >>>>> phy-handle = <&rgmii_phy1>; >>>>> - phy-mode = "rgmii-id"; >>>>> + phy-mode = "rgmii"; >>>>> phy-supply = <&vcc_3v3>; >>>>> pinctrl-names = "default"; >>>>> pinctrl-0 = <&gmac1m1_miim >>>>> &gmac1m1_tx_bus2 >>>>> &gmac1m1_rx_bus2 >>>>> &gmac1m1_rgmii_clk >>>>> - &gmac1m1_clkinout >>>>> &gmac1m1_rgmii_bus>; >>>>> + snps,reset-gpio = <&gpio3 RK_PB0 GPIO_ACTIVE_LOW>; >>>>> + snps,reset-active-low; >>>>> + /* Reset time is 20ms, 100ms for rtl8211f */ >>>>> + snps,reset-delays-us = <0 20000 100000>; >>>>> + tx_delay = <0x42>; >>>>> + rx_delay = <0x28>; >>>>> status = "okay"; >>>>> }; >>>>> >>>>> @@ -588,11 +587,6 @@ &mdio1 { >>>>> rgmii_phy1: ethernet-phy@0 { >>>>> compatible = "ethernet-phy-ieee802.3-c22"; >>>>> reg = <0x0>; >>>>> - pinctrl-names = "default"; >>>>> - pinctrl-0 = <ð_phy_rst>; >>>>> - reset-assert-us = <20000>; >>>>> - reset-deassert-us = <100000>; >>>>> - reset-gpios = <&gpio3 RK_PB0 GPIO_ACTIVE_LOW>; >>>>> }; >>>>> }; >>>>> >>>>> @@ -630,12 +624,6 @@ vcc_mipi_en: vcc_mipi_en { >>>>> }; >>>>> }; >>>>> >>>>> - ethernet { >>>>> - eth_phy_rst: eth_phy_rst { >>>>> - rockchip,pins = <3 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>; >>>>> - }; >>>>> - }; >>>>> - >>>>> hym8563 { >>>>> hym8563_int: hym8563-int { >>>>> rockchip,pins = <0 RK_PD3 RK_FUNC_GPIO &pcfg_pull_up>; >>>>> >
On 2023-07-17 09:40, Michael Riesch wrote: > Hi all, > > In addition to what has been already said: > > On 7/16/23 15:50, Jonas Karlman wrote: >> On 2023-07-15 06:49, FUKAUMI Naoki wrote: >>> hi, >>> >>> On 7/15/23 01:24, Jonas Karlman wrote: >>>> On 2023-07-14 17:46, Heiko Stuebner wrote: >>>>> Am Freitag, 14. Juli 2023, 08:30:27 CEST schrieb FUKAUMI Naoki: >>>>>> ethernet on Radxa ROCK 3A is not working by following error: >>>>>> >>>>>> rk_gmac-dwmac fe010000.ethernet eth0: no phy at addr -1 >>>>>> rk_gmac-dwmac fe010000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) >>>>>> >>>>>> to fix this problem, align related properties with vendor kernel >>>>>> https://github.com/radxa/kernel/blob/linux-5.10-gen-rkr4.1/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >>>>>> >>>>>> Fixes: 22a442e6586c ("arm64: dts: rockchip: add basic dts for the radxa rock3 model a") >>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> >>>>> >>>>> There also is a second patch in the mix adding the gmac1_clkin >>>>> ef9f4b4a5020 ("arm64: dts: rockchip: Add support of external clock to ethernet node on Rock 3A SBC") >>>>> >>>>> And this patch does the exact opposite as the original nodes. >>>>> Can someone please mention board versions? Or did the gmac1 never >>>>> really work in the first place? > > As far as I know all schematics versions state that the PHY produces the > clock (see the most recent schematics here: > https://dl.radxa.com/rock3/docs/hw/3a/ROCK-3A-V1.3-SCH.pdf>> > Although using the internal MAC clock works as well, using the > gmac1_clkin is most probably the correct way. > >>>> Ethernet have worked and probably still works booting with vendor U-Boot. >>>> >>>> However, when booting using mainline U-Boot the ethernet PHY is never >>>> initialized or reset due to lack of a ethernet gmac driver for rk35xx. >>> >>> surely I'm using mainline u-boot. > > Ah, this might explain why I never experienced this issue: I am using > mainline barebox with GMAC support. > >>>> With an early work-in-progress gmac driver the ethernet PHY is working >>>> same as with vendor U-Boot, and the ethernet PHY is identified. >>>> >>>> This revert from using reset-gpios to using the deprecated >>>> snps,reset-gpio is probably the wrong way forward. >>>> >>>> I suspect there is a bug in net/phy/mdio_device.c on how reset-gpios >>>> is asserted/deasserted, it works differently than how I would expect it >>>> to work, and also differs in how U-Boot handles reset-gpios. >>>> >>>> Some earlier findings regarding this reset issue: >>>> https://github.com/Kwiboo/linux-rockchip/compare/rk3568-eth-phy-reset~2...rk3568-eth-phy-reset >>>> >>>> Will try to get a proper patch/rfc out later this weekend or early next >>>> week after re-testing that on latest kernel. >>> >>> thank you so much for your awesome work! >> >> Thanks, made some progress on tracking down the root cause. >> From what I have discovered so far there is a chicken-and-egg problem: >> >> - phy needs to be reset or phy_id read back as 0xffffffff on mdio bus >> - phy device is not created because a valid phy_id is not read back >> - phy device needs to be created before it can be reset >> >> Possible workarounds so far: >> - phy is reset in U-Boot >> - very early work-in-progress at https://github.com/Kwiboo/u-boot-rockchip/commit/6ee80f9a895a32551cf30dd4252a4960ed80dfc9 >> - phy is reset using mdio bus reset >> - similar to old https://github.com/Kwiboo/linux-rockchip/commit/8597fcfa0c5c792dabb44a2db7b283c56c99ec6a >> - phy is reset using deprecated snps,reset-gpio >> - similar to mdio bus reset > > There was a similar discussion here: > https://lore.kernel.org/all/CAMdYzYo_DGiO0UxJEb3xues7Um=X9AgPvz+Xp_YWb9pp9HaScg@mail.gmail.com/ > > The approach that moves the reset to the MDIO bus has been mentioned > there as well. On the first glance this approach looks reasonable to me. It does not look like U-Boot support mdio bus reset-gpios, so changing to that would require adding even more code into U-Boot to get ethernet working in U-Boot. Moving to mdio bus would make it behave like with old snps,reset-gpio, however phy reset-gpios still describe the hw more accurately, a assert/deassert cycle of reset-gpios triggers a phy hard reset. Do not know if it is possible to have both mdio bus reset and phy reset. There also looks like there is a bug in dwmac-rk rk3568_set_to_rgmii, tx/rx delay is always enabled. It should be disabled in some phy modes. Can send a patch once I finish with the U-Boot ethernet driver. Will try to complete a U-Boot driver that supports both phy reset-gpios and the deprecated snps,reset-gpio as a first step. Regards, Jonas > > Best regards, > Michael > >> [...] >>>>>> --- >>>>>> .../boot/dts/rockchip/rk3568-rock-3a.dts | 32 ++++++------------- >>>>>> 1 file changed, 10 insertions(+), 22 deletions(-) >>>>>> >>>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >>>>>> index 917f5b2b8aab..f9381ab9629b 100644 >>>>>> --- a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >>>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >>>>>> @@ -32,13 +32,6 @@ hdmi_con_in: endpoint { >>>>>> }; >>>>>> }; >>>>>> >>>>>> - gmac1_clkin: external-gmac1-clock { >>>>>> - compatible = "fixed-clock"; >>>>>> - clock-frequency = <125000000>; >>>>>> - clock-output-names = "gmac1_clkin"; >>>>>> - #clock-cells = <0>; >>>>>> - }; >>>>>> - >>>>>> leds { >>>>>> compatible = "gpio-leds"; >>>>>> >>>>>> @@ -256,18 +249,24 @@ &cpu3 { >>>>>> >>>>>> &gmac1 { >>>>>> assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>; >>>>>> - assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>, <&gmac1_clkin>; >>>>>> - clock_in_out = "input"; >>>>>> + assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>; >>>>>> + assigned-clock-rates = <0>, <125000000>; >>>>>> + clock_in_out = "output"; >>>>>> phy-handle = <&rgmii_phy1>; >>>>>> - phy-mode = "rgmii-id"; >>>>>> + phy-mode = "rgmii"; >>>>>> phy-supply = <&vcc_3v3>; >>>>>> pinctrl-names = "default"; >>>>>> pinctrl-0 = <&gmac1m1_miim >>>>>> &gmac1m1_tx_bus2 >>>>>> &gmac1m1_rx_bus2 >>>>>> &gmac1m1_rgmii_clk >>>>>> - &gmac1m1_clkinout >>>>>> &gmac1m1_rgmii_bus>; >>>>>> + snps,reset-gpio = <&gpio3 RK_PB0 GPIO_ACTIVE_LOW>; >>>>>> + snps,reset-active-low; >>>>>> + /* Reset time is 20ms, 100ms for rtl8211f */ >>>>>> + snps,reset-delays-us = <0 20000 100000>; >>>>>> + tx_delay = <0x42>; >>>>>> + rx_delay = <0x28>; >>>>>> status = "okay"; >>>>>> }; >>>>>> >>>>>> @@ -588,11 +587,6 @@ &mdio1 { >>>>>> rgmii_phy1: ethernet-phy@0 { >>>>>> compatible = "ethernet-phy-ieee802.3-c22"; >>>>>> reg = <0x0>; >>>>>> - pinctrl-names = "default"; >>>>>> - pinctrl-0 = <ð_phy_rst>; >>>>>> - reset-assert-us = <20000>; >>>>>> - reset-deassert-us = <100000>; >>>>>> - reset-gpios = <&gpio3 RK_PB0 GPIO_ACTIVE_LOW>; >>>>>> }; >>>>>> }; >>>>>> >>>>>> @@ -630,12 +624,6 @@ vcc_mipi_en: vcc_mipi_en { >>>>>> }; >>>>>> }; >>>>>> >>>>>> - ethernet { >>>>>> - eth_phy_rst: eth_phy_rst { >>>>>> - rockchip,pins = <3 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>; >>>>>> - }; >>>>>> - }; >>>>>> - >>>>>> hym8563 { >>>>>> hym8563_int: hym8563-int { >>>>>> rockchip,pins = <0 RK_PD3 RK_FUNC_GPIO &pcfg_pull_up>; >>>>>> >>
On 2023-07-17 19:11, Jonas Karlman wrote: > On 2023-07-17 09:40, Michael Riesch wrote: >> Hi all, >> >> In addition to what has been already said: >> >> On 7/16/23 15:50, Jonas Karlman wrote: >>> On 2023-07-15 06:49, FUKAUMI Naoki wrote: >>>> hi, >>>> >>>> On 7/15/23 01:24, Jonas Karlman wrote: >>>>> On 2023-07-14 17:46, Heiko Stuebner wrote: >>>>>> Am Freitag, 14. Juli 2023, 08:30:27 CEST schrieb FUKAUMI Naoki: >>>>>>> ethernet on Radxa ROCK 3A is not working by following error: >>>>>>> >>>>>>> rk_gmac-dwmac fe010000.ethernet eth0: no phy at addr -1 >>>>>>> rk_gmac-dwmac fe010000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) >>>>>>> >>>>>>> to fix this problem, align related properties with vendor kernel >>>>>>> https://github.com/radxa/kernel/blob/linux-5.10-gen-rkr4.1/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >>>>>>> >>>>>>> Fixes: 22a442e6586c ("arm64: dts: rockchip: add basic dts for the radxa rock3 model a") >>>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> >>>>>> >>>>>> There also is a second patch in the mix adding the gmac1_clkin >>>>>> ef9f4b4a5020 ("arm64: dts: rockchip: Add support of external clock to ethernet node on Rock 3A SBC") >>>>>> >>>>>> And this patch does the exact opposite as the original nodes. >>>>>> Can someone please mention board versions? Or did the gmac1 never >>>>>> really work in the first place? >> >> As far as I know all schematics versions state that the PHY produces the >> clock (see the most recent schematics here: >> https://dl.radxa.com/rock3/docs/hw/3a/ROCK-3A-V1.3-SCH.pdf >> >> Although using the internal MAC clock works as well, using the >> gmac1_clkin is most probably the correct way. >> >>>>> Ethernet have worked and probably still works booting with vendor U-Boot. >>>>> >>>>> However, when booting using mainline U-Boot the ethernet PHY is never >>>>> initialized or reset due to lack of a ethernet gmac driver for rk35xx. >>>> >>>> surely I'm using mainline u-boot. >> >> Ah, this might explain why I never experienced this issue: I am using >> mainline barebox with GMAC support. >> >>>>> With an early work-in-progress gmac driver the ethernet PHY is working >>>>> same as with vendor U-Boot, and the ethernet PHY is identified. >>>>> >>>>> This revert from using reset-gpios to using the deprecated >>>>> snps,reset-gpio is probably the wrong way forward. >>>>> >>>>> I suspect there is a bug in net/phy/mdio_device.c on how reset-gpios >>>>> is asserted/deasserted, it works differently than how I would expect it >>>>> to work, and also differs in how U-Boot handles reset-gpios. >>>>> >>>>> Some earlier findings regarding this reset issue: >>>>> https://github.com/Kwiboo/linux-rockchip/compare/rk3568-eth-phy-reset~2...rk3568-eth-phy-reset >>>>> >>>>> Will try to get a proper patch/rfc out later this weekend or early next >>>>> week after re-testing that on latest kernel. >>>> >>>> thank you so much for your awesome work! >>> >>> Thanks, made some progress on tracking down the root cause. >>> From what I have discovered so far there is a chicken-and-egg problem: >>> >>> - phy needs to be reset or phy_id read back as 0xffffffff on mdio bus >>> - phy device is not created because a valid phy_id is not read back >>> - phy device needs to be created before it can be reset >>> >>> Possible workarounds so far: >>> - phy is reset in U-Boot >>> - very early work-in-progress at https://github.com/Kwiboo/u-boot-rockchip/commit/6ee80f9a895a32551cf30dd4252a4960ed80dfc9 >>> - phy is reset using mdio bus reset >>> - similar to old https://github.com/Kwiboo/linux-rockchip/commit/8597fcfa0c5c792dabb44a2db7b283c56c99ec6a >>> - phy is reset using deprecated snps,reset-gpio >>> - similar to mdio bus reset >> >> There was a similar discussion here: >> https://lore.kernel.org/all/CAMdYzYo_DGiO0UxJEb3xues7Um=X9AgPvz+Xp_YWb9pp9HaScg@mail.gmail.com/ >> >> The approach that moves the reset to the MDIO bus has been mentioned >> there as well. On the first glance this approach looks reasonable to me. > > It does not look like U-Boot support mdio bus reset-gpios, so changing > to that would require adding even more code into U-Boot to get ethernet > working in U-Boot. > > Moving to mdio bus would make it behave like with old snps,reset-gpio, > however phy reset-gpios still describe the hw more accurately, a > assert/deassert cycle of reset-gpios triggers a phy hard reset. > > Do not know if it is possible to have both mdio bus reset and phy reset. > > There also looks like there is a bug in dwmac-rk rk3568_set_to_rgmii, > tx/rx delay is always enabled. It should be disabled in some phy modes. > Can send a patch once I finish with the U-Boot ethernet driver. > > Will try to complete a U-Boot driver that supports both phy reset-gpios > and the deprecated snps,reset-gpio as a first step. I have now created a small U-Boot dummy ethernet phy reset driver that will assert/deassert reset-gpios to help make linux detect the PHY. With this my ROCK 3 Model B detects the RTL8211F PHY again without any changes to linux device tree. See the U-Boot patch "HACK: net: Add dummy PHY reset-gpios driver" at https://github.com/Kwiboo/u-boot-rockchip/commits/rk3568-2023.10-hacks Will continue work on a fully working dwc_eth_qos_rockchip U-Boot driver, currently having trouble getting TX working, at least RX is working. Regards, Jonas > > Regards, > Jonas > >> >> Best regards, >> Michael >> >>> [...]
hi, On 7/24/23 07:54, Jonas Karlman wrote: > On 2023-07-17 19:11, Jonas Karlman wrote: >> On 2023-07-17 09:40, Michael Riesch wrote: >>> Hi all, >>> >>> In addition to what has been already said: >>> >>> On 7/16/23 15:50, Jonas Karlman wrote: >>>> On 2023-07-15 06:49, FUKAUMI Naoki wrote: >>>>> hi, >>>>> >>>>> On 7/15/23 01:24, Jonas Karlman wrote: >>>>>> On 2023-07-14 17:46, Heiko Stuebner wrote: >>>>>>> Am Freitag, 14. Juli 2023, 08:30:27 CEST schrieb FUKAUMI Naoki: >>>>>>>> ethernet on Radxa ROCK 3A is not working by following error: >>>>>>>> >>>>>>>> rk_gmac-dwmac fe010000.ethernet eth0: no phy at addr -1 >>>>>>>> rk_gmac-dwmac fe010000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) >>>>>>>> >>>>>>>> to fix this problem, align related properties with vendor kernel >>>>>>>> https://github.com/radxa/kernel/blob/linux-5.10-gen-rkr4.1/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >>>>>>>> >>>>>>>> Fixes: 22a442e6586c ("arm64: dts: rockchip: add basic dts for the radxa rock3 model a") >>>>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> >>>>>>> >>>>>>> There also is a second patch in the mix adding the gmac1_clkin >>>>>>> ef9f4b4a5020 ("arm64: dts: rockchip: Add support of external clock to ethernet node on Rock 3A SBC") >>>>>>> >>>>>>> And this patch does the exact opposite as the original nodes. >>>>>>> Can someone please mention board versions? Or did the gmac1 never >>>>>>> really work in the first place? >>> >>> As far as I know all schematics versions state that the PHY produces the >>> clock (see the most recent schematics here: >>> https://dl.radxa.com/rock3/docs/hw/3a/ROCK-3A-V1.3-SCH.pdf >>> >>> Although using the internal MAC clock works as well, using the >>> gmac1_clkin is most probably the correct way. >>> >>>>>> Ethernet have worked and probably still works booting with vendor U-Boot. >>>>>> >>>>>> However, when booting using mainline U-Boot the ethernet PHY is never >>>>>> initialized or reset due to lack of a ethernet gmac driver for rk35xx. >>>>> >>>>> surely I'm using mainline u-boot. >>> >>> Ah, this might explain why I never experienced this issue: I am using >>> mainline barebox with GMAC support. >>> >>>>>> With an early work-in-progress gmac driver the ethernet PHY is working >>>>>> same as with vendor U-Boot, and the ethernet PHY is identified. >>>>>> >>>>>> This revert from using reset-gpios to using the deprecated >>>>>> snps,reset-gpio is probably the wrong way forward. >>>>>> >>>>>> I suspect there is a bug in net/phy/mdio_device.c on how reset-gpios >>>>>> is asserted/deasserted, it works differently than how I would expect it >>>>>> to work, and also differs in how U-Boot handles reset-gpios. >>>>>> >>>>>> Some earlier findings regarding this reset issue: >>>>>> https://github.com/Kwiboo/linux-rockchip/compare/rk3568-eth-phy-reset~2...rk3568-eth-phy-reset >>>>>> >>>>>> Will try to get a proper patch/rfc out later this weekend or early next >>>>>> week after re-testing that on latest kernel. >>>>> >>>>> thank you so much for your awesome work! >>>> >>>> Thanks, made some progress on tracking down the root cause. >>>> From what I have discovered so far there is a chicken-and-egg problem: >>>> >>>> - phy needs to be reset or phy_id read back as 0xffffffff on mdio bus >>>> - phy device is not created because a valid phy_id is not read back >>>> - phy device needs to be created before it can be reset >>>> >>>> Possible workarounds so far: >>>> - phy is reset in U-Boot >>>> - very early work-in-progress at https://github.com/Kwiboo/u-boot-rockchip/commit/6ee80f9a895a32551cf30dd4252a4960ed80dfc9 >>>> - phy is reset using mdio bus reset >>>> - similar to old https://github.com/Kwiboo/linux-rockchip/commit/8597fcfa0c5c792dabb44a2db7b283c56c99ec6a >>>> - phy is reset using deprecated snps,reset-gpio >>>> - similar to mdio bus reset >>> >>> There was a similar discussion here: >>> https://lore.kernel.org/all/CAMdYzYo_DGiO0UxJEb3xues7Um=X9AgPvz+Xp_YWb9pp9HaScg@mail.gmail.com/ >>> >>> The approach that moves the reset to the MDIO bus has been mentioned >>> there as well. On the first glance this approach looks reasonable to me. >> >> It does not look like U-Boot support mdio bus reset-gpios, so changing >> to that would require adding even more code into U-Boot to get ethernet >> working in U-Boot. >> >> Moving to mdio bus would make it behave like with old snps,reset-gpio, >> however phy reset-gpios still describe the hw more accurately, a >> assert/deassert cycle of reset-gpios triggers a phy hard reset. >> >> Do not know if it is possible to have both mdio bus reset and phy reset. >> >> There also looks like there is a bug in dwmac-rk rk3568_set_to_rgmii, >> tx/rx delay is always enabled. It should be disabled in some phy modes. >> Can send a patch once I finish with the U-Boot ethernet driver. >> >> Will try to complete a U-Boot driver that supports both phy reset-gpios >> and the deprecated snps,reset-gpio as a first step. > > I have now created a small U-Boot dummy ethernet phy reset driver that > will assert/deassert reset-gpios to help make linux detect the PHY. > > With this my ROCK 3 Model B detects the RTL8211F PHY again without any > changes to linux device tree. > > See the U-Boot patch "HACK: net: Add dummy PHY reset-gpios driver" > at https://github.com/Kwiboo/u-boot-rockchip/commits/rk3568-2023.10-hacks your hack works fine on my ROCK 3A with mainline kernel. Best regards, -- FUKAUMI Naoki Radxa > Will continue work on a fully working dwc_eth_qos_rockchip U-Boot driver, > currently having trouble getting TX working, at least RX is working. > > Regards, > Jonas > >> >> Regards, >> Jonas >> >>> >>> Best regards, >>> Michael >>> >>>> [...] > >
Am Montag, 24. Juli 2023, 07:09:48 CEST schrieb FUKAUMI Naoki: > hi, > > On 7/24/23 07:54, Jonas Karlman wrote: > > On 2023-07-17 19:11, Jonas Karlman wrote: > >> On 2023-07-17 09:40, Michael Riesch wrote: > >>> Hi all, > >>> > >>> In addition to what has been already said: > >>> > >>> On 7/16/23 15:50, Jonas Karlman wrote: > >>>> On 2023-07-15 06:49, FUKAUMI Naoki wrote: > >>>>> hi, > >>>>> > >>>>> On 7/15/23 01:24, Jonas Karlman wrote: > >>>>>> On 2023-07-14 17:46, Heiko Stuebner wrote: > >>>>>>> Am Freitag, 14. Juli 2023, 08:30:27 CEST schrieb FUKAUMI Naoki: > >>>>>>>> ethernet on Radxa ROCK 3A is not working by following error: > >>>>>>>> > >>>>>>>> rk_gmac-dwmac fe010000.ethernet eth0: no phy at addr -1 > >>>>>>>> rk_gmac-dwmac fe010000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) > >>>>>>>> > >>>>>>>> to fix this problem, align related properties with vendor kernel > >>>>>>>> https://github.com/radxa/kernel/blob/linux-5.10-gen-rkr4.1/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts > >>>>>>>> > >>>>>>>> Fixes: 22a442e6586c ("arm64: dts: rockchip: add basic dts for the radxa rock3 model a") > >>>>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> > >>>>>>> > >>>>>>> There also is a second patch in the mix adding the gmac1_clkin > >>>>>>> ef9f4b4a5020 ("arm64: dts: rockchip: Add support of external clock to ethernet node on Rock 3A SBC") > >>>>>>> > >>>>>>> And this patch does the exact opposite as the original nodes. > >>>>>>> Can someone please mention board versions? Or did the gmac1 never > >>>>>>> really work in the first place? > >>> > >>> As far as I know all schematics versions state that the PHY produces the > >>> clock (see the most recent schematics here: > >>> https://dl.radxa.com/rock3/docs/hw/3a/ROCK-3A-V1.3-SCH.pdf > >>> > >>> Although using the internal MAC clock works as well, using the > >>> gmac1_clkin is most probably the correct way. > >>> > >>>>>> Ethernet have worked and probably still works booting with vendor U-Boot. > >>>>>> > >>>>>> However, when booting using mainline U-Boot the ethernet PHY is never > >>>>>> initialized or reset due to lack of a ethernet gmac driver for rk35xx. > >>>>> > >>>>> surely I'm using mainline u-boot. > >>> > >>> Ah, this might explain why I never experienced this issue: I am using > >>> mainline barebox with GMAC support. > >>> > >>>>>> With an early work-in-progress gmac driver the ethernet PHY is working > >>>>>> same as with vendor U-Boot, and the ethernet PHY is identified. > >>>>>> > >>>>>> This revert from using reset-gpios to using the deprecated > >>>>>> snps,reset-gpio is probably the wrong way forward. > >>>>>> > >>>>>> I suspect there is a bug in net/phy/mdio_device.c on how reset-gpios > >>>>>> is asserted/deasserted, it works differently than how I would expect it > >>>>>> to work, and also differs in how U-Boot handles reset-gpios. > >>>>>> > >>>>>> Some earlier findings regarding this reset issue: > >>>>>> https://github.com/Kwiboo/linux-rockchip/compare/rk3568-eth-phy-reset~2...rk3568-eth-phy-reset > >>>>>> > >>>>>> Will try to get a proper patch/rfc out later this weekend or early next > >>>>>> week after re-testing that on latest kernel. > >>>>> > >>>>> thank you so much for your awesome work! > >>>> > >>>> Thanks, made some progress on tracking down the root cause. > >>>> From what I have discovered so far there is a chicken-and-egg problem: > >>>> > >>>> - phy needs to be reset or phy_id read back as 0xffffffff on mdio bus > >>>> - phy device is not created because a valid phy_id is not read back > >>>> - phy device needs to be created before it can be reset > >>>> > >>>> Possible workarounds so far: > >>>> - phy is reset in U-Boot > >>>> - very early work-in-progress at https://github.com/Kwiboo/u-boot-rockchip/commit/6ee80f9a895a32551cf30dd4252a4960ed80dfc9 > >>>> - phy is reset using mdio bus reset > >>>> - similar to old https://github.com/Kwiboo/linux-rockchip/commit/8597fcfa0c5c792dabb44a2db7b283c56c99ec6a > >>>> - phy is reset using deprecated snps,reset-gpio > >>>> - similar to mdio bus reset > >>> > >>> There was a similar discussion here: > >>> https://lore.kernel.org/all/CAMdYzYo_DGiO0UxJEb3xues7Um=X9AgPvz+Xp_YWb9pp9HaScg@mail.gmail.com/ > >>> > >>> The approach that moves the reset to the MDIO bus has been mentioned > >>> there as well. On the first glance this approach looks reasonable to me. > >> > >> It does not look like U-Boot support mdio bus reset-gpios, so changing > >> to that would require adding even more code into U-Boot to get ethernet > >> working in U-Boot. > >> > >> Moving to mdio bus would make it behave like with old snps,reset-gpio, > >> however phy reset-gpios still describe the hw more accurately, a > >> assert/deassert cycle of reset-gpios triggers a phy hard reset. > >> > >> Do not know if it is possible to have both mdio bus reset and phy reset. > >> > >> There also looks like there is a bug in dwmac-rk rk3568_set_to_rgmii, > >> tx/rx delay is always enabled. It should be disabled in some phy modes. > >> Can send a patch once I finish with the U-Boot ethernet driver. > >> > >> Will try to complete a U-Boot driver that supports both phy reset-gpios > >> and the deprecated snps,reset-gpio as a first step. > > > > I have now created a small U-Boot dummy ethernet phy reset driver that > > will assert/deassert reset-gpios to help make linux detect the PHY. > > > > With this my ROCK 3 Model B detects the RTL8211F PHY again without any > > changes to linux device tree. > > > > See the U-Boot patch "HACK: net: Add dummy PHY reset-gpios driver" > > at https://github.com/Kwiboo/u-boot-rockchip/commits/rk3568-2023.10-hacks > > your hack works fine on my ROCK 3A with mainline kernel. very nice. Jonas, thanks for working on that. So I'll disregard this dt patch. Heiko
2023-07-24 20:48 időpontban Heiko Stuebner ezt írta: > Am Montag, 24. Juli 2023, 07:09:48 CEST schrieb FUKAUMI Naoki: >> hi, Hi >> >> On 7/24/23 07:54, Jonas Karlman wrote: >> > On 2023-07-17 19:11, Jonas Karlman wrote: >> >> On 2023-07-17 09:40, Michael Riesch wrote: >> >>> Hi all, >> >>> >> >>> In addition to what has been already said: >> >>> >> >>> On 7/16/23 15:50, Jonas Karlman wrote: >> >>>> On 2023-07-15 06:49, FUKAUMI Naoki wrote: >> >>>>> hi, >> >>>>> >> >>>>> On 7/15/23 01:24, Jonas Karlman wrote: >> >>>>>> On 2023-07-14 17:46, Heiko Stuebner wrote: >> >>>>>>> Am Freitag, 14. Juli 2023, 08:30:27 CEST schrieb FUKAUMI Naoki: >> >>>>>>>> ethernet on Radxa ROCK 3A is not working by following error: >> >>>>>>>> >> >>>>>>>> rk_gmac-dwmac fe010000.ethernet eth0: no phy at addr -1 >> >>>>>>>> rk_gmac-dwmac fe010000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) >> >>>>>>>> >> >>>>>>>> to fix this problem, align related properties with vendor kernel >> >>>>>>>> https://github.com/radxa/kernel/blob/linux-5.10-gen-rkr4.1/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >> >>>>>>>> >> >>>>>>>> Fixes: 22a442e6586c ("arm64: dts: rockchip: add basic dts for the radxa rock3 model a") >> >>>>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> >> >>>>>>> >> >>>>>>> There also is a second patch in the mix adding the gmac1_clkin >> >>>>>>> ef9f4b4a5020 ("arm64: dts: rockchip: Add support of external clock to ethernet node on Rock 3A SBC") >> >>>>>>> >> >>>>>>> And this patch does the exact opposite as the original nodes. >> >>>>>>> Can someone please mention board versions? Or did the gmac1 never >> >>>>>>> really work in the first place? >> >>> >> >>> As far as I know all schematics versions state that the PHY produces the >> >>> clock (see the most recent schematics here: >> >>> https://dl.radxa.com/rock3/docs/hw/3a/ROCK-3A-V1.3-SCH.pdf >> >>> >> >>> Although using the internal MAC clock works as well, using the >> >>> gmac1_clkin is most probably the correct way. >> >>> >> >>>>>> Ethernet have worked and probably still works booting with vendor U-Boot. >> >>>>>> >> >>>>>> However, when booting using mainline U-Boot the ethernet PHY is never >> >>>>>> initialized or reset due to lack of a ethernet gmac driver for rk35xx. >> >>>>> >> >>>>> surely I'm using mainline u-boot. >> >>> >> >>> Ah, this might explain why I never experienced this issue: I am using >> >>> mainline barebox with GMAC support. >> >>> >> >>>>>> With an early work-in-progress gmac driver the ethernet PHY is working >> >>>>>> same as with vendor U-Boot, and the ethernet PHY is identified. >> >>>>>> >> >>>>>> This revert from using reset-gpios to using the deprecated >> >>>>>> snps,reset-gpio is probably the wrong way forward. >> >>>>>> >> >>>>>> I suspect there is a bug in net/phy/mdio_device.c on how reset-gpios >> >>>>>> is asserted/deasserted, it works differently than how I would expect it >> >>>>>> to work, and also differs in how U-Boot handles reset-gpios. >> >>>>>> >> >>>>>> Some earlier findings regarding this reset issue: >> >>>>>> https://github.com/Kwiboo/linux-rockchip/compare/rk3568-eth-phy-reset~2...rk3568-eth-phy-reset >> >>>>>> >> >>>>>> Will try to get a proper patch/rfc out later this weekend or early next >> >>>>>> week after re-testing that on latest kernel. >> >>>>> >> >>>>> thank you so much for your awesome work! >> >>>> >> >>>> Thanks, made some progress on tracking down the root cause. >> >>>> From what I have discovered so far there is a chicken-and-egg problem: >> >>>> >> >>>> - phy needs to be reset or phy_id read back as 0xffffffff on mdio bus >> >>>> - phy device is not created because a valid phy_id is not read back >> >>>> - phy device needs to be created before it can be reset >> >>>> >> >>>> Possible workarounds so far: >> >>>> - phy is reset in U-Boot >> >>>> - very early work-in-progress at https://github.com/Kwiboo/u-boot-rockchip/commit/6ee80f9a895a32551cf30dd4252a4960ed80dfc9 >> >>>> - phy is reset using mdio bus reset >> >>>> - similar to old https://github.com/Kwiboo/linux-rockchip/commit/8597fcfa0c5c792dabb44a2db7b283c56c99ec6a >> >>>> - phy is reset using deprecated snps,reset-gpio >> >>>> - similar to mdio bus reset >> >>> >> >>> There was a similar discussion here: >> >>> https://lore.kernel.org/all/CAMdYzYo_DGiO0UxJEb3xues7Um=X9AgPvz+Xp_YWb9pp9HaScg@mail.gmail.com/ >> >>> >> >>> The approach that moves the reset to the MDIO bus has been mentioned >> >>> there as well. On the first glance this approach looks reasonable to me. >> >> >> >> It does not look like U-Boot support mdio bus reset-gpios, so changing >> >> to that would require adding even more code into U-Boot to get ethernet >> >> working in U-Boot. >> >> >> >> Moving to mdio bus would make it behave like with old snps,reset-gpio, >> >> however phy reset-gpios still describe the hw more accurately, a >> >> assert/deassert cycle of reset-gpios triggers a phy hard reset. >> >> >> >> Do not know if it is possible to have both mdio bus reset and phy reset. >> >> >> >> There also looks like there is a bug in dwmac-rk rk3568_set_to_rgmii, >> >> tx/rx delay is always enabled. It should be disabled in some phy modes. >> >> Can send a patch once I finish with the U-Boot ethernet driver. >> >> >> >> Will try to complete a U-Boot driver that supports both phy reset-gpios >> >> and the deprecated snps,reset-gpio as a first step. >> > >> > I have now created a small U-Boot dummy ethernet phy reset driver that >> > will assert/deassert reset-gpios to help make linux detect the PHY. >> > >> > With this my ROCK 3 Model B detects the RTL8211F PHY again without any >> > changes to linux device tree. >> > >> > See the U-Boot patch "HACK: net: Add dummy PHY reset-gpios driver" >> > at https://github.com/Kwiboo/u-boot-rockchip/commits/rk3568-2023.10-hacks >> >> your hack works fine on my ROCK 3A with mainline kernel. > > very nice. Jonas, thanks for working on that. > > So I'll disregard this dt patch. > While this sounds good to me also, that we have a solution, would it not be linux kernels sole task to initialize devices on its own? I mean, why is this treated as an u-boot bug? This way the linux kernel will depend on specific u-boot version, and perhaps specific u-boot features, compile time options. I assume there are many other devices which u-boot does not support, and linux can initialize it well. So, would not be there a way to fix this only in linux kernel? Thanks, regards, Richard > > Heiko > > > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip
On 2023-08-05 18:22, Richard Kojedzinszky wrote: > 2023-07-24 20:48 időpontban Heiko Stuebner ezt írta: >> Am Montag, 24. Juli 2023, 07:09:48 CEST schrieb FUKAUMI Naoki: >>> hi, > > Hi > >>> >>> On 7/24/23 07:54, Jonas Karlman wrote: >>>> On 2023-07-17 19:11, Jonas Karlman wrote: >>>>> On 2023-07-17 09:40, Michael Riesch wrote: >>>>>> Hi all, >>>>>> >>>>>> In addition to what has been already said: >>>>>> >>>>>> On 7/16/23 15:50, Jonas Karlman wrote: >>>>>>> On 2023-07-15 06:49, FUKAUMI Naoki wrote: >>>>>>>> hi, >>>>>>>> >>>>>>>> On 7/15/23 01:24, Jonas Karlman wrote: >>>>>>>>> On 2023-07-14 17:46, Heiko Stuebner wrote: >>>>>>>>>> Am Freitag, 14. Juli 2023, 08:30:27 CEST schrieb FUKAUMI Naoki: >>>>>>>>>>> ethernet on Radxa ROCK 3A is not working by following error: >>>>>>>>>>> >>>>>>>>>>> rk_gmac-dwmac fe010000.ethernet eth0: no phy at addr -1 >>>>>>>>>>> rk_gmac-dwmac fe010000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) >>>>>>>>>>> >>>>>>>>>>> to fix this problem, align related properties with vendor kernel >>>>>>>>>>> https://github.com/radxa/kernel/blob/linux-5.10-gen-rkr4.1/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts >>>>>>>>>>> >>>>>>>>>>> Fixes: 22a442e6586c ("arm64: dts: rockchip: add basic dts for the radxa rock3 model a") >>>>>>>>>>> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> >>>>>>>>>> >>>>>>>>>> There also is a second patch in the mix adding the gmac1_clkin >>>>>>>>>> ef9f4b4a5020 ("arm64: dts: rockchip: Add support of external clock to ethernet node on Rock 3A SBC") >>>>>>>>>> >>>>>>>>>> And this patch does the exact opposite as the original nodes. >>>>>>>>>> Can someone please mention board versions? Or did the gmac1 never >>>>>>>>>> really work in the first place? >>>>>> >>>>>> As far as I know all schematics versions state that the PHY produces the >>>>>> clock (see the most recent schematics here: >>>>>> https://dl.radxa.com/rock3/docs/hw/3a/ROCK-3A-V1.3-SCH.pdf >>>>>> >>>>>> Although using the internal MAC clock works as well, using the >>>>>> gmac1_clkin is most probably the correct way. >>>>>> >>>>>>>>> Ethernet have worked and probably still works booting with vendor U-Boot. >>>>>>>>> >>>>>>>>> However, when booting using mainline U-Boot the ethernet PHY is never >>>>>>>>> initialized or reset due to lack of a ethernet gmac driver for rk35xx. >>>>>>>> >>>>>>>> surely I'm using mainline u-boot. >>>>>> >>>>>> Ah, this might explain why I never experienced this issue: I am using >>>>>> mainline barebox with GMAC support. >>>>>> >>>>>>>>> With an early work-in-progress gmac driver the ethernet PHY is working >>>>>>>>> same as with vendor U-Boot, and the ethernet PHY is identified. >>>>>>>>> >>>>>>>>> This revert from using reset-gpios to using the deprecated >>>>>>>>> snps,reset-gpio is probably the wrong way forward. >>>>>>>>> >>>>>>>>> I suspect there is a bug in net/phy/mdio_device.c on how reset-gpios >>>>>>>>> is asserted/deasserted, it works differently than how I would expect it >>>>>>>>> to work, and also differs in how U-Boot handles reset-gpios. >>>>>>>>> >>>>>>>>> Some earlier findings regarding this reset issue: >>>>>>>>> https://github.com/Kwiboo/linux-rockchip/compare/rk3568-eth-phy-reset~2...rk3568-eth-phy-reset >>>>>>>>> >>>>>>>>> Will try to get a proper patch/rfc out later this weekend or early next >>>>>>>>> week after re-testing that on latest kernel. >>>>>>>> >>>>>>>> thank you so much for your awesome work! >>>>>>> >>>>>>> Thanks, made some progress on tracking down the root cause. >>>>>>> From what I have discovered so far there is a chicken-and-egg problem: >>>>>>> >>>>>>> - phy needs to be reset or phy_id read back as 0xffffffff on mdio bus >>>>>>> - phy device is not created because a valid phy_id is not read back >>>>>>> - phy device needs to be created before it can be reset >>>>>>> >>>>>>> Possible workarounds so far: >>>>>>> - phy is reset in U-Boot >>>>>>> - very early work-in-progress at https://github.com/Kwiboo/u-boot-rockchip/commit/6ee80f9a895a32551cf30dd4252a4960ed80dfc9 >>>>>>> - phy is reset using mdio bus reset >>>>>>> - similar to old https://github.com/Kwiboo/linux-rockchip/commit/8597fcfa0c5c792dabb44a2db7b283c56c99ec6a >>>>>>> - phy is reset using deprecated snps,reset-gpio >>>>>>> - similar to mdio bus reset >>>>>> >>>>>> There was a similar discussion here: >>>>>> https://lore.kernel.org/all/CAMdYzYo_DGiO0UxJEb3xues7Um=X9AgPvz+Xp_YWb9pp9HaScg@mail.gmail.com/ >>>>>> >>>>>> The approach that moves the reset to the MDIO bus has been mentioned >>>>>> there as well. On the first glance this approach looks reasonable to me. >>>>> >>>>> It does not look like U-Boot support mdio bus reset-gpios, so changing >>>>> to that would require adding even more code into U-Boot to get ethernet >>>>> working in U-Boot. >>>>> >>>>> Moving to mdio bus would make it behave like with old snps,reset-gpio, >>>>> however phy reset-gpios still describe the hw more accurately, a >>>>> assert/deassert cycle of reset-gpios triggers a phy hard reset. >>>>> >>>>> Do not know if it is possible to have both mdio bus reset and phy reset. >>>>> >>>>> There also looks like there is a bug in dwmac-rk rk3568_set_to_rgmii, >>>>> tx/rx delay is always enabled. It should be disabled in some phy modes. >>>>> Can send a patch once I finish with the U-Boot ethernet driver. >>>>> >>>>> Will try to complete a U-Boot driver that supports both phy reset-gpios >>>>> and the deprecated snps,reset-gpio as a first step. >>>> >>>> I have now created a small U-Boot dummy ethernet phy reset driver that >>>> will assert/deassert reset-gpios to help make linux detect the PHY. >>>> >>>> With this my ROCK 3 Model B detects the RTL8211F PHY again without any >>>> changes to linux device tree. >>>> >>>> See the U-Boot patch "HACK: net: Add dummy PHY reset-gpios driver" >>>> at https://github.com/Kwiboo/u-boot-rockchip/commits/rk3568-2023.10-hacks >>> >>> your hack works fine on my ROCK 3A with mainline kernel. >> >> very nice. Jonas, thanks for working on that. >> >> So I'll disregard this dt patch. >> > > While this sounds good to me also, that we have a solution, would it not > be linux kernels sole task to initialize devices on its own? I mean, why > is this treated as an u-boot bug? This way the linux kernel will depend > on specific u-boot version, and perhaps specific u-boot features, > compile time options. I assume there are many other devices which u-boot > does not support, and linux can initialize it well. I fully agree that this should also be fixed in linux, but not by reverting to use deprecated DT properties as done in this patch. Big progress has also been made on the U-Boot front and a GMAC driver for RK356x and RK3588 will be posted any day now. See https://github.com/Kwiboo/u-boot-rockchip/commits/rk3568-2023.10-gmac for a fully working work-in-progress state of such series. There are some dependencies to sort out first, like porting the IO-domain driver. > > So, would not be there a way to fix this only in linux kernel? It should be possible, not something I will be looking into. Doing a proper gpio assert/deassert cycle before trying to read back the phy_id should fix this issue and allow the PHY to be registered. As I mentioned earlier there is a chicken-and-egg problem to be solved: - phy needs to be reset or phy_id read back as 0xffffffff on mdio bus - phy device is not created because a valid phy_id is not read back - phy device needs to be created before it can be reset A reset need to happen before/during this call chain: stmmac_mdio_register() -> of_mdiobus_register() -> of_mdiobus_register_phy() -> fwnode_mdiobus_register_phy() -> get_phy_device() -> get_phy_c22_id() -> mdiobus_read(bus, addr, MII_PHYSID1) Here mdiobus_read cannot read back the phy_id unless the PHY has been reset. This is why the deprecated props work, the reset is issued before/during stmmac_mdio_register(). Or at the mdiobus level, the reset is issued before/during of_mdiobus_register(). With reset at phy level the reset happens after device is created, after phy_id has been read, hence a chicken-and-egg problem. The following commit was able at least reset the PHY correctly some linux versions ago. This worked because stmmac_init_phy() would somehow end up calling mdio_device_reset() and a PHY could be probed after that. https://github.com/Kwiboo/linux-rockchip/commit/c338ed260bfd87277c41aa0290f1f2aad8d629b1 I think the commit 8fbc10b995a5 ("net: stmmac: check fwnode for phy device before scanning for phy") changed this behavior and now the phy must be registered during the above call chain to later be picked up by in the stmmac_init_phy() call. Hope this can help if someone wants to dig more into this issue and work on a proper fix for the linux side. Regards, Jonas > > Thanks, regards, > Richard > >> >> Heiko >> >>
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts index 917f5b2b8aab..f9381ab9629b 100644 --- a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts +++ b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts @@ -32,13 +32,6 @@ hdmi_con_in: endpoint { }; }; - gmac1_clkin: external-gmac1-clock { - compatible = "fixed-clock"; - clock-frequency = <125000000>; - clock-output-names = "gmac1_clkin"; - #clock-cells = <0>; - }; - leds { compatible = "gpio-leds"; @@ -256,18 +249,24 @@ &cpu3 { &gmac1 { assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>; - assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>, <&gmac1_clkin>; - clock_in_out = "input"; + assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>; + assigned-clock-rates = <0>, <125000000>; + clock_in_out = "output"; phy-handle = <&rgmii_phy1>; - phy-mode = "rgmii-id"; + phy-mode = "rgmii"; phy-supply = <&vcc_3v3>; pinctrl-names = "default"; pinctrl-0 = <&gmac1m1_miim &gmac1m1_tx_bus2 &gmac1m1_rx_bus2 &gmac1m1_rgmii_clk - &gmac1m1_clkinout &gmac1m1_rgmii_bus>; + snps,reset-gpio = <&gpio3 RK_PB0 GPIO_ACTIVE_LOW>; + snps,reset-active-low; + /* Reset time is 20ms, 100ms for rtl8211f */ + snps,reset-delays-us = <0 20000 100000>; + tx_delay = <0x42>; + rx_delay = <0x28>; status = "okay"; }; @@ -588,11 +587,6 @@ &mdio1 { rgmii_phy1: ethernet-phy@0 { compatible = "ethernet-phy-ieee802.3-c22"; reg = <0x0>; - pinctrl-names = "default"; - pinctrl-0 = <ð_phy_rst>; - reset-assert-us = <20000>; - reset-deassert-us = <100000>; - reset-gpios = <&gpio3 RK_PB0 GPIO_ACTIVE_LOW>; }; }; @@ -630,12 +624,6 @@ vcc_mipi_en: vcc_mipi_en { }; }; - ethernet { - eth_phy_rst: eth_phy_rst { - rockchip,pins = <3 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>; - }; - }; - hym8563 { hym8563_int: hym8563-int { rockchip,pins = <0 RK_PD3 RK_FUNC_GPIO &pcfg_pull_up>;
ethernet on Radxa ROCK 3A is not working by following error: rk_gmac-dwmac fe010000.ethernet eth0: no phy at addr -1 rk_gmac-dwmac fe010000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) to fix this problem, align related properties with vendor kernel https://github.com/radxa/kernel/blob/linux-5.10-gen-rkr4.1/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts Fixes: 22a442e6586c ("arm64: dts: rockchip: add basic dts for the radxa rock3 model a") Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> --- .../boot/dts/rockchip/rk3568-rock-3a.dts | 32 ++++++------------- 1 file changed, 10 insertions(+), 22 deletions(-)