Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5970871ybe; Tue, 17 Sep 2019 17:09:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqwnKHgn1UpFGtpkqSquw2onQ87u4b2wcTIzZbrOM/ItRJ9mArrTyZD+Il04ee7DbbJz54Qv X-Received: by 2002:a50:ac0d:: with SMTP id v13mr7419362edc.189.1568765350926; Tue, 17 Sep 2019 17:09:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568765350; cv=none; d=google.com; s=arc-20160816; b=C/pA02U88fwaM1kYDBUPq525l5me7ygQmNcGopxX7Jwx7P0PCM06PBs8xQJisytr7s 6vTBFVKxKkQ1NaTxmCNnbS8ztyiv7NhC3PZkvF3cXhtUpT4dxelMeXYYmMQNWpiLWtDg dsCvQz8Ms+k4XGVIu97U0CAM5HSTB+9D98xViiua0DEcd723D9gbWO9ALUULRxTeMkE7 G3cFZrid/OhhwKr1jvmpQAe6mg39g4t5dZGjkzqejk0w1R1M8zpveAqPr+8tJ2HzraTw PmSGxPH2kyPF2s3ukYRZWgYBz58L0A2rkIsCGyalT1yvCcuXv7ewoRupkOl604wNGoOL Nnqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=kq0CocEY9i4/5e+2igO8Cik75CQMtIKP4GgD17cUQo4=; b=gAMHfcNLkt/A471s6+7r+0fOVMYBeGJ6z+jceBZpo/ujNJfxS2OQvyXrr1X1zg05QU 9lKN+192uYgYNoTI7wuuLfgYu8yEV3V8l4xEoY1uw6LOCHmU0ZEh3w0erTfHQcPVE7kB mRDptRHmZE+5Yy4xZbYWA3iyinK2M7pUKXX1Hh89Ztr57h4vcP8/iCu2EzulwhGic42i u4gJHCO2OBlydfkO76UM7AyT9gnm1FIQiKJ6wmtmJ8u8D6hyleLvh8Y3Ut52QBV0dllc DrIivzWvap5L5RZh9eMk5Hk071y1gzPt9Yn+BfB+6OFMl3XKeyIgIN9Yzlh/crjKKnza vPng== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=W3RKu9YP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c9si2284288eds.211.2019.09.17.17.08.47; Tue, 17 Sep 2019 17:09:10 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=W3RKu9YP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730704AbfIQREd (ORCPT + 99 others); Tue, 17 Sep 2019 13:04:33 -0400 Received: from pandora.armlinux.org.uk ([78.32.30.218]:44108 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730669AbfIQREc (ORCPT ); Tue, 17 Sep 2019 13:04:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kq0CocEY9i4/5e+2igO8Cik75CQMtIKP4GgD17cUQo4=; b=W3RKu9YPCV8TsiO0pKS6tbgX4 6OBHY3CDKjT+9eFudvercZJOcgz3vv584J0P65B9IMswiyIiic+AuoqdJdVqVMkDnmK5gLqlucfLG lW2u5U9nEPUj+VECWwMlbb1+2Wgckt5VeQLKquPObMGA7MBg37Dekn9z5Ulqx8orTsjBwRpSQdy1u ZnuJIvM8C/zOaBB8b2WGypZ0TmrUPvwkOC2xpAp1qCsg52hhGCWpbrDCWHktzULRGnWqXkdN0N1wi j0/cHkDAnPxXs5yeolO/poFT1sSFyHFziscsBI8QquESxddTcJfKPWQxvL3gPLcrW7fwRMFggl3Bf yuUEbrFag==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:44848) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1iAGtr-00035z-Fx; Tue, 17 Sep 2019 18:04:23 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1iAGtn-0001SK-M8; Tue, 17 Sep 2019 18:04:19 +0100 Date: Tue, 17 Sep 2019 18:04:19 +0100 From: Russell King - ARM Linux admin To: tinywrkb Cc: Mark Rutland , Andrew Lunn , Baruch Siach , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Fabio Estevam , Sascha Hauer , open list , Rob Herring , NXP Linux Team , Pengutronix Kernel Team , Shawn Guo , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] ARM: dts: imx6dl: SolidRun: add phy node with 100Mb/s max-speed Message-ID: <20190917170419.GX25745@shell.armlinux.org.uk> References: <20190910185033.GD9761@lunn.ch> <87muf6oyvr.fsf@tarshish> <20190915135652.GC3427@lunn.ch> <20190917124101.GA1200564@arch-dsk-01> <20190917125434.GH20778@lunn.ch> <20190917133253.GA1210141@arch-dsk-01> <20190917133942.GR25745@shell.armlinux.org.uk> <20190917151707.GV25745@shell.armlinux.org.uk> <20190917153027.GW25745@shell.armlinux.org.uk> <20190917163427.GA1475935@arch-dsk-01> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190917163427.GA1475935@arch-dsk-01> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 17, 2019 at 07:34:27PM +0300, tinywrkb wrote: > The patch didn't fix the issue. > > # ethtool eth0 > > Settings for eth0: > Supported ports: [ TP MII ] > Supported link modes: 10baseT/Half 10baseT/Full > 100baseT/Half 100baseT/Full > 1000baseT/Full > Supported pause frame use: Symmetric > Supports auto-negotiation: Yes > Supported FEC modes: Not reported > Advertised link modes: 10baseT/Half 10baseT/Full > 100baseT/Half 100baseT/Full > 1000baseT/Full > Advertised pause frame use: Symmetric > Advertised auto-negotiation: Yes > Advertised FEC modes: Not reported > Link partner advertised link modes: 10baseT/Half 10baseT/Full > 100baseT/Half 100baseT/Full > 1000baseT/Full > Link partner advertised pause frame use: Symmetric > Link partner advertised auto-negotiation: Yes > Link partner advertised FEC modes: Not reported > Speed: 1000Mb/s > Duplex: Full > Port: MII > PHYAD: 0 > Transceiver: internal > Auto-negotiation: on > Supports Wake-on: d > Wake-on: d > Link detected: yes > > # mii-tool -v -v eth0 > > Using SIOCGMIIPHY=0x8947 > eth0: negotiated 100baseTx-FD flow-control, link ok > registers for MII PHY 0: > 3100 796d 004d d072 15e1 c5e1 000f 0000 > 0000 0000 0800 0000 0000 0000 0000 a000 > 0000 0000 0000 f420 082c 0000 04e8 0000 > 3200 3000 0000 063d 0000 0000 0000 0000 > product info: vendor 00:13:74, model 7 rev 2 > basic mode: autonegotiation enabled > basic status: autonegotiation complete, link ok > capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD > advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control > link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control > > # journalctl -b | egrep -i 'phy|eth|fec'|grep -v usb > > kernel: Booting Linux on physical CPU 0x0 > kernel: libphy: Fixed MDIO Bus: probed > kernel: libphy: fec_enet_mii_bus: probed > kernel: fec 2188000.ethernet eth0: registered PHC device 0 > kernel: dwhdmi-imx 120000.hdmi: Detected HDMI TX controller v1.31a with HDCP (DWC HDMI 3D TX PHY) > kernel: Generic PHY 2188000.ethernet-1:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=2188000.ethernet-1:00, irq=POLL) > kernel: fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx > kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > systemd-networkd[242]: eth0: Gained carrier Okay, so this is getting weird. ethtool still shows that 1000baseT/Full is being advertised, yet the PHY disagrees: 3100 796d 004d d072 15e1 c5e1 000f 0000 0000 0000 0800 0000 0000 0000 0000 a000 ^^^^ Gigabit control register, bits 9 should be set, but it's clear. Looking at the following registers, brings up another possibility what is going on: 0000 0000 0000 f420 082c 0000 04e8 0000 ^^^^ ^^^^ These two registers may provide a hint. Of the first register, which is the interrupt status register, bit 5 is set, indicating that a "smartspeed downgrade occurred". The second register is the smartspeed configuration, which basically says that the feature is enabled. Smartspeed is designed to allow the link to come up if two-pair CAT5 cable is used (are you using a 4-pair or 2-pair cable?) by making the link fall back to 100mbit, or with CAT3 cable, 10mbit speeds. What isn't specified is whether it does this by clearing bits in the various advertisement registers. Given what you've said so far, I'd suggest that this is indeed the case - when smartspeed is triggered, advertisement bits are cleared by the PHY without the kernel's knowledge, leading to the kernel getting the speed resolution incorrect after 5502b218e001. There's another issue here - if smartspeed clears advertisement bits, then if you connect a 4-pair cable after having used a 2-pair cable, you'd still be limited to 100mbit. The ethtool output will be just as confusing. The only thing I can think we should do is to read-back the advertisement from the PHY whenever we read the rest of the status and update the phy->advertising mask, just like we do with the link partner advertisement. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up