From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 681323EAC96 for ; Wed, 6 May 2026 09:40:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778060459; cv=none; b=Hm09SVR5tLG+50snewU1gHsEevSKMHKnBAaYASkwQxgKsez5BUbIMH3WyKJgW56ZwmUUdJhI6gQM0S5ZO7hdPAayWOqWIkftexdI2+DWNYU7T07yNcFhDFySU7uoV2B34j6bl9OU27I/ItmAUKCVIk+6e4o7YXIIrdRMp+lkls4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778060459; c=relaxed/simple; bh=/ukJ5vDdOSsgLet+xcKmTpHYrOQRlHD4PS747OsECPI=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=DxMITVdIajRdXPchBe6DdP83XpNTFTVACcF9mvPrPD1f3lc7YJIikwH+EMRJ/g+OUF+qagoVS1fCH5m3T00jh6njAmfvqmxwZ1kMeJuSRcQzAmiOac6QLckC0ddi+Pe+fxW9JEx8kgMBKXrRQ2PHP1um3a3+CxXpOaETcIxRVkA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=CDLfj1NS; arc=none smtp.client-ip=209.85.128.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="CDLfj1NS" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4891e86fabeso74607935e9.1 for ; Wed, 06 May 2026 02:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778060456; x=1778665256; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=3sQT2FfXZ9a1rTbGvEQSWacP8U0CUvSTZQ/TjI8giX0=; b=CDLfj1NST9JYZRVTIIvS83t/mHd7lUZYEcHGc51dN19d7HrrIT51+cbNOuLWRsMaJA IDl/EHIiAghbCprguQJtpTj5hDys+kFNY5ABo9VVjVKeEIZAy1BV9Mnp5gGXmvoc3S1P 11dflymXj8QotqzOHqvksCUPiTKr2Lli5lC56D21pkY0IL2/3RORyZ0sExYXt9y+rA0j X+wlFKja6Oe5GwmJ8AVeITpe7u7nOzcIBVCFl5mEfsa6PvaE7jwWdMr8dhzLmoZQedrM Hvtf8+sHO4glpI9UQsA953yd7IrzOgWK8AuNB1bXMjdXAJcRgWoyG5l1LoYAmWnXIZK8 oa2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778060456; x=1778665256; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=3sQT2FfXZ9a1rTbGvEQSWacP8U0CUvSTZQ/TjI8giX0=; b=U2lZr5SKrpJ7ZqG2+bUgTO7+sfuuHiwjUuUl4VDEuqeC2KOd/hs+VaLt57JNvY1rJ5 1IHQyQ6R8jT4yscuqPpIM1AqP1SjZUrz6QwLxLuWVCE1o2JcSWIIBwJfoW8/1TFhICdn M/xpcegQcjUgYPP0MwP0NtDxLE2gCJ6urQCRJTnf+RyYnzUAljnHN7Ei+leGZ5IkSKDS OVPniBabgOmpZvzesebtiGEmQF47TNDBygi0vUfvvFntWtQFiRrHhzRW6M6NiwkS67ow EHxtyuVWj+qYHEg4PNH70TW7WhI/oFhIFmK4MG5Spr/Pa4mfftaVn5Fr3R58CL6ZYoqV Xprw== X-Forwarded-Encrypted: i=1; AFNElJ+sHCG+8HgF0R63E3Y/vnX8jnAr2mFzxjmrwKOCne+mQbwHKEjknKGxNzY3x91PBZ2wOQUysGIqxN0TGL8=@vger.kernel.org X-Gm-Message-State: AOJu0YyBh6coF3lWGhfn+rkyN6Vx5ffVlNzPZZ/thEbkowD5jrTzu3DZ HGwT3CUsVAhAriGBI+VIUn6rSYguOdunU6cnDLKWxZV63OvAUFf1ZEcE X-Gm-Gg: AeBDiesOyc7+56eGpYT5Ktuc+ImE108bLSzvv7xd5+X4N8+GKDQX1Fvd23xCRcjgW93 LDUjG08OUAYt5u/iJoOJV0CePmk9yngR5cYmftpJakSHQ9l7SEYytakQvHgUET3jw7/RQ+i1Lfi MSv1/Eaf55bLfTUv8zMUvGHDRTRhaNLsg9poXb6wyykKHwP6S64m5Lch1HIvIr6IxxmjeHvbLP1 97hTzRCZ6bP1AYOoDZHw+BJM1hMQSAaaLkzujSbxi7WBAJD/OcybQeXUgLblKuB7BT3aqTxysn8 C2Ve5cMrpn6qax/XReMC9YMAlF0dqx34/9csnai+rAHtD/Iywcz2UMwePppb7J5tfX+l1eCUfGt GoiNA1cFWIzIAEHmRpHPQxRqtU7E2yhD/i/sXQKAim3biiDunyhSgyznj2GqTjWV0GhGHo5mll1 82Uw2no5u58FobTw6a42LcZT59PnSRVRuCLQD/nGsBa9UAfvxntC5LgCt+Lj3R+28WqZVNu4Jb0 83CNY7QrX9DxQ== X-Received: by 2002:a05:600c:a305:b0:48a:5970:2005 with SMTP id 5b1f17b1804b1-48e51e08362mr30882515e9.2.1778060455466; Wed, 06 May 2026 02:40:55 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48e530b2947sm12667845e9.4.2026.05.06.02.40.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 May 2026 02:40:55 -0700 (PDT) Date: Wed, 6 May 2026 10:40:53 +0100 From: David Laight To: "Abdul Rahim, Faizal" Cc: KhaiWenTan , anthony.l.nguyen@intel.com, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, faizal.abdul.rahim@intel.com, hong.aun.looi@intel.com, khai.wen.tan@intel.com Subject: Re: [PATCH iwl-next v4 0/3] igc: add support for forcing link speed without autonegotiation Message-ID: <20260506104053.7a4f5bf5@pumpkin> In-Reply-To: <63b186e0-046d-496e-8ae4-d68cd5eb5817@linux.intel.com> References: <20260428060009.311393-1-khai.wen.tan@linux.intel.com> <20260430154105.505739ac@pumpkin> <63b186e0-046d-496e-8ae4-d68cd5eb5817@linux.intel.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 6 May 2026 14:21:59 +0800 "Abdul Rahim, Faizal" wrote: > On 30/4/2026 10:41 pm, David Laight wrote: > > On Tue, 28 Apr 2026 14:00:06 +0800 > > KhaiWenTan wrote: > > > >> From: Faizal Rahim > >> > >> This series adds support for forcing 10/100 Mb/s link speed via ethtool > >> when autonegotiation is disabled on the igc driver. > > > > I'll ask 'why' ? > > > > In particular forcing half/full duplex has always been a very good way > > of 'breaking' a network connection. > > > > It really is much better to restrict the advertised link modes and let > > the autodetect/autonegotiation logic in the phy/mac do its job. > > > > About the only think I can think of is to force 10M HDX when connected > > to a remote system that supports 10M/100M HDX. > > In that case you need to send out single link test pulses, not the > > burst used to identify 100M HDX, or the pattern encoded on the burst > > used by autonegotiation. > > But you need to got back to the mid 1990s to find such systems. > > Anything that supports FDX will do autonegotiation. > > > > David > > > > There's a use case requested: > > Profinet Certification tool reports that forcing a link speed without > auto-negotiation is not working. > Forcing the link speed is a critical feature for the industrial automation > "fast-start" use case. When there is a connection lost, the system must > come back up as fast as possible. In PROFINET, that means to force the > speed and rejoin the controller loops. Without supporting forcing the speed > to 100M in Foxville, the certification tool would not be able to certify > the availability of this feature. > > I'm hoping this context is enough to justify the need? Is auto-negotiation of the 'low' speed actually that slow? IIRC detecting 10G and above requires a lot of signal processing. But 10/100 and hdx/fdx just uses the ANAR register value sent in the link test pulses. (IIRC 1G uses the ANAR pattern, but requires extra signal processing as well. The higher speeds didn't exist when I was writing ethernet drivers.) I've been on the 'wrong end' of hdx/fdx mismatches - you really don't want to let people get there, it is terribly confusing. There actually ought to be a way of setting the auto-negotiation registers to 100M (HDX and/or FDX) and then transmitting as (say) 100M HDX even before negotiation completes. Then correcting hdx/fdx based on the received ANAR register. Or, at least, sending out an ANAR that only contains what you are using. The problem I always had was that the actual operating mode of the phy wasn't in one of the standard registers. So if you connected to a system that didn't do auto-negotiation the phy would be using (say) 10M HDX, but the received ANAR register would still contain a value from an earlier connection. If the driver read that register from the phy it used the wrong duplex mode. (The speed for 10/100 doesn't matter, the phy clocks the interface to the mac at the right speed and the mac doesn't care.) David