From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 68F71C47073 for ; Fri, 29 Dec 2023 15:28:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=XsTc1ewIhB0rJY/j2GnG7g57lxRzTjAqLyflXq5GQJE=; b=n9PNIBEfeGJLMr GC0f1y5LLLGQU7taxe1A8qD5Tohx7tdGwIPa5xeyLPc4IY6lqBdGaTQDZeNC61qzwbBL761c381wH kH9lVKL8YaK02HfaH1JawvoW1XWmsX6GtOEIem341ozwS7gFdm62tRRodhJoigGC29JCqotEsdvpE yzQB7YyfVW4uNArYcgwHxpBaNmiE/rJ5CBTgEcsDz7AhHrUmJKg8HG++juJrY4mgIQ2tfZOCt5VgM IJcS/G61+AvD8GxgAUJ4tszFbWJ4vXVSbV7WhA2abpa2uRP/UbTBD3WRC9TGutSsMrjVFQ9X36F4E llu7smxUPRrLwcIbtBAQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rJEjo-0016s7-1I; Fri, 29 Dec 2023 15:25:28 +0000 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rJEjk-0016rS-2x for linux-arm-kernel@lists.infradead.org; Fri, 29 Dec 2023 15:25:26 +0000 Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-40d5b159350so28920145e9.2 for ; Fri, 29 Dec 2023 07:25:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703863522; x=1704468322; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=lYKi1Ed87Lj2j5kXa6dfoEYMvP54594XyZW+zyxicNw=; b=Y7F9oK5zdowf4IdPdgSWmAaMVZ9tgE6fNrt1Q+PeHSoYMhWp/sPpMkNwKTFnzOCDhM fIqw13YCikPMtxe/qHsKrX7mCyTWVgBorOirbyBGh3DFCqrwPnLMI9M2N1c/ipkwD27n aIq/CNlOBYdP1pVQGeJ9xO6kw5ptmsHthlWoYZ3ZpCGG1cJlXlOF5TBmbC6SuU5InHaZ dXNZV1WosFDJiWhACicAuT8jRacoJ+7nvKB73v3juW7JUrOjRiA53Qr9HN0XFVf/wBGW YeYeYotP19C1xNq/BQsyHJS3ti+d5IruGzvxRoYxRbCz8gQbNZVorszmRPMeJ9ZVrT3B r1wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703863522; x=1704468322; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=lYKi1Ed87Lj2j5kXa6dfoEYMvP54594XyZW+zyxicNw=; b=peD8EvageuEQqKoLWEIz9+oxgMcFPaiLaNFfrR8L9yEqMSQEBcAk1TpqQSOhLTO6MN wtARV5ee3tZeftuNDhKxCOEy1/bYCe0qadkaCMY6ZXTSwd53bhFCG5gAWVEpKwlG1+IG L89uJKPCDq4Kv0tkF7BG0vmyU2dqzJ+XUoR8+46kX4giqkJt5KwQlI0ddW00W5Keo7rn 9/RjHEf3N4qP4/Tw3TsZxfaZb94vv5k91bViN8EXYgPPb3gUCcoSybZ3zsXcxTHeO5d4 2BI8/Z9iiuPZuY1Cs90tBuBH3BuMdJehZ+WHsj22Kfopiwtzemt3n/UW7oyG4x5iSY6M ZY7w== X-Gm-Message-State: AOJu0YwT5sPsGQrr03ceL3WZVLhRcNUzp5B9aNUF5Hbe8IFzgIUY5wCo dw5ZbyBcg/ZWozDXQZ6hhJY= X-Google-Smtp-Source: AGHT+IF14/5SoXwRelolZluqulHNoHcSzmTGhalc2XL17YdaShFnZBQnTYxhF+q1E4p3JWCDyiHkZQ== X-Received: by 2002:a05:600c:4450:b0:40c:6a85:e83a with SMTP id v16-20020a05600c445000b0040c6a85e83amr5823353wmn.51.1703863522316; Fri, 29 Dec 2023 07:25:22 -0800 (PST) Received: from skbuf ([188.25.254.184]) by smtp.gmail.com with ESMTPSA id s21-20020a05600c45d500b0040c3953cda5sm39145597wmo.45.2023.12.29.07.25.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Dec 2023 07:25:22 -0800 (PST) Date: Fri, 29 Dec 2023 17:25:19 +0200 From: Vladimir Oltean To: Jagan Teki Cc: Andrew Lunn , Heiner Kallweit , "Andrew F. Davis" , Florian Fainelli , linux-kernel , netdev@vger.kernel.org, Michael Nazzareno Trimarchi , Ioana Ciornei , Shawn Guo , linux-arm-kernel , Fabio Estevam Subject: Re: PHY issue with SJA1105Q/DP84849I Design Message-ID: <20231229152519.2jxrwaeltp4pxlms@skbuf> References: <20231222145100.sfcuux7ayxtxgogo@skbuf> <20231226153055.4yihsmu6kiak6hkf@skbuf> <20231222145100.sfcuux7ayxtxgogo@skbuf> <20231226153055.4yihsmu6kiak6hkf@skbuf> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231229_072524_978797_C148C3A4 X-CRM114-Status: GOOD ( 21.89 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Dec 29, 2023 at 05:12:39PM +0530, Jagan Teki wrote: > With fec0 fixed-link and 3 different switch port configurations, the > result of the link seems to be up but the ping not working and even > the packets are not transmitted via eth0. > > DT Combinations: > > - Port0 is ethphy0, Port1 is ethphy1, Port2 is disabled, Port3 is > disabled, Port4 is FEC > - Port0 is disabled, Port1 is ethphy0, Port2 is ethphy1, Port3 is > disabled, Port4 is FEC > - Port0 is disabled, Port1 is disabled, Port2 is ethphy0, Port3 is > ethphy1, Port4 as FEC Why all these combinations? You don't know which switch port is which? > DT: (with Port0 is ethphy0, Port1 is ethphy1, Port2 is disabled, Port3 > is disabled, Port4 is FEC) > > &ecspi2 { > cs-gpios = <&gpio2 27 GPIO_ACTIVE_HIGH>; > pinctrl-names = "default"; > pinctrl-0 = <&pinctrl_ecspi2>; > status = "okay"; > > switch@0 { > compatible = "nxp,sja1105q"; > reg = <0>; > spi-max-frequency = <4000000>; > spi-rx-delay-us = <1>; > spi-tx-delay-us = <1>; > spi-cpha; > > clocks = <&clk25m>; > > pinctrl-0 = <&pinctrl_sja1105_rst>; > pinctrl-names = "default"; > reset-gpios = <&gpio6 5 GPIO_ACTIVE_LOW>; > > ports { > #address-cells = <1>; > #size-cells = <0>; > > port@0 { > reg = <0>; > label = "ethphy0"; > phy-handle = <ðphy0>; > phy-mode = "mii"; > }; > > port@1 { > reg = <1>; > label = "ethphy1"; > phy-handle = <ðphy1>; > phy-mode = "mii"; > }; > > port@2 { > reg = <2>; > status = "disabled"; > }; > > port@3 { > reg = <3>; > status = "disabled"; > }; > > port@4 { > reg = <4>; > label = "cpu"; > ethernet = <&fec>; > phy-mode = "mii"; > rx-internal-delay-ps = <2000>; > tx-internal-delay-ps = <2000>; This looks suspicious. "rx-internal-delay-ps" and "tx-internal-delay-ps" are only relevant for the RGMII modes, but you specify phy-mode = "mii". Does the board schematic confirm that MII is the physical connection being used from the switch to the FEC? If you are truly using MII, then you should remove the RGMII delay properties, and since you are using a 6.1 kernel - hence after kernel commit 5d645df99ac6 ("net: dsa: sja1105: determine PHY/MAC role from PHY interface type") - you should be using phy-mode = "rev-mii" to put this port in MII PHY ("RevMII") mode - to interoperate with the FEC in MII MAC mode. > > fixed-link { > speed = <100>; > full-duplex; > }; > }; > }; > }; > }; > > &fec { > pinctrl-names = "default"; > pinctrl-0 = <&pinctrl_enet>; > phy-mode = "mii"; > status = "okay"; > > fixed-link { > speed = <100>; > full-duplex; > }; > > mdio { > #address-cells = <1>; > #size-cells = <0>; > > ethphy0: ethernet-phy@0 { > compatible = "ethernet-phy-ieee802.3-c22"; > reg = <0>; > }; > > ethphy1: ethernet-phy@1 { > compatible = "ethernet-phy-ieee802.3-c22"; > reg = <1>; > }; > }; > }; > > root@ltts-imx6solo:~# bash /usr/phynew.sh > ======= MDIO: PHY0 ======== > [ 162.426515] mdio_netlink: loading out-of-tree module taints kernel. Still, please refrain from involving out-of-tree modules when asking for help upstream. Thanks. > root@ltts-imx6solo:~# [ 165.208656] sja1105 spi1.0 ethphy0: Link is > Up - 100Mbps/Full - flow control off > [ 165.225788] sja1105 spi1.0 ethphy1: Link is Up - 100Mbps/Full - > flow control off > [ 165.235925] IPv6: ADDRCONF(NETDEV_CHANGE): ethphy0: link becomes ready > [ 165.255777] IPv6: ADDRCONF(NETDEV_CHANGE): ethphy1: link becomes ready > > root@ltts-imx6solo:~# ifconfig > eth0: flags=4163 mtu 1504 > inet6 fe80::68fb:8ff:fedf:d377 prefixlen 64 scopeid 0x20 > ether 6a:fb:08:df:d3:77 txqueuelen 1000 (Ethernet) > RX packets 0 bytes 0 (0.0 B) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 0 bytes 0 (0.0 B) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > ethphy0: flags=4163 mtu 1500 > inet 169.254.178.1 netmask 255.255.0.0 broadcast 0.0.0.0 > inet6 fe80::211:22ff:fe33:4455 prefixlen 64 scopeid 0x20 > ether 00:11:22:33:44:55 txqueuelen 1000 (Ethernet) > RX packets 0 bytes 0 (0.0 B) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 30 bytes 4071 (3.9 KiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > ethphy1: flags=4163 mtu 1500 > inet 169.253.178.2 netmask 255.255.0.0 broadcast 0.0.0.0 > inet6 fe80::211:22ff:fe33:4466 prefixlen 64 scopeid 0x20 > ether 00:11:22:33:44:66 txqueuelen 1000 (Ethernet) > RX packets 0 bytes 0 (0.0 B) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 30 bytes 4071 (3.9 KiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > lo: flags=73 mtu 65536 > inet 127.0.0.1 netmask 255.0.0.0 > inet6 ::1 prefixlen 128 scopeid 0x10 > loop txqueuelen 1000 (Local Loopback) > RX packets 89 bytes 7675 (7.4 KiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 89 bytes 7675 (7.4 KiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ifconfig reports statistics counters from the /proc/net/dev interface, which the sja1105 does not report very well (they don't come from hardware). It's best to use "ethtool -S eth0 | grep -v ': 0'" for FEC and SJA1105 CPU port (named "p04_*") counters, and "ethtool -S ethphy0 | grep -v ': 0'" to get hardware counters from the switch user ports. You can also use the RX counters to determine which switch port is which (but the phy-handle of each port to each PHY needs to be correct). > mytsl02383@MYTSL02383:~$ ifconfig -a > enp43s0: flags=4163 mtu 1500 > inet 169.254.178.2 netmask 255.255.0.0 broadcast 169.254.255.255 > inet6 fe80::d71b:4bdd:27bd:2a1a prefixlen 64 scopeid 0x20 > ether 00:be:43:20:9a:26 txqueuelen 1000 (Ethernet) > RX packets 272356 bytes 27099064 (27.0 MB) > RX errors 0 dropped 19 overruns 0 frame 0 > TX packets 862 bytes 300806 (300.8 KB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > mytsl02383@MYTSL02383:~$ ping 169.254.178.1 > PING 169.254.178.1 (169.254.178.1) 56(84) bytes of data. > From 169.254.178.2 icmp_seq=1 Destination Host Unreachable > > Let me know if you need any more details. I'm not convinced packets are routed through ethphy0 or ethphy1, since all interfaces have IPv4 link-local addresses only. You can use "ip route get 169.254.178.1" to confirm what interface gets chosen. This is not indicative of a device-level problem, just a setup one. Please set up some IPv4 static addresses which are not link-local on the DSA user ports and try to ping a link partner which has an IP address in the same subnet. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel