* MT7621 SoC Traffic Won't Flow on RGMII2 Bus/2nd GMAC @ 2022-01-22 18:01 Arınç ÜNAL 2022-01-23 6:51 ` DENG Qingfang 0 siblings, 1 reply; 8+ messages in thread From: Arınç ÜNAL @ 2022-01-22 18:01 UTC (permalink / raw) To: Luiz Angelo Daros de Luca, DENG Qingfang, Matthias Brugger, John Crispin, Siddhant Gupta, Ilya Lipnitskiy, Sergio Paracuellos, Felix Fietkau, Sean Wang, Mark Lee, Russell King, Jakub Kicinski, David Miller, René van Dorst Cc: linux-mediatek, netdev, linux-mips, devicetree, openwrt-devel, erkin.bozoglu [-- Attachment #1: Type: text/plain, Size: 2200 bytes --] Hi all, The company I currently work for has got an Ralink mt7621a board with an external phy connected. It's a Realtek rtl8367s switch. I've been running gregkh/staging staging-next & netdev/net-next master branches with Sergio's "clk: ralink: make system controller a reset provider" v8 patch series. We don't have traffic flow on the RGMII2 bus which is shared by the 2nd GMAC of the SoC, MT7530's GMAC5 and an external phy (rtl switch in our case). According to Documentation/devicetree/bindings/net/dsa/mt7530.txt, I can either configure the external phy to connect to the second GMAC of the mt7621 SoC or to MT7530's GMAC5 to create a cascade. None of the documented configurations work: External phy <-> 2nd GMAC External phy <-> MT7530's GMAC5 The external switch works with Mediatek SDK ethernet driver on External phy <-> 2nd GMAC mode. I suspect there is a problem with the mtk_eth_soc driver on upstream. Same issue on 5.10 (OpenWrt Master) and 4.14 (OpenWrt 19.07) The board's RTL8367S schematics is in the attachments. Dumbed down wiring scheme: CPU ┌───────────────┐ │ GMAC0 | GMAC1 │ └───┼───────┼───┘ │ │ ┌────────────┼┐ │ MT7530 │0 1 2 3 4 5 6│ │ └─────────────┘ │ ┌───────┘ ┌────────────┼┐ RTL8367S │0 1 2 3 4 6 7│ └┼─┼─┼─┼─┼────┘ ┌───────┘ │ │ │ └───────┐ │ ┌───┘ │ └───┐ │ │ │ │ │ │ │ │ │ │ │ ┌───┼─────┼─────┼─────┼─────┼───┐ │ sw1p0 sw1p1 sw1p2 sw1p3 sw1p4 │ └───────────────────────────────┘ Cheers. Arınç [-- Attachment #2: Xeront_7531_8367.pdf --] [-- Type: application/pdf, Size: 361521 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MT7621 SoC Traffic Won't Flow on RGMII2 Bus/2nd GMAC 2022-01-22 18:01 MT7621 SoC Traffic Won't Flow on RGMII2 Bus/2nd GMAC Arınç ÜNAL @ 2022-01-23 6:51 ` DENG Qingfang 2022-01-23 8:33 ` Arınç ÜNAL 0 siblings, 1 reply; 8+ messages in thread From: DENG Qingfang @ 2022-01-23 6:51 UTC (permalink / raw) To: Arınç ÜNAL Cc: Luiz Angelo Daros de Luca, Matthias Brugger, John Crispin, Siddhant Gupta, Ilya Lipnitskiy, Sergio Paracuellos, Felix Fietkau, Sean Wang, Mark Lee, Russell King, Jakub Kicinski, David Miller, René van Dorst, moderated list:ARM/Mediatek SoC support, netdev, linux-mips, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, openwrt-devel, erkin.bozoglu Hi, Do you set the ethernet pinmux correctly? ðernet { pinctrl-names = "default"; pinctrl-0 = <&rgmii1_pins &rgmii2_pins &mdio_pins>; }; ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MT7621 SoC Traffic Won't Flow on RGMII2 Bus/2nd GMAC 2022-01-23 6:51 ` DENG Qingfang @ 2022-01-23 8:33 ` Arınç ÜNAL 2022-01-23 15:26 ` Andrew Lunn 0 siblings, 1 reply; 8+ messages in thread From: Arınç ÜNAL @ 2022-01-23 8:33 UTC (permalink / raw) To: DENG Qingfang Cc: Luiz Angelo Daros de Luca, Matthias Brugger, John Crispin, Siddhant Gupta, Ilya Lipnitskiy, Sergio Paracuellos, Felix Fietkau, Sean Wang, Mark Lee, Russell King, Jakub Kicinski, David Miller, René van Dorst, moderated list:ARM/Mediatek SoC support, netdev, linux-mips, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, openwrt-devel, erkin.bozoglu Hey Deng, On 23/01/2022 09:51, DENG Qingfang wrote: > Hi, > > Do you set the ethernet pinmux correctly? > > ðernet { > pinctrl-names = "default"; > pinctrl-0 = <&rgmii1_pins &rgmii2_pins &mdio_pins>; > }; This fixed it! We did have &rgmii2_pins on the gmac1 node (it was originally on external_phy) so we never thought to investigate the pinctrl configuration further! Turns out &rgmii2_pins needs to be defined on the ethernet node instead. I'll send a patch to address this on mt7621.dtsi. You saved us a bunch of time, thank you very much! Cheers. Arınç ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MT7621 SoC Traffic Won't Flow on RGMII2 Bus/2nd GMAC 2022-01-23 8:33 ` Arınç ÜNAL @ 2022-01-23 15:26 ` Andrew Lunn 2022-01-23 17:48 ` Arınç ÜNAL 2022-01-24 17:13 ` Florian Fainelli 0 siblings, 2 replies; 8+ messages in thread From: Andrew Lunn @ 2022-01-23 15:26 UTC (permalink / raw) To: Arınç ÜNAL Cc: DENG Qingfang, Luiz Angelo Daros de Luca, Matthias Brugger, John Crispin, Siddhant Gupta, Ilya Lipnitskiy, Sergio Paracuellos, Felix Fietkau, Sean Wang, Mark Lee, Russell King, Jakub Kicinski, David Miller, René van Dorst, moderated list:ARM/Mediatek SoC support, netdev, linux-mips, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, openwrt-devel, erkin.bozoglu On Sun, Jan 23, 2022 at 11:33:04AM +0300, Arınç ÜNAL wrote: > Hey Deng, > > On 23/01/2022 09:51, DENG Qingfang wrote: > > Hi, > > > > Do you set the ethernet pinmux correctly? > > > > ðernet { > > pinctrl-names = "default"; > > pinctrl-0 = <&rgmii1_pins &rgmii2_pins &mdio_pins>; > > }; > > This fixed it! We did have &rgmii2_pins on the gmac1 node (it was originally > on external_phy) so we never thought to investigate the pinctrl > configuration further! Turns out &rgmii2_pins needs to be defined on the > ethernet node instead. PHYs are generally external, so pinmux on them makes no sense. PHYs in DT are not devices in the usual sense, so i don't think the driver core will handle pinmux for them, even if you did list them. This could be interesting for the DT compliance checker. Ideally we want it to warn if it finds a pinmux configuration in a PHY node. It also sounds like you had them somewhere else wrong? Andrew ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MT7621 SoC Traffic Won't Flow on RGMII2 Bus/2nd GMAC 2022-01-23 15:26 ` Andrew Lunn @ 2022-01-23 17:48 ` Arınç ÜNAL 2022-01-24 17:13 ` Florian Fainelli 1 sibling, 0 replies; 8+ messages in thread From: Arınç ÜNAL @ 2022-01-23 17:48 UTC (permalink / raw) To: Andrew Lunn Cc: DENG Qingfang, Luiz Angelo Daros de Luca, Matthias Brugger, John Crispin, Siddhant Gupta, Ilya Lipnitskiy, Sergio Paracuellos, Felix Fietkau, Sean Wang, Mark Lee, Russell King, Jakub Kicinski, David Miller, René van Dorst, moderated list:ARM/Mediatek SoC support, netdev, linux-mips, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, openwrt-devel, erkin.bozoglu On 23/01/2022 18:26, Andrew Lunn wrote: > On Sun, Jan 23, 2022 at 11:33:04AM +0300, Arınç ÜNAL wrote: >> Hey Deng, >> >> On 23/01/2022 09:51, DENG Qingfang wrote: >>> Hi, >>> >>> Do you set the ethernet pinmux correctly? >>> >>> ðernet { >>> pinctrl-names = "default"; >>> pinctrl-0 = <&rgmii1_pins &rgmii2_pins &mdio_pins>; >>> }; >> >> This fixed it! We did have &rgmii2_pins on the gmac1 node (it was originally >> on external_phy) so we never thought to investigate the pinctrl >> configuration further! Turns out &rgmii2_pins needs to be defined on the >> ethernet node instead. > > PHYs are generally external, so pinmux on them makes no sense. PHYs in > DT are not devices in the usual sense, so i don't think the driver > core will handle pinmux for them, even if you did list them. > > This could be interesting for the DT compliance checker. Ideally we > want it to warn if it finds a pinmux configuration in a PHY node. I don't see any warnings about it: $ cpp -nostdinc -I include -I arch -undef -x assembler-with-cpp drivers/staging/mt7621-dts/mt7621.dtsi mt7621.dtsi.preprocessed $ dtc -I dts -O dtb -p 0x1000 mt7621.dtsi.preprocessed -o mt7621.dtb drivers/staging/mt7621-dts/mt7621.dtsi:28.21-33.4: Warning (unit_address_vs_reg): /cpuintc@0: node has a unit name, but no reg property drivers/staging/mt7621-dts/mt7621.dtsi:40.34-47.6: Warning (unit_address_vs_reg): /fixedregulator@0: node has a unit name, but no reg property drivers/staging/mt7621-dts/mt7621.dtsi:49.39-56.4: Warning (unit_address_vs_reg): /fixedregulator@1: node has a unit name, but no reg property drivers/staging/mt7621-dts/mt7621.dtsi:410.11-449.7: Warning (unit_address_vs_reg): /ethernet@1e100000/mdio-bus/switch0@0/ports: node has a reg or ranges property, but no unit name drivers/staging/mt7621-dts/mt7621.dtsi:28.21-33.4: Warning (unique_unit_address): /cpuintc@0: duplicate unit-address (also used in node /fixedregulator@0) > > It also sounds like you had them somewhere else wrong? Yes, it was under the phy_external node: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/mt7621-dts/mt7621.dtsi#n350 I had put it under gmac1 node instead since we didn't enable the phy_external node. Arınç ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MT7621 SoC Traffic Won't Flow on RGMII2 Bus/2nd GMAC 2022-01-23 15:26 ` Andrew Lunn 2022-01-23 17:48 ` Arınç ÜNAL @ 2022-01-24 17:13 ` Florian Fainelli 2022-01-24 17:26 ` Russell King (Oracle) 1 sibling, 1 reply; 8+ messages in thread From: Florian Fainelli @ 2022-01-24 17:13 UTC (permalink / raw) To: Andrew Lunn, Arınç ÜNAL Cc: DENG Qingfang, Luiz Angelo Daros de Luca, Matthias Brugger, John Crispin, Siddhant Gupta, Ilya Lipnitskiy, Sergio Paracuellos, Felix Fietkau, Sean Wang, Mark Lee, Russell King, Jakub Kicinski, David Miller, René van Dorst, moderated list:ARM/Mediatek SoC support, netdev, linux-mips, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, openwrt-devel, erkin.bozoglu On 1/23/2022 7:26 AM, Andrew Lunn wrote: > On Sun, Jan 23, 2022 at 11:33:04AM +0300, Arınç ÜNAL wrote: >> Hey Deng, >> >> On 23/01/2022 09:51, DENG Qingfang wrote: >>> Hi, >>> >>> Do you set the ethernet pinmux correctly? >>> >>> ðernet { >>> pinctrl-names = "default"; >>> pinctrl-0 = <&rgmii1_pins &rgmii2_pins &mdio_pins>; >>> }; >> >> This fixed it! We did have &rgmii2_pins on the gmac1 node (it was originally >> on external_phy) so we never thought to investigate the pinctrl >> configuration further! Turns out &rgmii2_pins needs to be defined on the >> ethernet node instead. > > PHYs are generally external, so pinmux on them makes no sense. PHYs in > DT are not devices in the usual sense, so i don't think the driver > core will handle pinmux for them, even if you did list them. Not sure I understand your comment here, this is configuring the pinmux on the SoC side in order for the second RGMII interface's data path to work. It is not uncommon for the same set of I/O pads to be used by different functions within the chip. For instance the chips I work with happily offer RGMII, MTSIF, PDM (I2S), TSIO on the same pads via different pinmuxing options. Also, this is declaring a pinmuxing function for the Ethernet MAC, which is a perfectly valid use case and typically how pinmuxing is declared for a given SoC. -- Florian ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MT7621 SoC Traffic Won't Flow on RGMII2 Bus/2nd GMAC 2022-01-24 17:13 ` Florian Fainelli @ 2022-01-24 17:26 ` Russell King (Oracle) 2022-01-24 17:34 ` Florian Fainelli 0 siblings, 1 reply; 8+ messages in thread From: Russell King (Oracle) @ 2022-01-24 17:26 UTC (permalink / raw) To: Florian Fainelli Cc: Andrew Lunn, Arınç ÜNAL, DENG Qingfang, Luiz Angelo Daros de Luca, Matthias Brugger, John Crispin, Siddhant Gupta, Ilya Lipnitskiy, Sergio Paracuellos, Felix Fietkau, Sean Wang, Mark Lee, Jakub Kicinski, David Miller, René van Dorst, moderated list:ARM/Mediatek SoC support, netdev, linux-mips, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, openwrt-devel, erkin.bozoglu On Mon, Jan 24, 2022 at 09:13:38AM -0800, Florian Fainelli wrote: > On 1/23/2022 7:26 AM, Andrew Lunn wrote: > > On Sun, Jan 23, 2022 at 11:33:04AM +0300, Arınç ÜNAL wrote: > > > Hey Deng, > > > > > > On 23/01/2022 09:51, DENG Qingfang wrote: > > > > Hi, > > > > > > > > Do you set the ethernet pinmux correctly? > > > > > > > > ðernet { > > > > pinctrl-names = "default"; > > > > pinctrl-0 = <&rgmii1_pins &rgmii2_pins &mdio_pins>; > > > > }; > > > > > > This fixed it! We did have &rgmii2_pins on the gmac1 node (it was originally > > > on external_phy) so we never thought to investigate the pinctrl > > > configuration further! Turns out &rgmii2_pins needs to be defined on the > > > ethernet node instead. > > > > PHYs are generally external, so pinmux on them makes no sense. PHYs in > > DT are not devices in the usual sense, so i don't think the driver > > core will handle pinmux for them, even if you did list them. > > Not sure I understand your comment here, this is configuring the pinmux on > the SoC side in order for the second RGMII interface's data path to work. The pinmux configuration was listed under the external PHY node, which is qutie unusual. In the case of phylib and external ethernet PHYs, this can be a problem. The pinmux configuration is normally handled at device probe time by the device model, but remember phylib bypasses that when it attaches the generic PHY driver - meaning you don't get the pinmux configured. What this means is that pinmux configuration in ethernet PHY nodes is unreliable. It will only happen if we have a specific driver for the PHY and the driver model binds that driver. Of course, if we killed the generic driver, that would get around this issue by requiring every PHY to have its own specific driver, but there would be many complaints because likely lots would stop working. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MT7621 SoC Traffic Won't Flow on RGMII2 Bus/2nd GMAC 2022-01-24 17:26 ` Russell King (Oracle) @ 2022-01-24 17:34 ` Florian Fainelli 0 siblings, 0 replies; 8+ messages in thread From: Florian Fainelli @ 2022-01-24 17:34 UTC (permalink / raw) To: Russell King (Oracle) Cc: Andrew Lunn, Arınç ÜNAL, DENG Qingfang, Luiz Angelo Daros de Luca, Matthias Brugger, John Crispin, Siddhant Gupta, Ilya Lipnitskiy, Sergio Paracuellos, Felix Fietkau, Sean Wang, Mark Lee, Jakub Kicinski, David Miller, René van Dorst, moderated list:ARM/Mediatek SoC support, netdev, linux-mips, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, openwrt-devel, erkin.bozoglu On 1/24/2022 9:26 AM, Russell King (Oracle) wrote: > On Mon, Jan 24, 2022 at 09:13:38AM -0800, Florian Fainelli wrote: >> On 1/23/2022 7:26 AM, Andrew Lunn wrote: >>> On Sun, Jan 23, 2022 at 11:33:04AM +0300, Arınç ÜNAL wrote: >>>> Hey Deng, >>>> >>>> On 23/01/2022 09:51, DENG Qingfang wrote: >>>>> Hi, >>>>> >>>>> Do you set the ethernet pinmux correctly? >>>>> >>>>> ðernet { >>>>> pinctrl-names = "default"; >>>>> pinctrl-0 = <&rgmii1_pins &rgmii2_pins &mdio_pins>; >>>>> }; >>>> >>>> This fixed it! We did have &rgmii2_pins on the gmac1 node (it was originally >>>> on external_phy) so we never thought to investigate the pinctrl >>>> configuration further! Turns out &rgmii2_pins needs to be defined on the >>>> ethernet node instead. >>> >>> PHYs are generally external, so pinmux on them makes no sense. PHYs in >>> DT are not devices in the usual sense, so i don't think the driver >>> core will handle pinmux for them, even if you did list them. >> >> Not sure I understand your comment here, this is configuring the pinmux on >> the SoC side in order for the second RGMII interface's data path to work. > > The pinmux configuration was listed under the external PHY node, which > is qutie unusual. In the case of phylib and external ethernet PHYs, > this can be a problem. > > The pinmux configuration is normally handled at device probe time by > the device model, but remember phylib bypasses that when it attaches > the generic PHY driver - meaning you don't get the pinmux configured. > > What this means is that pinmux configuration in ethernet PHY nodes is > unreliable. It will only happen if we have a specific driver for the > PHY and the driver model binds that driver. > > Of course, if we killed the generic driver, that would get around this > issue by requiring every PHY to have its own specific driver, but there > would be many complaints because likely lots would stop working. I suppose that explains why this is still in staging then :) Andrew's answer makes more sense now, thanks. -- Florian ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-01-24 17:34 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-01-22 18:01 MT7621 SoC Traffic Won't Flow on RGMII2 Bus/2nd GMAC Arınç ÜNAL 2022-01-23 6:51 ` DENG Qingfang 2022-01-23 8:33 ` Arınç ÜNAL 2022-01-23 15:26 ` Andrew Lunn 2022-01-23 17:48 ` Arınç ÜNAL 2022-01-24 17:13 ` Florian Fainelli 2022-01-24 17:26 ` Russell King (Oracle) 2022-01-24 17:34 ` Florian Fainelli
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).