From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 75CA5606A880 for ; Fri, 13 Nov 2026 00:33:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=OfXZTSfC; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=HJawXLc6 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:To:From:Reply-To: Cc:Content-Type:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Unsubscribe-Post: List-Owner; bh=Id4cZ/fw9ZnSbEqbTGJ2RwSlS+8eMOnAd+ziuKc7G3M=; b=OfXZTSfC+X3Wyo TX7CTdIzAONYNJZUl8thH7g+nRlD+TNVMeVpkQg8kCPo1CNVSCJMJWsYUowvedAtXOeGVQlhqYse7 Z0LhZa/TOX7OEeTBOE7jKUfL0IeZ9sziUT3/N8aVwLfdFz5MfR590NG2iP66vM3m1SKoVYKKBEBpK GSvW7dIYNJlVC2l5ZUtRd8RBLI3er5CURApJUpemJ0xxS9r+B7FOETrTEeN+RNJjW/Wsm2ZFhrOHE VluHvEdPQgG6Iq//d+LEe0eAAYCbKKz7nyxbcVhgkmcU0/g0RWucLTEqxfHS9c3mf1z+LfUDhMNEN iioKgQOZSLWfMWYKuuKA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xRfE0-0000000BJi9-0AnG; Fri, 13 Nov 2026 00:33:04 +0000 Received: from mail-wr1-x432.google.com ([2a00:1450:4864:20::432]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xRfDs-0000000BJSN-0jir for linux-arm-kernel@lists.infradead.org; Fri, 13 Nov 2026 00:32:58 +0000 Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-48dee593f18so425510f8f.3 for ; Thu, 12 Nov 2026 16:32:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1794529974; x=1795134774; darn=lists.infradead.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:from:to:cc:subject:date:message-id :reply-to:content-type; bh=Id4cZ/fw9ZnSbEqbTGJ2RwSlS+8eMOnAd+ziuKc7G3M=; b=HJawXLc6B0mX07BO/pHIrkHOlRVi7b366L/TIeD4qdH+DYTMeZBDDQSr+ZfsnvoX8X vnr7CiofHwcyLkUX3qGlzF0iHtJFVwhQo7v7+zLs+Ls5rfBki2ow9CnYnd/B+IoScxpM xkmU+etvMHW5glmKA/53diaKDbG9mgDztGsmT1gOGreI1Ho0EpV8g/h12YE675XbCCpV 9XdBE07W2Y4qFr+J8HDekBMCd8WfTF0rA/FE4Qbn7g4jdxGoCFSstsBMIkj2FLShCVUT vui1LAt3z6mw84XZtuYx0YfiUxpWhV5A7uSJaB2nU2b6K/71FXCuV6NARHpfGvyMMdqJ rNRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1794529974; x=1795134774; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to:content-type; bh=Id4cZ/fw9ZnSbEqbTGJ2RwSlS+8eMOnAd+ziuKc7G3M=; b=ArLKMy2f1twtM3WILmNJQHgmxUTb6uqbFMu+YEwVR9gSd8sbBV1+E8WJi8VjR2e7uo IvxmHF+bDCWJmT5cxlBhCSsnPPDm8fgPgL+eInQYBCUOFRrVYr+kL0W0JZ0Andx5rSFX xwXK0W2Y8BlTm4Fx/xffosEpUHuc7if3uPCUOGcQQzCxQX5viKURGzxueyTsRJ839Lpn 2tQT7bpsDM5IEVz+XJRnCve7FjZ6KqEPYgL7JAJS5tB0LyzokaBWHFyk0IfjdKh+GWgx XsAsAipEi8bM48vFtgXkHcHJwysnzJtBTs9SKhKhXI91ocC1kqwPPDPdgnhhp57U7zbp J3pg== X-Forwarded-Encrypted: i=1; AL+hErFHFFWkiK1GJmJrwrzm2zAZRF1g963+afUg2W5u0fjLteDeIfPsyx8K20rSWYFxDXGGWRQ8fm61NEejG/2GNpTr@lists.infradead.org X-Gm-Message-State: APuU4Z/RxUgL/WHDA3tCOghPudSKauNo6Jbxtvh1/9q6qsdYU4vOqYF2 XpkZKBdRCLrtmegC5dNbm05iELBKonX24GlRMApMon5O+K42u7jiy4AE X-Gm-Gg: AYBFou1U+acPQUWl0lwoJ6u4blybjBRyhCom6dhXvc7BUzNqqT4l0sriuoGNjVnel0m 425eAK1X5k8rfeTo1ZMqXmtSQh0w6zr5QgxVrJ1u1G1aIptO1/pjv8XpOzE6OByvvgmYHyFl10l YILoxp8GkAEGKgyUHZxjfDBmdMYP7iUVgibxL/bd3HhQm+aEe90EwcVfyt+yIUW9LX5Avl+bcAq Ve74qiiuIua42lI2zwaJ6iVLb1s8kL1v2uMMlV2JU3Sooi/mZhEPOoZd/2CQPypUx4yE5QtHnys xjBcMQu549rDvpes8ajR3rtK5B9uLmUILYy44YCCLPYOENSpoxO2qNuFotDZgrqonmMvCeH8M7V H+cQFPl8mIMxVa4gpBZBcT7iP7rikzhdHo7HcH++FJsKvcZq/uP1bYiTPwSxttyFCBmtXAc1jnP QgrHyiEBydznxzT4Z2wpSpb9bak4z/ShMSwIQluKzdhCsf9a6kXbkVnvZNwij4HmdZzZ/fc8mHG i8Rf+WTINw04glog7HaEoaqMrdqL3kXfLUJdvdsOPoPy6SyMZKY/oOaIzwgywH1H0Aiw3fPBe6B BT/VAvyXcNZD5LJURPK+LBxHeHUv1+bOxy6V0pbKbBdFg9mKgccREObu7KGLZHbzdzg8kPNbXsP kLuMAOtgmGKTZSpa4Qi7D6vH5MarJtPOUiFUQDqQz1u9AsDjrW6KpmkpWqBLW7T1oHv0mZQP8a4 k= X-Received: by 2002:a05:6000:491c:b0:48b:118e:7454 with SMTP id ffacd0b85a97d-49c70a0f0cbmr2053309f8f.31.1794529974084; Thu, 12 Nov 2026 16:32:54 -0800 (PST) Received: from Ansuel-XPS24.localdomain (host-212-171-11-167.retail.telecomitalia.it. [212.171.11.167]) by smtp.googlemail.com with ESMTPSA id ffacd0b85a97d-49c5f7828a4sm2029768f8f.23.2026.11.12.16.32.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Nov 2026 16:32:53 -0800 (PST) From: Christian Marangi To: Maxime Chevallier , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Simon Horman , Jonathan Corbet , Shuah Khan , Randy Dunlap , Christian Marangi , Lorenzo Bianconi , Heiner Kallweit , Russell King , Philipp Zabel , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt , netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, llvm@lists.linux.dev Subject: [PATCH net-next v19 10/15] net: Document PCS subsystem Date: Fri, 13 Nov 2026 01:32:00 +0100 Message-ID: <20261113003217.197757-11-ansuelsmth@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20261113003217.197757-1-ansuelsmth@gmail.com> References: <20261113003217.197757-1-ansuelsmth@gmail.com> X-Archived-By: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20261112_163256_524516_B8D4F179 X-CRM114-Status: GOOD ( 34.14 ) X-Spam-Score: -2.1 (--) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 Add extensive documentation of the new PCS subsystem and the fwnode implementation with producer/consumer API. Also update the sfp-phylink migration guide. Signed-off-by: Christian Marangi --- Documentation/networking/index.rst | 1 + Documentation/networking/pcs.rst | 234 +++++++++++++++++++++++ Documentation/networking/sfp-phylink.rst | 35 ++-- 3 files changed, 246 insertions(+), 24 deletions(-) create mode 100644 Documentation/networking/pcs.rst diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index 44a422ad3b05..3fce8f6ac089 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -28,6 +28,7 @@ Contents: net_failover page_pool phy + pcs sfp-phylink alias bridge diff --git a/Documentation/networking/pcs.rst b/Documentation/networking/pcs.rst new file mode 100644 index 000000000000..2cae70231948 --- /dev/null +++ b/Documentation/networking/pcs.rst @@ -0,0 +1,234 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============= +PCS Subsystem +============= + +The PCS (Physical Coding Sublayer) subsystem handles the registration and lookup +of PCS devices. These devices contain the upper sublayers of the Ethernet +physical layer, generally handling framing, scrambling, and encoding tasks. PCS +devices may also include PMA (Physical Medium Attachment) components. PCS +devices transfer data between the Link-layer MAC device, and the rest of the +physical layer, typically via a serdes. The output of the serdes may be +connected more-or-less directly to the medium when using fiber-optic or +backplane connections (1000BASE-SX, 1000BASE-KX, etc). It may also communicate +with a separate PHY (such as over SGMII) which handles the connection to the +medium (such as 1000BASE-T). + +Remark on usage of .mac_select_pcs and fw_node PCS +-------------------------------------------------- + +There are generally two ways to look up a PCS device. + +1. MAC OP struct .mac_select_pcs (considered deprecated) +2. Internal PCS handling with ``num_possible_pcs`` and ``fill_available_pcs`` + +Implementation 1 leaves the entire handling of the PCS to the MAC +driver with the selection of the PCS driven by .mac_select_pcs. +Custom implementations are required if the PCS is external to the MAC +and needs to be handled by a separate driver. + +Implementation 2 makes the phylink core code to select the PCS +provided by ``num_possible_pcs`` and ``fill_available_pcs`` either +via internal MAC handling or firmware node (fwnode) + +Implementation 1 is considered deprecated and it's suggested to +switch to implementation 2 and where possible switch to firmware +node design. + +.. _pcs_fwnode: + +Looking up PCS Devices (fwnode implementation) +----------------------------------------------- + +The lookup of a PCS device follows the common producer/consumer implementation +used by similar subsystems with a ``#pcs-cells`` on the producer and a +``pcs-handle`` property on the consumer:: + + pcs: pcs { + // ... + #pcs-cells = <0>; + }; + + ethernet-controller { + // ... + pcs-handle = <&pcs>; + }; + +On :c:func:`phylink_create`, phylink will use the ``num_possible_pcs`` +value and ``fill_available_pcs`` helper function in +:c:struct:`phylink_config` to compose the list of available PCS that can be +used for the phylink instance. + +Phylink will then internally handle the selection of the correct PCS for +the requested interface mode based on the interface modes configured in +``pcs_interfaces`` in :c:struct:`phylink_config` struct and +``supported_interfaces`` in :c:struct:`phylink_pcs` struct. + +A PCS is considered eligible when the requested interface mode is present +in both ``pcs_interfaces`` in :c:struct:`phylink_config` struct and +``supported_interfaces`` in :c:struct:`phylink_pcs` struct. + +``supported_interfaces`` describes all interface modes supported by the MAC, +whereas ``pcs_interfaces`` identifies the subset that require PCS selection. + +For the special implementation where the PCS is internal or part of the MAC +and a dedicated driver is not needed, it's possible to leave the implementation +of the PCS to the MAC driver and just implement the ``num_possible_pcs`` +value and ``fill_available_pcs`` helper function in +:c:struct:`phylink_config` referencing the local :c:struct:`phylink_pcs` +struct allocated from the MAC driver. + +.. _pcs_consumer: + +Using PCS Devices +----------------- + +It's mandatory to either implement the ``mac_select_pcs`` callback +of :c:struct:`phylink_mac_ops` or ``num_possible_pcs`` and ``fill_available_pcs`` +of :c:struct:`phylink_config` to use a PCS for a MAC. + +The fwnode implementation exposes simple helpers to parse the PCS from +the fwnode :c:func:`fwnode_phylink_pcs_count` and +:c:func:`fwnode_phylink_pcs_parse`. The :c:func:`fwnode_phylink_pcs_count` helper +takes the fwnode where the ``pcs-handle`` should be parsed and return the +number of PCS entries described in the fwnode. +The :c:func:`fwnode_phylink_pcs_parse` helper takes three arguments, +the fwnode where the ``pcs-handle`` should be parsed, an allocated array +of :c:struct:`phylink_pcs` pointer where to put the parsed PCS from the fwnode +and the maximum number of PCS to parse. +Contrary to :c:func:`fwnode_phylink_pcs_count`, :c:func:`fwnode_phylink_pcs_parse` +helper fills the allocated array with ONLY the available PCS and return the +number of available PCS found. PCS that returns -ENODEV will be skipped and +won't be inserted in the allocated array. + +A phylink instance may use multiple PCS devices. The maximum number is reported +through ``num_possible_pcs``. + +It's mandatory to specify for what interface a PCS is needed. This can be done +by filling the ``pcs_interfaces`` in :c:struct:`phylink_config` struct. +If the requested interface mode is not present in this bitmask, phylink does +not search for a PCS for that specific mode. (example MAC doesn't need a PCS +for SGMII but require one for USXGMII) + +With the use of the :c:func:`fwnode_phylink_pcs_parse` a common implementation +is the following:: + + static int mac_fill_available_pcs(struct phylink_config *config, + struct phylink_pcs **available_pcs, + unsigned int num_possible_pcs) + { + struct device *dev = config->dev; + + return fwnode_phylink_pcs_parse(dev_fwnode(dev), available_pcs, + num_possible_pcs); + } + + static int mac_setup_phylink(struct net_device *netdev) + { + struct phylink_config *config; + + // ... + + config->dev = &netdev->dev; + + // ... + + // Parse possible PCS and fill num_possible_pcs. + config->num_possible_pcs = fwnode_phylink_pcs_count(dev_fwnode(&netdev->dev)); + config->fill_available_pcs = mac_fill_available_pcs; + + __set_bit(PHY_INTERFACE_MODE_INTERNAL, config->supported_interfaces); + __set_bit(PHY_INTERFACE_MODE_SGMII, config->supported_interfaces); + __set_bit(PHY_INTERFACE_MODE_1000BASEX, config->supported_interfaces); + __set_bit(PHY_INTERFACE_MODE_USXGMII, config->supported_interfaces); + + // PCS required only for USXGMII + __set_bit(PHY_INTERFACE_MODE_USXGMII, config->pcs_interfaces); + + phylink = phylink_create(config, //... + +It's worth to mention that it's phylink code that takes care of allocating +the array of :c:struct:`phylink_pcs` pointer for ``fill_available_pcs`` +callback based on the value set in ``num_possible_pcs`` for +:c:struct:`phylink_config` struct. + +The ``fill_available_pcs`` callback must not write more than +``num_possible_pcs`` entries. The third argument may be used to validate +that there is enough space to fill all the available PCS in the passed array +of :c:struct:`phylink_pcs` pointer. + +The ``fill_available_pcs`` callback is called only on :c:func:`phylink_create` +and is used only to compose the initial available PCS list. Ownership of PCS +is held by phylink. + +.. _pcs_producer: + +Writing PCS Drivers +------------------- + +To write a PCS driver, first implement :c:struct:`phylink_pcs_ops`. Then, +register your PCS in your probe function using :c:func:`fwnode_pcs_add_provider`. +The :c:func:`fwnode_pcs_add_provider` takes three arguments, the fwnode where +the PCS provider should be registered to, a xlate function to return the requested +PCS based on ``#pcs-cells`` and a pointer to reference private data for the xlate +function. + +The PCS will then be registered to a global list of PCS provider that the +PCS fwnode implementation will use to parse it. + +For the simple case where the PCS driver expose a single PCS, +:c:func:`fwnode_pcs_simple_xlate` can be used as the xlate function. + +You must call :c:func:`fwnode_pcs_del_provider` from your remove function +on driver detach. + +A devm variant, :c:func:`devm_fwnode_pcs_add_provider`, is available to +automatically release the PCS provider on driver detach. + +It's worth to mention that xlate function MUST reference already allocated +:c:struct:`phylink_pcs` pointer and MUST NOT dynamically allocate new PCS. +The returned pointer is used to identify the PCS across provider lookup and +removal notifications. + +Late PCS registration handling +------------------------------ + +It's possible that a PCS becomes available after the MAC finished probing. +Contrary to the usual producer/consumer implementation, when a PCS is not +registered and can't be found, the fwnode parser helper returns ``-ENODEV`` +instead of ``-EPROBE_DEFER``. + +This is to prevent race condition with particular devices that register +MAC and PCS with USB or PCIe and require the MAC to be registered before +the PCS. + +The phylink logic correctly handle this special case and keep the phylink +instance in a fail condition. + +The PCS fwnode implementation provides a notifier to which each phylink +instance with a non-empty ``pcs_interfaces`` in :c:type:`phylink_config` +registers. When a new PCS provider is registered, the notifier is called +triggering the :c:func:`pcs_provider_notify` function. + +Function :c:func:`pcs_provider_notify` will check if the just added PCS +should be used by the phylink instance. If it should be used then, +it's added to the internal list of available PCS and a phylink major +config is forced. + +If a phylink instance was in a failure state, with the just added PCS +now part of the available PCS internal phylink list, provided all other +conditions are satisfied, the configuration is retried and the failure +condition is cleared. + +API Reference +------------- + +.. kernel-doc:: include/linux/phylink.h + :identifiers: phylink_pcs + +.. kernel-doc:: include/linux/pcs/pcs.h + :internal: + +.. kernel-doc:: include/linux/pcs/pcs-provider.h + :internal: diff --git a/Documentation/networking/sfp-phylink.rst b/Documentation/networking/sfp-phylink.rst index 5bf285d73e8a..306505118eba 100644 --- a/Documentation/networking/sfp-phylink.rst +++ b/Documentation/networking/sfp-phylink.rst @@ -311,33 +311,20 @@ this documentation. priv->pcs = lynx_pcs_create_mdiodev(bus, 0); - Some PCS can be recovered based on firmware information: + PCS that should be recovered based on firmware information should implement + the external PCS as a :ref:`PCS provider ` and reference it + with the use of PCS fwnode helper :ref:`PCS fwnode helper `. - .. code-block:: c - - priv->pcs = lynx_pcs_create_fwnode(of_fwnode_handle(node)); - -12. Populate the :c:func:`mac_select_pcs` callback and add it to your - :c:type:`struct phylink_mac_ops ` set of ops. This function - must return a pointer to the relevant :c:type:`struct phylink_pcs ` - that will be used for the requested link configuration: - - .. code-block:: c - - static struct phylink_pcs *foo_select_pcs(struct phylink_config *config, - phy_interface_t interface) - { - struct foo_priv *priv = container_of(config, struct foo_priv, - phylink_config); - - if ( /* 'interface' needs a PCS to function */ ) - return priv->pcs; +12. Populate the :c:var:`num_possible_pcs` value and + :c:func:`fill_available_pcs` callback and add it to your + :c:type:`struct phylink_config `. - return NULL; - } + Refer to :ref:`Documentation/networking/pcs.rst ` for + further details and examples. - See :c:func:`mvpp2_select_pcs` for an example of a driver that has multiple - internal PCS. + Notice that the previous implementation of populating + :c:func:`mac_select_pcs` is considered deprecated in favor of the new + described above. 13. Fill-in all the :c:type:`phy_interface_t ` (i.e. all MAC to PHY link modes) that your MAC can output. The following example shows a -- 2.55.0