[RFC,net-next,2/8] phy: introduce the PHY_MODE_ETHERNET_PHY mode for phy_set_mode_ext()
Message ID | 20230817150644.3605105-3-vladimir.oltean@nxp.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b82d:0:b0:3f2:4152:657d with SMTP id z13csp2195480vqi; Sat, 19 Aug 2023 14:05:28 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFbDoIvZMBpooDWnQ6QLRXBbSVrxOVhlZOTjYdxZeGlHSEkZgJAD4l97tlDug/LYC0FGEIr X-Received: by 2002:a17:903:41d0:b0:1bb:fcb9:f85 with SMTP id u16-20020a17090341d000b001bbfcb90f85mr4633414ple.32.1692479128499; Sat, 19 Aug 2023 14:05:28 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1692479128; cv=pass; d=google.com; s=arc-20160816; b=09smpg9uFQtmQsKjhgoBLIn2p6MUehnsLE+OTL0Hhos9nqPNzoqr57gV5K6mm2ewHa VfCxjBvJoyO+qzWDGt0W4lJRMRUGNItp+jh4PrUuT39Bp+7SFk/9itmkeg3PGJAfARyw snA2lyT1GpF5A802n2B1P4+7WC9FO9cQUfGc7Bbs/EOKUosF7pzhNiZKhV7WRNb/EA3E QWcOWb8WP/Dx2SWFxnNh/bk9cs9URGKTXBGzCHNn8ZSXqDuuNt6tLN4NGzUl3SeeCW1p f4SsXq/dhCQxHU57Vr3N7O7z0WflAfqeyFxHvvSsZ1tohLig6IwrSezHXZFtkltLwsRv UTig== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=1DtDnQb3t799BpMV2b8fe2VqVvoQ50dmSVlrU7UEntU=; fh=RrkdC81dfSg5wMaJIRUZzOCN8dQO7whkk2UWG+wjDiI=; b=xjRRquD/x7zzWui9u0wBTTuE/CvzwNDF97xPuVXL0HEpy6hWDHPmVcmCN1g2DHOpQl Q2a8h9E1dFWWmZ8HASsh79xyKAWcirL+kkWJd6O3yEDLNdeSsDHYYg66frQjBuzOrssK mNiLPNxvy1d4/KTMt9D/DknfiJrDIdOzn3/5pZ6hNJsh91u/R8vJvsk4RPgMU1N5Ziyy uZgOdIOeHQrO39vxkMiB9f7AngUDgnzr5FhUBFaIo66xFB+BU+NHRcu6b1zeVSSYPKQE W4GlWg+Sx1HwigG51PcffWOrVSiat1FH6qxMGnEQ1Qnt8SB/mVCzJULQDpoceL0+wiDH VTcA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@nxp.com header.s=selector2 header.b=pDx39EBW; arc=pass (i=1 spf=pass spfdomain=nxp.com dkim=pass dkdomain=nxp.com dmarc=pass fromdomain=nxp.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nxp.com Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id m66-20020a633f45000000b0054402b987f8si3903933pga.605.2023.08.19.14.05.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 19 Aug 2023 14:05:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@nxp.com header.s=selector2 header.b=pDx39EBW; arc=pass (i=1 spf=pass spfdomain=nxp.com dkim=pass dkdomain=nxp.com dmarc=pass fromdomain=nxp.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nxp.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id DE6E1C6E43; Sat, 19 Aug 2023 01:43:59 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352796AbjHQPHW (ORCPT <rfc822;shaohuahua6@gmail.com> + 99 others); Thu, 17 Aug 2023 11:07:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41080 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352808AbjHQPHC (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 17 Aug 2023 11:07:02 -0400 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2064.outbound.protection.outlook.com [40.107.20.64]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AF94192; Thu, 17 Aug 2023 08:07:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EausO78CWhJXke4/uyL/aFrKfJAG0R+1aG4O5z00vUQMnA1skzVbl2TMlFyrxqfFymPdaZwWnZZawma8StTlrs4oP/aWEOLU+qkM8ufVbmxJVKh0pbkk6xcww1uiHMRQ7Dya3W/+M2vGARAAQcmYyVHGkJvHmOppdiQUGcjegO27pb8PTrXY0+aAJhVAanGN8yzbwFHNR1AjIUlEOBJhwxrKOo/auHTD/PPk1phSLufDEljjjrMwLonXsidZpHb8HjxL5IJc9/TPZOXoMpWOfmt3oIMc1RApB+FW+kzCtqo37M64Xx48Pgubc5bygkIZ2uq3B0GTOA3hU4S5rR+QjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1DtDnQb3t799BpMV2b8fe2VqVvoQ50dmSVlrU7UEntU=; b=a3ibNcMRmXXxCMIQle9kMpBJDT99YI6hVxR1z7rvD0v8q/CLt7OQdbi1jsdKeVq95MJpx3wFvvHyP6zty5u9F0u8vfNTpPoE15Kij5Gf6rMYo/bTGyN+bu7EzJ0cxUdcP4zNcoa6AM5ayo02VDgoEMSz1txi2xyEoOy7NwStUTGZSY10cjB232PlAnX3LLu8zQYj4DF82IBSH02V1VZYdGRbF44oRyIYLRDshwcghV3kl7wyIJtMiST/nmdX0XNq1ZypIFWFP08gxnudRXR53CMBUwbIc9NkEHMadM91xZrNNUXoxKYPipZn6DcDY2DroMnocAMTEbB64fraMqhIxQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1DtDnQb3t799BpMV2b8fe2VqVvoQ50dmSVlrU7UEntU=; b=pDx39EBWs5KAFBBEAI7qiOyB9X632TspLelwMRgWdiiVm+WdYVeOnlIOuRaOc4RTOz3T/Ejll8+4jatsyfFZm0oq1b7j60SBnNVGutlEHP9Ab6w3Nb61kAcsGeHI6ncFWljD9kwFKuvTBrn0wk2VF7Z3dwx2avdxCrJ/EM37IFA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nxp.com; Received: from AM0PR04MB6452.eurprd04.prod.outlook.com (2603:10a6:208:16d::21) by PAXPR04MB9469.eurprd04.prod.outlook.com (2603:10a6:102:2b4::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6678.29; Thu, 17 Aug 2023 15:06:59 +0000 Received: from AM0PR04MB6452.eurprd04.prod.outlook.com ([fe80::d4ed:20a0:8c0a:d9cf]) by AM0PR04MB6452.eurprd04.prod.outlook.com ([fe80::d4ed:20a0:8c0a:d9cf%7]) with mapi id 15.20.6678.031; Thu, 17 Aug 2023 15:06:59 +0000 From: Vladimir Oltean <vladimir.oltean@nxp.com> To: netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org Cc: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>, Heiner Kallweit <hkallweit1@gmail.com>, Andrew Lunn <andrew@lunn.ch>, Florian Fainelli <f.fainelli@gmail.com>, Madalin Bucur <madalin.bucur@nxp.com>, Ioana Ciornei <ioana.ciornei@nxp.com>, Camelia Groza <camelia.groza@nxp.com>, Li Yang <leoyang.li@nxp.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor@kernel.org>, Sean Anderson <sean.anderson@seco.com>, Maxime Chevallier <maxime.chevallier@bootlin.com>, Vinod Koul <vkoul@kernel.org>, Kishon Vijay Abraham I <kishon@kernel.org> Subject: [RFC PATCH net-next 2/8] phy: introduce the PHY_MODE_ETHERNET_PHY mode for phy_set_mode_ext() Date: Thu, 17 Aug 2023 18:06:38 +0300 Message-Id: <20230817150644.3605105-3-vladimir.oltean@nxp.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230817150644.3605105-1-vladimir.oltean@nxp.com> References: <20230817150644.3605105-1-vladimir.oltean@nxp.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: AM0PR02CA0137.eurprd02.prod.outlook.com (2603:10a6:20b:28c::34) To AM0PR04MB6452.eurprd04.prod.outlook.com (2603:10a6:208:16d::21) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM0PR04MB6452:EE_|PAXPR04MB9469:EE_ X-MS-Office365-Filtering-Correlation-Id: 6308542f-9714-43d0-8d9d-08db9f339aa5 X-LD-Processed: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635,ExtAddr X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: CMnFZY7dLYkR2qLU1rQWVMl4HBbIIJx+j/8zTXzS0M460yXtcLMRb0Eqzwu/2IlXirOeqUVionfH63UpthejHUn9h01CjbwpfJzTEWTysOzB9UW0RgNMc1eVD9ivCLxcujG19OS24ibyDwpamKGdEE+DMq5mgF0YeFvWVl1xXcTEQLOCvFouQ1wjzBVzmtNnjBtga+kYLw0wGVk/glICjaeNaF9Tlbr1yRm81AOcpyhHJNluFnqPwZh5K5HCqeCFPotWQzms56mF6CIp7IkUSXbzbrQgjHBMvV0xR67mTMnitsjjw6sG7rFR3o+uczC92O8rmoI1wXAwezfw7xaLvInGlr/RGoN7UTJtln4wwT+um3+MVnTpIsEBLKcidH3UAISM5ldB/3mLKY2BcD/LaD+nTHDIkq+BUi60xSTK5LyPCw6QqYv+7Dztd8K7iFnzEMzk/ep9vxgh3GTB9WY6bbrYtMsi2nrwDOEaH4BaayOB2WcZLALhtzLjKVrtekT4gmDOIpSFFOi67mNyGF5hdwdoVA3KOtyRtKrdEyZLuqUECUbCxCy4+UAM2o4IA9jef96Iqs/TRjLp9strlCidVdsPOfzDA/LUKMpU4B2oBwmJ41WUZprcyEOZwV5ztgCH X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM0PR04MB6452.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366004)(376002)(136003)(346002)(39860400002)(396003)(186009)(451199024)(1800799009)(2906002)(83380400001)(26005)(86362001)(7416002)(478600001)(6506007)(36756003)(6666004)(2616005)(1076003)(6486002)(6512007)(52116002)(44832011)(5660300002)(41300700001)(316002)(54906003)(66946007)(66476007)(66556008)(4326008)(8676002)(8936002)(38350700002)(38100700002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: CxmRyHz48aEQpFLLWw/qc4AOk9++fTBgxl40zFDmD25sbKbUGPXYmsA9PsRB+wKbcuSNbe+UnSfBJOZAEwVaVKOgth9X4ws8uTDUruSBCfc7WWxQZCdxAGdn2eSk2jcsR7mDm5IJLVL7xK9wQvKpgUx/IQxe+re/vkhceSJFRPDHrI+VhNnD55oNIPJ/RCVxnSWg4OzdMOX3vwZAaDRtr8F6RdAS4p4dAM8NwwTdTdiJGDdVWjgnCkuufiFOKd3A75JwdtL41RNHWmWxY0xOMRcRgJqrBF957KoPV3r5rvw9qEd4b+D6J8Vgu4Zod4iQ66Ku7Dj9FTr2OBxPfAKuWvrCa8fvKJ+RzASHW0H8IExnBF835FuEhcepW/RtV22BNdl6phNVvObQmB+BhC1J87+RChdWUGXnzy3wk5eQkzuKEuygWNj+swtUe/weDs+aDJt4UjHVCk7Oein8c/VlmjJRblcYV5H4wGbP1/jyp/W3MXOBFafgk5lXAXZV/fO3XhRVECRFAnBhQ6Y05oMYT5L6SiBvJrqKogTatDdNvqoEYTS7XZyM/JKCewPkQSZAiaz8G1yI7/NurVg/EoQ+TsCD5czl46W5K37yj8pqWk1Ldy4klgtx+edD9ESvia1BMSHy9w+ggHF9JpP1vAf5aIw7K9UZP4yAUAaev6KePwQo6Cxnb7JRKIWr/q03omHtwKhC6bVV2iNYmc6bg3jXVJtlJR0CwTDCGHZmldXsXRF1tXKLqYYbJSq85d83yh21uWOOrnZcguuDiPqKMm/48Ol5BL+dDg+MDgiSFCPiAYCcWkz5ehAC9B0Ux0VMzlJ33QfozDbRQzEldwnuzNCZGvklp2B5pgUIzqtKB7qOBb7pbiTHniuUvQn0WMqSsXIRcimYQEeWTOjm1gVjosdRwc/AR91hnSokh4yZVD8no5Q+pPP5TXmMDWcgKvtvt/P0Z9trYWeO8OktbF3P+fbaVF93xli/OFeSsqA8U+0N3+EDQwkfch4TJe1zgAwAvyvwBRac3y/W1Y0gikEKfFn6L1kPnC5Sz0nrh9JyXpMbOmFZmy+Ko1lB77eVP6gqVNtBEx4o+o7dszt7YCuqsi7FooCRCv+YJESHjnL6EDvrBwAhJCHdDTKQDB2VY/jPDbwCIuu6o5oX4nmCeQKtupIQE+d0a44XQ/syqKv7LpUrathheYTCW7zeZzEOKHO12ysUjOP+xjuIRKW4RWqfOgiz6lW2DNjrDJPM5EHr8dlsCSR4xkGXzhHoMxXgH/5s0QzgslzPV5gBApKdenSD1cH8fJAvukAjznusrucC2VftLtJxOtDqtJEJ6mu07xzrOl0Dpt3K8irYoYBSs8F6tzcKESypl14qRF/+K2N/UW6qNqdfH7+2cbX/KWfAck7oG7+TjvH/PydzrffGyf8zgqhD5R7vPHuOUROoHpJulvbV6T9PCVUGMgSxgc7vbLICy7vLsFdgne1ODE8rT4mWFieEfmikLWXnJx2VeLI35b9RDD8T84erCAORJmyxxunurUoAECDvirzNYDSL9elT0yDq/OldME9Qz5atpcMaaY5onXSsx3XJevj5iGb0eB6qfDJhxb9LDRYs7WA98olEGCg8qQ== X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6308542f-9714-43d0-8d9d-08db9f339aa5 X-MS-Exchange-CrossTenant-AuthSource: AM0PR04MB6452.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2023 15:06:59.1643 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: iq3RO5yRogk6C/K9C6CdovgTJPttt2ebCYNP0P7vmqwGuEXyIDm7UCZwwo6FwPbWDXyrWx9zBNjxpNYOAZIVbQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR04MB9469 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1774692994625542994 X-GMAIL-MSGID: 1774692994625542994 |
Series |
None
|
|
Commit Message
Vladimir Oltean
Aug. 17, 2023, 3:06 p.m. UTC
As opposed to PHY_MODE_ETHERNET which takes a phy_interface_t as is
expected to be used by an Ethernet MAC driver, PHY_MODE_ETHERNET takes
an enum ethtool_link_mode_bit_indices and expects to be used by an
Ethernet PHY driver.
It is true that the phy_interface_t type also contains definitions for
PHY_INTERFACE_MODE_10GKR and PHY_INTERFACE_MODE_1000BASEKX, but those
were deemed to be mistakes, and shouldn't be used going forward, when
10GBase-KR and 1GBase-KX are really link modes. Thus, I believe that the
distinction is necessary, rather than hacking more improper PHY modes.
In particular to the Lynx SerDes, it can be used (as the PMA/PMD layer)
in conjunction with a separate backplane AN/LT block to form a
full-fledged copper backplane Ethernet PHY. The configuration of the
lanes is relatively similar to what is done for a typical MAC-to-PHY
link, except that we allow tuning the electrical equalization parameters
of the link (support for which will come as a separate change).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
include/linux/phy/phy.h | 1 +
1 file changed, 1 insertion(+)
Comments
On 8/21/23 14:13, Vladimir Oltean wrote: > Hi Sean, > > On Mon, Aug 21, 2023 at 01:30:46PM -0400, Sean Anderson wrote: >> On 8/17/23 11:06, Vladimir Oltean wrote: >> > As opposed to PHY_MODE_ETHERNET which takes a phy_interface_t as is >> > expected to be used by an Ethernet MAC driver, PHY_MODE_ETHERNET takes >> > an enum ethtool_link_mode_bit_indices and expects to be used by an >> > Ethernet PHY driver. >> > >> > It is true that the phy_interface_t type also contains definitions for >> > PHY_INTERFACE_MODE_10GKR and PHY_INTERFACE_MODE_1000BASEKX, but those >> > were deemed to be mistakes, and shouldn't be used going forward, when >> > 10GBase-KR and 1GBase-KX are really link modes. Thus, I believe that the >> > distinction is necessary, rather than hacking more improper PHY modes. >> >> 10GBase-KR and 1000Base-KX are both electrically (e.g. link mode) and >> functionally (e.g. phy mode) different from 10GBase-R and 1000Base-X due >> to differing autonegotiation. So the phy modes are still relevant, and >> should still be used to ensure the correct form of autonegotiation is >> selected. >> >> That said, I do agree that from the phy's (serdes's) point of view, >> there are only electrical differences between these modes. >> >> However, I'm not sure we need to have a separate mode here. I think this >> would only be necessary if there were electrically-incompatible modes >> which shared the same signalling. E.g. if 802.3 decided that they wanted >> a "long range backplane ethernet" or somesuch with different >> drive/equalization requirements from 1000BASE-KX et al. but with the >> same signalling. Otherwise, we can infer the link mode from the phy >> mode. >> >> --Sean > > Thanks for taking the time to look at this RFC. > > I will ask a clarification question. When you say "I'm not sure we need > to have a separate mode here", what do you mean? > > The lynx-28g implementation (not shown here) will need to distinguish > between 1000Base-X and 1000Base-KX, and between 10GBase-R and 10GBase-KR > respectively, to configure the number of electrical equalization taps in > the LNmTECR registers, and to allocate memory for the ("K"-specific) > link training algorithm. Also, in the particular case of BaseX vs > BaseKX, we need to modify the PCCR8 register depending on whether the > C22 BaseX PCS or the C45 PCS + AN/LT blocks need to be available over > MDIO. > > So, passing PHY_INTERFACE_MODE_1000BASEX when we intend 1000Base-KX is > simply not possible, because the dpaa2-mac consumer already uses > PHY_INTERFACE_MODE_1000BASEX to mean a very different (and legit) thing. > > Do you mean instead that we could use the PHY_INTERFACE_MODE_1000BASEKX > that you've added to phy_interface_t? It's not clear that this is what > you're suggesting, so feel free to stop reading here if it isn't. Yes. The intent for this interface mode is for the PCS to select the appropriate autonegotiation. So if you use the 1000Base-KX link mode, you should also use the 1000BASEKX phy mode (unless you have a separate phy doing the conversion). > But mtip_backplane uses linkmode_c73_priority_resolution() (a function > added by me, sure, but nonetheless, it operates in the linkmode namespace, > as a PHY driver helper should) to figure out the proper argument to pass > to phy_set_mode_ext(). That argument has the enum ethtool_link_mode_bit_indices. > > So, a translation between enum ethtool_link_mode_bit_indices and > phy_interface_t would be needed. That would be more or less doable for > 1000Base-KX and 10GBase-KR, but it needs more phy_interface_t additions > for: > > static const enum ethtool_link_mode_bit_indices c73_linkmodes[] = { > ETHTOOL_LINK_MODE_100000baseCR4_Full_BIT, > ETHTOOL_LINK_MODE_100000baseKR4_Full_BIT, > /* ETHTOOL_LINK_MODE_100000baseKP4_Full_BIT not supported */ > /* ETHTOOL_LINK_MODE_100000baseCR10_Full_BIT not supported */ > ETHTOOL_LINK_MODE_40000baseCR4_Full_BIT, > ETHTOOL_LINK_MODE_40000baseKR4_Full_BIT, > ETHTOOL_LINK_MODE_25000baseKR_Full_BIT, > ETHTOOL_LINK_MODE_25000baseCR_Full_BIT, > /* ETHTOOL_LINK_MODE_25000baseKRS_Full_BIT not supported */ > /* ETHTOOL_LINK_MODE_25000baseCRS_Full_BIT not supported */ > ETHTOOL_LINK_MODE_10000baseKR_Full_BIT, > ETHTOOL_LINK_MODE_10000baseKX4_Full_BIT, > ETHTOOL_LINK_MODE_1000baseKX_Full_BIT, > }; Well, I suppose you really do have "electrically-incompatible modes which shared the same signalling". So I think it's reasonable to go this route. I considered something like this for lynx10g, but that serdes only supports 10GBase-KR, so there was no need to differentiate that from 10GBase-KX4 (or 10GBase-CR). > I guess that network PHY maintainers will need to chime in and say > whether that's the path forward or not. I think the commit message could better motivate this patch by drawing a distinction between a serdes which is talking to a phy or sfp which will convert the signals to the final link mode, and a serdes which is acting as the final connection to the far end, with nothing intervening. --Sean
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h index 456d21c67e4f..7e10761303fc 100644 --- a/include/linux/phy/phy.h +++ b/include/linux/phy/phy.h @@ -39,6 +39,7 @@ enum phy_mode { PHY_MODE_UFS_HS_B, PHY_MODE_PCIE, PHY_MODE_ETHERNET, + PHY_MODE_ETHERNET_PHY, PHY_MODE_MIPI_DPHY, PHY_MODE_SATA, PHY_MODE_LVDS,