From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) (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 2DE0C3D34A0 for ; Fri, 8 May 2026 11:31:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778239888; cv=none; b=jxS6+E4lZb2ASBSmKBsISPVXRJSOqBlEQfQpvPfV02qJHP/NubKJd0DR8O7LTZ/wJFdq+JkFopBOL/FU+Dakxti6Ewrnfzzx4PigUoXyugXs4s3h+/JUM2zsPmKEM5/RYZHvqRiRRebKL+Co/AuCIKy09acppdjro+p+10YqKxQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778239888; c=relaxed/simple; bh=0hrQlW5FpcXozs6wxkIBzDktzohYeRr936w21ThvyGI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kiELiaBjIR/YRN8MuCOb0zekk+bJ56Imm1mDO9Gjl/eXrLs0Fger8kc4lwvtabw+un1v/G6dyrYXzTE2m3J4oSkQSu6pxCy5+YS2zhhTrOZfXWJQfizlRPJbS9nRdQXX8EtLmQhkI66i4djAI62D8NnVAPwLMu2GfPGRydVcyUU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=riscstar.com; spf=pass smtp.mailfrom=riscstar.com; dkim=pass (2048-bit key) header.d=riscstar-com.20251104.gappssmtp.com header.i=@riscstar-com.20251104.gappssmtp.com header.b=zaGqOHpn; arc=none smtp.client-ip=209.85.167.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=riscstar.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=riscstar.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=riscstar-com.20251104.gappssmtp.com header.i=@riscstar-com.20251104.gappssmtp.com header.b="zaGqOHpn" Received: by mail-lf1-f51.google.com with SMTP id 2adb3069b0e04-5a87782588cso2432583e87.3 for ; Fri, 08 May 2026 04:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=riscstar-com.20251104.gappssmtp.com; s=20251104; t=1778239885; x=1778844685; darn=vger.kernel.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=i3oCf6JjY2k4f2DdZmgb+d8lKs1DeUt4qK3/lGPB5dQ=; b=zaGqOHpnsUCV+vA6TVCtOV8VWmaUyfmOkHHzLGkEADuNsj0J4GjK9oK4xW/3CNcMv1 kr2whR9te0rnCtZzCtVGzKfUAwZD6kHX9gGeHzEsQcbNGuRb4fmjNxOlVuMYvwmAWdsW bvU3Td71ri1EF7xTc7xlkE/UfzI1UbRtOQiSxPjohk5NqmvUGfWywNqBa3IXqUOCOmUf 3NdGZQzac7id9nnvXWk6uxZsnLiMk/CXcqDwT8e/eZUD1PK07a3sz4+cyR/2bkcPk3NA 37zzl8/r5xA1jqnaU8Tn8o4ptwTUmO55EBkqwi8X9fG++kTorbv8j18lsB4Dre85coVs Oh+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778239885; x=1778844685; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=i3oCf6JjY2k4f2DdZmgb+d8lKs1DeUt4qK3/lGPB5dQ=; b=BDFRiGlVpJUFfbYAP0Oe/bodqsLO9o4+Q5P1HfMMdnbmeWSuS7M/XLu/ghgp9oJqop 0P6VC6r9umUiFEFIvRVtbjPLv6njH1CFMk37feiZZWt8r7aV4fAGRbWNnAvOvJ4leTEJ T+EKTMZp5b5O8AY9OU8hWdIHRpgxfxw9T1pVEFkSJtxua3yRywTvLgdVOEI/ZhPr2EJ2 y2AU58T7yBBQV6/vXDdVB96VFbImZgnXLyDcVpVIsdV6RlXN2cFsw9/QuFzu1yXiSwv0 pakrcCkAkq1Vgg7Igrb22bZlZDZbE4QM+oVBravAs4id/RU7gkigmLMv6M84XK3U6uh5 qPyQ== X-Forwarded-Encrypted: i=1; AFNElJ8n7BTRd0k+ONblF0KoSpE+MTEYtEEFS/yWmb+dWzqyO5jrC9vKT4HSGjt8aBa4QA2hKDjPOHQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yw6K64yDXi1Ge2cuMkmkabXndpK40naxTIRsWv+7GjHNDmGw80S TkU3tNVbezrjj9drtdiV5lVyqqUxy7fsgJyIo1aKJsC5nnn559tkbnndIEa0krvKHjuwdZ5rtf+ lkc26wwc= X-Gm-Gg: Acq92OFdQweU0RQi3fAWwyWDxYmc2Nmq8SJLylDCo9rvtZmCw8rJf2wqHU1z2L6FU3o 7D0mVqzwIGgLocv4ItUMZub+4Tnb3zKyo/pUyXy2qTohp/HM3m1hypYfcSB22ZgXzi8OjFO7av2 /+V6uc9D/kokuHvVbBmszdRnzcK+2x0g0QPk3mnVZlY+B3KtLP7jzDGp561Swew5/Uuv60yBEvJ VIcge8GxOObZkD70K7Ire2KVAdeolOUzzDfbs3z9PItKco5Brc8FmWsA0/sOw+fapz03Sv/XrHV YAQ22wNqQVkpGJDRXpLKG+sxG/Cqcq+dOESsH2O+wRCVWM/NS1H4d2lMAp034EXRccMRYZYwNWE j7WmiUh6mNyhRhyQjD0hQGV3oIFNRP2mHkdrkmouQiF/CxKPgYoxdQ2V5Mr0WP9M3eIfT9ncMQP hFWLEcCjnJtxZ+O0a5n686svT0wEDZs0rw4xTtH682uU5HrlGETVg4JsOzwmzz7O9mKY3agYHVC +vE3BPYfYstapckmT+kYgQtDcvyU4krlmloSRhr7tiZc0dzJfgjjqWLReEM/kQhdw+l7z5GDVmD q3jAhVEf X-Received: by 2002:a05:6000:26c9:b0:43b:3b80:6776 with SMTP id ffacd0b85a97d-4515d3dc30emr18803689f8f.30.1778239532551; Fri, 08 May 2026 04:25:32 -0700 (PDT) Received: from aspen.lan (aztw-34-b2-v4wan-166919-cust780.vm26.cable.virginm.net. [82.37.195.13]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-454917d57aesm3814079f8f.26.2026.05.08.04.25.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 May 2026 04:25:31 -0700 (PDT) Date: Fri, 8 May 2026 12:25:28 +0100 From: Daniel Thompson To: Andrew Lunn Cc: Alex Elder , andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, maxime.chevallier@bootlin.com, rmk+kernel@armlinux.org.uk, andersson@kernel.org, konradybcio@kernel.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, linusw@kernel.org, brgl@kernel.org, arnd@arndb.de, gregkh@linuxfoundation.org, mohd.anwar@oss.qualcomm.com, a0987203069@gmail.com, alexandre.torgue@foss.st.com, ast@kernel.org, boon.khai.ng@altera.com, chenchuangyu@xiaomi.com, chenhuacai@kernel.org, daniel@iogearbox.net, hawk@kernel.org, hkallweit1@gmail.com, inochiama@gmail.com, john.fastabend@gmail.com, julianbraha@gmail.com, livelycarpet87@gmail.com, matthew.gerlach@altera.com, mcoquelin.stm32@gmail.com, me@ziyao.cc, prabhakar.mahadev-lad.rj@bp.renesas.com, richardcochran@gmail.com, rohan.g.thomas@altera.com, sdf@fomichev.me, siyanteng@cqsoftware.com.cn, weishangjuan@eswincomputing.com, wens@kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-gpio@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next 10/12] net: stmmac: tc956x: add TC956x/QPS615 support Message-ID: References: <20260501155421.3329862-1-elder@riscstar.com> <20260501155421.3329862-11-elder@riscstar.com> <2ce5897d-5bbb-486a-b0f0-0e30e54b451a@lunn.ch> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, May 07, 2026 at 06:29:15PM +0200, Andrew Lunn wrote: > On Thu, May 07, 2026 at 05:03:46PM +0100, Daniel Thompson wrote: > > On Fri, May 01, 2026 at 09:04:58PM +0200, Andrew Lunn wrote: > > > > +static struct tc956x_mac_speed mac_speed[] = { > > > > + { PHY_INTERFACE_MODE_2500BASEX, SPEED_2500, SP_SEL_SGMII_2500M, }, > > > > + { PHY_INTERFACE_MODE_SGMII, SPEED_2500, SP_SEL_SGMII_2500M, }, > > > > + { PHY_INTERFACE_MODE_SGMII, SPEED_1000, SP_SEL_SGMII_1000M, }, > > > > > > That looks odd. Some vendors implemented 2500BaseX using SGMII > > > overclocked. But that is not strictly 2500BaseX. Having the 2500BASEX > > > entry suggests you have real 2500BASEX, so why have an SGMII entry > > > with SPEED_2500? > > > > This is a consequence of the code that uses this lookup table being > > called both during initialization and from the fix_mac_speed() callback. > > > > During initialization we only have the value in plat->phy_interface to > > go on so we run the lookup table using plat->phy_interface (which is > > typically PHY_INTERFACE_MODE_SGMII) and with the maximum permitted > > speed. > > Something sounds wrong here. SGMII only supports 10/100/1G. You should > never be asked to do SGMII at 2500. It should ask for 2500BaseX. We weren't being asked. It was just an internal driver trick to common up some code paths. However I did a few tests and the internal driver trick doesn't actually do much we can't achieve a different way. With that changed I can (and will) remove the PHY_INTERFACE_MODE_SGMII/SPEED_2500 entry from the table. > > I haven't got detailed enough notes to allow me to double check but I > > think there were problems completing the initial MAC reset if we didn't > > write something sensible to the hardware during initialization. > > > During fix_max_speed() we get told to adopt 2500base-x. Reviewing the > > code I can see we don't propagate that and just use > > plat->phy_interface for fix_mac_speed(). I will fix the code to that > > the requested interface propagates properly to the lookup table but I > > think we would still rely on the SGMII entry to get sane initial values > > to write to the hardware. > > Getting sane values into the hardware is good, but 2500 SGMII is not > sane :-( BTW if you are bothered by SP_SEL_SGMII_2500M, that name comes directly from the TRM and I'd prefer to keep it if I can. The enumerated value we have to write into the SP_SEL for 2500base-X is "SGMII 2500M". Daniel.