Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1730653pxu; Tue, 24 Nov 2020 07:36:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJxPPIK9nkeqXmNqzJGHrv+RTcxw5vMmlf2ttprXAWNmL/D65OXA1Aqp2Dq5v+Qlwlaoppmh X-Received: by 2002:a17:906:4a02:: with SMTP id w2mr4595376eju.267.1606232218123; Tue, 24 Nov 2020 07:36:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606232218; cv=none; d=google.com; s=arc-20160816; b=JXQwbFa3d2Wz0AdDI74N8flHXrTBLlCvVX88sdfZ9UEskgSpBXm3/GniP9PTVBnp12 ljFBNJHWwACO5l5hHlxaqvOo8Rg9ZmPF4+CvSRxmFbuJvRfGnYb1qBKdtNU9Kb7VCZI1 6vq/qOej6zjK0diu0OkwVDQIjsuJxr84hMZZdIhf194gHt7RYYU7X2hhuL68nTSix8E8 y6wXPPVrrKvyV9TM95fMjyqzi2mXwX0P8PtWfrvM4yugZXox7FsX0wQ8Dq/IOmZBEnrJ pU4z6vA3s2mkjq7+9pkNajKg03CQdnUDAR7iKpUox9FgcAVLR9w2g9vWa4+hQ9BPd9Zx fWgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=Ypt08g8yC5E1a0xePLAiZgQfojweHehBCCzNvuLtWM8=; b=ak1YV39FRZkgwm4wiK+lJL/ISa2VhJ0IXZ2SX/d3SgV1tA7O8LsO+cw7BWXyDw/5cb +M2LW3bmBaCtviHRHgytT+R+IgU7dEjbjLhMRDFO4uNIWY0ePZLHzUekCm7dL9/q8mKA 1wxax/40ssGJjENtqjKTnmGEbz9XIdjeJxo769EbdbWpkKsSDa75E/fHXELikut52Ayf xX/I5DB2OWY/Yn/6UHZ+DxiixudV8rClMkDO1cqkZk9Rpzt38yBsBWe7W/QR45px0TJv qJOY5sC9FY94uep+wN4gKa3OZxhkn48lamKXWJk/D9RAfqRY0Zvi8wMhyHvtQcYgyjHx /Q5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@st.com header.s=STMicroelectronics header.b=ct7IcYWF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=st.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y4si8820771ejj.723.2020.11.24.07.36.33; Tue, 24 Nov 2020 07:36:58 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@st.com header.s=STMicroelectronics header.b=ct7IcYWF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=st.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389757AbgKXPcw (ORCPT + 99 others); Tue, 24 Nov 2020 10:32:52 -0500 Received: from mx07-00178001.pphosted.com ([185.132.182.106]:58121 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389078AbgKXPcv (ORCPT ); Tue, 24 Nov 2020 10:32:51 -0500 Received: from pps.filterd (m0046668.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0AOFWFUL031036; Tue, 24 Nov 2020 16:32:33 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=st.com; h=message-id : subject : from : to : cc : date : in-reply-to : references : content-type : mime-version : content-transfer-encoding; s=STMicroelectronics; bh=Ypt08g8yC5E1a0xePLAiZgQfojweHehBCCzNvuLtWM8=; b=ct7IcYWFG9R1S++YtI/eB2Q8vNwL6mXtwZlS2wUZq07usEjhSZD7BLNSBiVxQgI0YE6H 50lJkKkHklPp1rD9O+aZhvbEGPFdmniLjpQjP4Wns0NEuLQEUlLdm7z7cUWH8Fg/t5oR /Wf+o7sMQr29/Ks6YbiDniNXGqF/tWNDE3u9i72WtV4mVxe6DXg50Y4OcKG7DMkLXl6u cHalXrkDGDXFofZnexU1DdnXaJ+A6K7Namw3ZmD3tbzRNbmXo4srOuXSqDWpWAMwoZPK xRA8Uys5hcX8RKXplwdNcgGh0HO9ZvL+Gfj39jTMBSkm8L37ycix4du1ZtEdtuAdqnWi mw== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 34y05h898p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Nov 2020 16:32:33 +0100 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 7000F10002A; Tue, 24 Nov 2020 16:32:32 +0100 (CET) Received: from Webmail-eu.st.com (sfhdag1node3.st.com [10.75.127.3]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 562A52568E0; Tue, 24 Nov 2020 16:32:32 +0100 (CET) Received: from [10.129.7.42] (10.75.127.50) by SFHDAG1NODE3.st.com (10.75.127.3) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Nov 2020 16:32:30 +0100 Message-ID: Subject: Re: [PATCH] net: phy: fix auto-negotiation in case of 'down-shift' From: Antonio Borneo To: Russell King - ARM Linux admin , Heiner Kallweit CC: Andrew Lunn , "David S. Miller" , Jakub Kicinski , , Yonglong Liu , , , Salil Mehta , , Date: Tue, 24 Nov 2020 16:31:40 +0100 In-Reply-To: <20201124151716.GG1551@shell.armlinux.org.uk> References: <20201124143848.874894-1-antonio.borneo@st.com> <4684304a-37f5-e0cd-91cf-3f86318979c3@gmail.com> <20201124151716.GG1551@shell.armlinux.org.uk> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.75.127.50] X-ClientProxiedBy: SFHDAG1NODE2.st.com (10.75.127.2) To SFHDAG1NODE3.st.com (10.75.127.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312,18.0.737 definitions=2020-11-24_04:2020-11-24,2020-11-24 signatures=0 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2020-11-24 at 15:17 +0000, Russell King - ARM Linux admin wrote: > On Tue, Nov 24, 2020 at 04:03:40PM +0100, Heiner Kallweit wrote: > > Am 24.11.2020 um 15:38 schrieb Antonio Borneo: > > > If the auto-negotiation fails to establish a gigabit link, the phy > > > can try to 'down-shift': it resets the bits in MII_CTRL1000 to > > > stop advertising 1Gbps and retries the negotiation at 100Mbps. > > > > > I see that Russell answered already. My 2cts: > > > > Are you sure all PHY's supporting downshift adjust the > > advertisement bits? IIRC an Aquantia PHY I dealt with does not. > > And if a PHY does so I'd consider this problematic: > > Let's say you have a broken cable and the PHY downshifts to > > 100Mbps. If you change the cable then the PHY would still negotiate > > 100Mbps only. > > From what I've seen, that is not how downshift works, at least on > the PHYs I've seen. > > When the PHY downshifts, it modifies the advertisement registers, > but it also remembers the original value. When the cable is > unplugged, it restores the setting to what was previously set. In fact, at least rtl8211f is able to recover the original settings and returns to 1Gbps once a decent cable gets plugged-in. > > It is _far_ from nice, but the fact is that your patch that Antonio > identified has broken previously working support, something that I > brought up when I patched one of the PHY drivers that was broken by > this very same problem by your patch. The idea to fix it for a general case was indeed triggered by the fact that before commit 5502b218e001 this was the norm. I considered it as a regression. > > That said, _if_ the PHY has a way to read the resolved state rather > than reading the advertisement registers, that is what should be > used (as I said previously) rather than trying to decode the > advertisement registers ourselves. That is normally more reliable > for speed and duplex. > Wrt rtl8211f I don't have info other then the public datasheet, and there I didn't found any way other than reading the advertisement register. I have read the latest comment from Heiner. I will check aqr107! Thanks Antonio