From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.221.42 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792428303; b=Y6gG0IH765r7rzGAzxUL/gv0XFa6hH4PpNLBWTyK6nC12o6wqNWXyclINz99gzFhsbNH +XshYxnZFL4tR+Vw8aiU+GHfvvzwoH/zCoS4MwlMt1PXCDrnKwJw4OQN/rS8ljWcQm2yk RyMAQIMWbBMI/wIo11np2AiZ13psziDkV7X7PHX31AzWp9+bOgCcB7JE4UH9/Rm9JJfJm 4wA5nLjcViWFSm2q+9c+I7BNfaO/A2dxiFaE0FOpxLFAMAuBUFFn4taOzqc3TfeKaKSd5 izZKO+4lAelDOTikhJYYgXbLVcdEhj/EeamMi/AGLO3PznAMIIaedjIFaIsfRwLyW3A== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792428303; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received:Received: Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; bh=YBxE2RHs/xtw2k6w0uwqJcfXRjL9fFfsXhtkaG1a0dA=; b=TiLYD9u4BL3ym1ESTNH0v4cfAzd7UVPhO9/UXXh3TyLQD/EdEQ8KkUgTTKW9eLt1bvIV 9rQNjSEZhK1jtL3+Z583OAjGpAYUMLuH95i3lkGvHQApvE5erJbJUQMHXwkWG+ay0J6qU KXgxuWW7+DOCBY/OyfM0QYp0jaa6n/2Ti+Gb3nTzH14lDfAf114uP8c9sN6QmdbQh54UC tI5lym2azo9jbR/k6Swgqr6iOLotd5Wn1Rizg9Bt9X5b8nCkzSswjxakxmk2/FGbtqwUh mdsR3UtJUmC+ZgYWjJcePFzYeFZeuREjA0APBlWOJjkR3EAL42rU5+N3sMMzPQ1Kzeg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=riscstar.com; spf=pass smtp.mailfrom=riscstar.com; dkim=pass header.d=riscstar-com.20251104.gappssmtp.com header.i=@riscstar-com.20251104.gappssmtp.com header.a=rsa-sha256 header.s=20251104 header.b=sWUP6p6d; arc=none smtp.remote-ip=209.85.221.42 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5DA07606A322 for ; Mon, 19 Oct 2026 16:44:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 5DA07606A322 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, unprotected) header.d=riscstar-com.20251104.gappssmtp.com header.i=@riscstar-com.20251104.gappssmtp.com header.a=rsa-sha256 header.s=20251104 header.b=sWUP6p6d Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-48dfaa3fa12so2208598f8f.0 for ; Mon, 19 Oct 2026 09:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=riscstar-com.20251104.gappssmtp.com; s=20251104; t=1792428297; x=1793033097; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=YBxE2RHs/xtw2k6w0uwqJcfXRjL9fFfsXhtkaG1a0dA=; b=sWUP6p6dS77gDd9crmmTzReRjbttlB+oGdebU8insTZ0eh8VuwE85bYmR7cVuMfITN 04ViV/M5Cli7xTKW1+fo4opBWS1lhlnfqVoEyTDIHAffyAjIGxPmIzYALh+/M2+i5hhm dIou0xRjPwAY22CinG4x17pvDzKX4avuJU251GO8e4LulYdFpt4p+fzVlvyU9jj9CFUQ rE0MiumtTqofDWMfk/iSipZfzKD7t+QsbDwy9bEKQZiGTiDe85n+QhXb02GSLwnZEvRt l0W+tZzsycG6O3Rcc/9ZktykZeaw1RAAobhTLe/k8KMsoLXZvGEh5kbD5nWv4ECn/q4O sEeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792428297; x=1793033097; h=in-reply-to:content-disposition:content-type: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 :content-type; bh=YBxE2RHs/xtw2k6w0uwqJcfXRjL9fFfsXhtkaG1a0dA=; b=cXsTCFWkYu8nL1IJ8bMI0XfczfNC/GqDUNAY/Gq3xMi/e0raLGXZx5wnO11hWoJGsU pb5qVSQgzq0oqvZ5OdLBhzwWeisLPg59Hcu8RwUTNJQW88Y8ykb1ff69fBIbQaP5QY9U UvmzUBOngAcc6xWlvWFn2Rvh9ZsHoAnJz2HMu9JJDCabDPkUmz0ZgGHooye4X/+u9oh5 g05Tvn7qEUYMEAhZFr1IRlc73an10QkTLafDPqbpI3YtVIkL71Hv8PbuI0vUDh2Ol4Rb vLMZC9aYpIflPiN29YP12KdxlLtD1NtwY4eMPMFB25KGlbCo1qD0kRpaDaFTl93YCYs3 WEkQ== X-Forwarded-Encrypted: i=1; AKwUvBwyIsM7b8C79dFYGJPNz/pgLGx3QLKxoejV90P43sjIpIxAlXnwvKLtkxquwcWJf6SINccGCSHZi/XNwTQ=@vger.kernel.org X-Gm-Message-State: AFq9FYKCXsunA5C/9gILVBBWTfMi0FrCFzUh2dk3oPDstdoP8Hqukf38 jGBj4bdPKm8IU8HoG/NqkB582z+pHwJnwQ3T9CGbFywhNbok+wuiAsC0QwNIXa6VgBI= X-Gm-Gg: AYBFou3uVT/w06D/r3I6m+r3MQDASyTeNOJ3jlGN9iTzM1DwOm62kasiFnzYLephiut oW2cTy47Vp9OzQZsmaw3lK/aKEE1w6qew/jEnmgXvWmPfsya/lWvHXAivi8DaEfAl6wwGfjHjBF F37p2bPCVSwqBOt80h6JCdlQqwaSoGjbU/wGXr44SGso8WrVYQFq51F/zkQYVz7Ws6XNN4WcM6I 7JdKXF0aldzSjajHIjKHXdvNG4yjpHFgP2mKgR1v4RdElsiR7yeUc2KT0LHEqFKBMTPoYpqY0iX d3TacDe0+TDLN6d3RbYQyt79N86HbF3V2dkRto/x5d5SdLul73acM/Z49dtk4zA3ol8AlJ6sGGv gGg48+XitmE/EhCFcz7p3i5uK1ra5UQBYUp/tTEL3hpSPDs3BVEpeFDkO8yLVrXcJN+jW4kt2Lv MH6kdFIB2dfuWoJvHmu2dxzDphdvf7un5r5oQsONbN91fkreq6OYRWjnukFl5YlQjGJEqxGI9uc eheOgHOjNT74+N2HzJLHniNt8cggFLfxKxwvOkM8jT8TffjKjaCm6EhkEVPrNadaPrEBtO8WP3L +Vxnm1KRy15fprNLc19lOhuJ0TbcodbCJeFH1/ye7fbKnYc4sm/c6ViCUyU= X-Received: by 2002:a05:600c:5254:b0:4a1:e57b:667e with SMTP id 5b1f17b1804b1-4a1e57b68c7mr97174505e9.4.1792428296450; Mon, 19 Oct 2026 09:44:56 -0700 (PDT) Received: from aspen.lan (aztw-33-b2-v4wan-169864-cust3247.vm26.cable.virginm.net. [92.239.204.176]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a1f2d324f8sm3668735e9.6.2026.10.19.09.44.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2026 09:44:55 -0700 (PDT) Date: Mon, 19 Oct 2026 17:44:53 +0100 From: Daniel Thompson To: Andrew Lunn Cc: Alexander Duyck , Alex Elder , hkallweit1@gmail.com, linux@armlinux.org.uk, davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next 2/2] net: pcs: xpcs: select operating mode for 10G-baseR capable PCS Message-ID: References: <20261014223100.304486-1-elder@riscstar.com> <20261014223100.304486-3-elder@riscstar.com> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sun, Oct 18, 2026 at 05:48:39PM +0200, Andrew Lunn wrote: > > > > + if (mdio_stat2 & MDIO_PCS_STAT2_10GBR) { > > > > + switch (interface) { > > > > + case PHY_INTERFACE_MODE_SGMII: > > > > + case PHY_INTERFACE_MODE_1000BASEX: > > > > + case PHY_INTERFACE_MODE_2500BASEX: > > > > + /* > > > > + * Why are we writing MDIO_PCS_CTRL2_TYPE + 1? We want > > > > + * the modal behaviour that comes when we pick a > > > > + * reserved value. XPCS allocates extra bits to this > > > > + * field and allocates values from 15 down so > > > > + * MDIO_PCS_CTRL2_TYPE + 1 is the value likely to be > > > > + * allocated last (and hopefully never). > > > > + */ > > > > + ret = xpcs_write(xpcs, MDIO_MMD_PCS, MDIO_CTRL2, > > > > + MDIO_PCS_CTRL2_TYPE + 1); > > > > + break; > > > > + default: > > > > + ret = xpcs_write(xpcs, MDIO_MMD_PCS, MDIO_CTRL2, > > > > + MDIO_PCS_CTRL2_10GBR); > > > > + break; > > > > + } > > > > > > MDIO_PCS_CTRL2_TYPE is 3. Looking at 802.3, the value 4 is > > > 40GBASE-R. The 2022 version of the standard has values defined up to > > > 10011b, for speeds up to 400G, > > > > > > Alex added support for 25G, 50G, 100G. > > > > > > Is this an issue? > > > > It will probably be an issue when the kernel is first called up on to > > support an XPCS that supports 40GBASE-R. > > Which is likely to happen sometime in the future. Maybe Alex's > hardware even supports it, but if you can do 50G, why bother with 40G? > > > > The XPCS (at least in TC956x) handles MDIO_PCS_CTRL2 in a slightly odd way. > > It 4 bits wide and accepts 10GBASE-R, 10GBASE-X, 5GBASE-R and 2.5GBASE-X > > is defined in the standards up to 2018. All other bit patterns are > > reserved and instruct the XPCS to use Speed selection bit (13) of PCS > > control 1 to choose between 10GBASE-X or 1000BASE-X. > > We probably need Alex in this thread, what happens for 25G, 50G, 100G? That would be very much appreciated (hi Alex)! I have spent a fairly big chunk of today trying to "get back inside my own head" since it's been quite a while since I last looked at this code; Alex (Elder) and I were focusing on other bits. I made two assumptions when I was reasoning about regressions: 1. No existing code ever wrote to PCS Control 2 and therefore the value after reset must be correct for existing working cases. 2. The reset value is bit pattern 0 (10GBASE-R). The idea of the code above is designed to match only those cases where we *know* that the reset bit pattern (0) will cause trouble and change things. It's currently a very narrow match although I might expect additional cases to be added as other phy interface modes are tested. I have spotted a very obvious flaw in my reasoning above: the special case logic for FBNIC that suppresses the initial XPCS reset. Unfortunately the version history doesn't mention what bad thing we can avoid by suppressing the reset (perhaps a reset can clobber values such as PCS_TYPE_SEL that are injected by the firmware). > Maybe there are different revisions of the IP, and later revisions > make this register follow the standard? I'm not able to answer that. All I can say is most XPCS seem to have the same ID. Finger crossed that, if they change the behaviour they also change the ID! > > That means we *must* write a reserved value to this register because the > > default value after a reset prevents <=1G modes from working (I think > > automatic switch over between 1G and 2.5G also liked this to a reserved > > value but I don't fully recall right now). > > > > On that basis the best bit pattern to use one that isn't implemented by > > whatever XPCS we happen to be running on. One simple approach might be > > keep using 40GBASE-R but to check PCS Status 2 to ensure we fail in a > > non-silent manner on hypothesized future XPCS hardware: > > > > if (mdio_stat2 & MDIO_PCS_STAT2_10GBR) { > > if (mdio_stat2 & MDIO_PCS_STAT2_40GBR) { > > dev_err(dev, "40GBASE-R is *not* a reserved " > > value on this XPCS"); > > return -ENOTSUP; > > } > > Maybe. But we need to ensure it does not cause regressions for fbnic, > which might actually support this speed. I will sketch out an idea based on explicitly checking both my assumptions hold by checking PCS Status 2 and PCS Control 2 after a soft reset. Thus if you never reset then the code will never deploy. Likewise we don't need to rely on my guess that all XPCS implementations will reset PCS_TYPE_SEL to 0. I will also, given everything I've had to share by e-mail, improve the commenting a lot! Daniel.