Message ID | 20231126060732.31764-4-quic_luoj@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:ce62:0:b0:403:3b70:6f57 with SMTP id o2csp2317937vqx; Sat, 25 Nov 2023 22:09:11 -0800 (PST) X-Google-Smtp-Source: AGHT+IGQQXIzb7IxIo2iFvETbQCVyONWJoGM+yaJzTvKh5pV0ZGudj4pmVKCpYXXh4ZbT+/60bqn X-Received: by 2002:a17:902:ac86:b0:1cf:c3fb:a75f with SMTP id h6-20020a170902ac8600b001cfc3fba75fmr1290328plr.17.1700978950821; Sat, 25 Nov 2023 22:09:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700978950; cv=none; d=google.com; s=arc-20160816; b=hyePTJ/ok0BrVhfSPJh+HlG7Ec9P56OVry5iLZ9JxQtv8VV22VNrKtllC50dVY/Zl+ HcpJda1DxQXLIy6hw8lrKnpAZGlQgxXwM8VON/GRurfMADbnta8JTB7ItA+fHwmRf+TX 1VMrdqEC1hsDLlcAOy+sZnlAmL3nvh8Pj3E0Mv9OJjYoeljIjXmOjVILDoSFC3Ffhw9V ae56CLi1gdOz43a1vKi3wGyHtaCy/51i8SRKCSOQP4Ug2sRH8LaIccV/431uqOLeF+PV ucIW2JHbRpP4a4V6rOHMRGbjzCmjImW+o8JL/aO4WlDO+o91f9lb1xa02raPkHC2fKTV Ln9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=mGAPiwQH9ZnwXhYA9V18stSSqTp0PD6Oex4u6WDgTkU=; fh=CzJZH1Mq0+1gFor3WuKjwLRRL9rPD0zvQs0go/fRLgA=; b=z5wyfRWIU44YeIFDUkxEXvTP0C+YcZs0vh9YfJ9gT4EV6JhLf7NmYPHHwQ9aN3Ns4s 1/cmv0p8VDsD/icUF8ViR3pW/XiyAxzDiwkgFaQkrG3RYGjmx3pWMlyBVNBdrLi1a33k CVIayniCzI/n+UN+iyDPciyQVfpGpHUUl9rYT39AV/i+qUhZz8C3qU2Bba3NMoq5WLzi M09urxb2CBxwFV4oL3fA9fJoP0F9L68+ztj6z0naeUl5Tu6fo5JGLazh5rM2y3BUPyTP EbUm1+Jc5UvKQ5IrzbM1OxP9qswJTHoiFnbWu14Hlk+5gQnGRdeKOVQguErWR6osh+C6 RKWg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=FMvBQqNQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id c14-20020a170903234e00b001cfc9a19164si1633plh.532.2023.11.25.22.09.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 25 Nov 2023 22:09:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=FMvBQqNQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id E2D70805B9EE; Sat, 25 Nov 2023 22:09:05 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231978AbjKZGIo (ORCPT <rfc822;kernel.ruili@gmail.com> + 99 others); Sun, 26 Nov 2023 01:08:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43480 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229447AbjKZGId (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 26 Nov 2023 01:08:33 -0500 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 458E9110; Sat, 25 Nov 2023 22:08:40 -0800 (PST) Received: from pps.filterd (m0279866.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3AQ636iJ027972; Sun, 26 Nov 2023 06:08:19 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type; s=qcppdkim1; bh=mGAPiwQH9ZnwXhYA9V18stSSqTp0PD6Oex4u6WDgTkU=; b=FMvBQqNQ97RijMq/5pP7swx1j+K9+GC0XLL6JAwdok6ye9ix0b/QaMr7/4k0nugA+pkN VBIC1RJ0H4KrpZTwcRsP5KXN+Lyl3JWDTN7C+W/4uvuHRop6bnc8P13C03IAC1cbdcuJ RJpHLyf7nN63lfEt4Akq6rn5ISRUTZ/bvPOjYliwQVNP7iWtH3tpkOsEOgs3MakCry0l YKtqaNNhMEcBOdeAdQ87SEDQg9Y1Gs94QrXEFfmJRuCGpI+9g1ccUnoxrVAGMH58vO8G Bw1XeIJnuN3HCKDHA7jySYv0z5w0If5jqPGfYvTTV4prA6/UU/53dtjdrsIs33GSuzIJ FQ== Received: from nalasppmta04.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3uka7g9nnf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 26 Nov 2023 06:08:19 +0000 Received: from nalasex01c.na.qualcomm.com (nalasex01c.na.qualcomm.com [10.47.97.35]) by NALASPPMTA04.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 3AQ68IWA021577 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 26 Nov 2023 06:08:18 GMT Received: from akronite-sh-dev02.qualcomm.com (10.80.80.8) by nalasex01c.na.qualcomm.com (10.47.97.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.40; Sat, 25 Nov 2023 22:08:15 -0800 From: Luo Jie <quic_luoj@quicinc.com> To: <andrew@lunn.ch>, <davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>, <robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>, <hkallweit1@gmail.com>, <linux@armlinux.org.uk>, <corbet@lwn.net> CC: <netdev@vger.kernel.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-doc@vger.kernel.org> Subject: [PATCH v6 3/6] net: phy: at803x: add QCA8084 ethernet phy support Date: Sun, 26 Nov 2023 14:07:29 +0800 Message-ID: <20231126060732.31764-4-quic_luoj@quicinc.com> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20231126060732.31764-1-quic_luoj@quicinc.com> References: <20231126060732.31764-1-quic_luoj@quicinc.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nalasex01c.na.qualcomm.com (10.47.97.35) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-ORIG-GUID: s6-0erMI-epKZLTX3V-qqy0Uem6zcHAm X-Proofpoint-GUID: s6-0erMI-epKZLTX3V-qqy0Uem6zcHAm X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.987,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-11-26_04,2023-11-22_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 clxscore=1015 suspectscore=0 lowpriorityscore=0 mlxscore=0 bulkscore=0 mlxlogscore=986 adultscore=0 phishscore=0 impostorscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311060000 definitions=main-2311260042 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Sat, 25 Nov 2023 22:09:06 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783605704357188411 X-GMAIL-MSGID: 1783605704357188411 |
Series |
add qca8084 ethernet phy driver
|
|
Commit Message
Jie Luo
Nov. 26, 2023, 6:07 a.m. UTC
Add qca8084 PHY support, which is four-port PHY with maximum
link capability 2.5G, the features of each port is almost same
as QCA8081 and slave seed config is not needed.
Three kind of interface modes supported by qca8084.
PHY_INTERFACE_MODE_10G_QXGMII, PHY_INTERFACE_MODE_2500BASEX and
PHY_INTERFACE_MODE_SGMII.
The PCS(serdes) and clock are also needed to be configured to
bringup qca8084 PHY, which will be added in the pcs driver.
The additional CDT configurations used for qca8084.
Signed-off-by: Luo Jie <quic_luoj@quicinc.com>
---
drivers/net/phy/at803x.c | 50 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
Comments
> + /* There are two PCSs available for QCA8084, which support the > + * following interface modes. > + * > + * 1. PHY_INTERFACE_MODE_10G_QXGMII utilizes PCS1 for all > + * available 4 ports, which is for all link speeds. > + * > + * 2. PHY_INTERFACE_MODE_2500BASEX utilizes PCS0 for the > + * fourth port, which is only for the link speed 2500M same > + * as QCA8081. > + * > + * 3. PHY_INTERFACE_MODE_SGMII utilizes PCS0 for the fourth > + * port, which is for the link speed 10M, 100M and 1000M same > + * as QCA8081. > + */ How are these 3 modes configured? I don't see any software configuration of this in these drivers. Can it only by configured by strapping? I think there should be some validation of the phydev->interface mode. Are ports 1-3 set to PHY_INTERFACE_MODE_10G_QXGMII? Is port 4 interface mode consistent with the strapping? Andrew
On 11/27/2023 1:31 AM, Andrew Lunn wrote: >> + /* There are two PCSs available for QCA8084, which support the >> + * following interface modes. >> + * >> + * 1. PHY_INTERFACE_MODE_10G_QXGMII utilizes PCS1 for all >> + * available 4 ports, which is for all link speeds. >> + * >> + * 2. PHY_INTERFACE_MODE_2500BASEX utilizes PCS0 for the >> + * fourth port, which is only for the link speed 2500M same >> + * as QCA8081. >> + * >> + * 3. PHY_INTERFACE_MODE_SGMII utilizes PCS0 for the fourth >> + * port, which is for the link speed 10M, 100M and 1000M same >> + * as QCA8081. >> + */ > > How are these 3 modes configured? I don't see any software > configuration of this in these drivers. Can it only by configured by > strapping? The interface mode is passed in the .config_init, which is configured by the PCS driver, the hardware register is located in the PCS, this driver will be pushed later. > > I think there should be some validation of the phydev->interface > mode. Are ports 1-3 set to PHY_INTERFACE_MODE_10G_QXGMII? Is port 4 > interface mode consistent with the strapping? > > Andrew All ports(1-4) can be PHY_INTERFACE_MODE_10G_QXGMII, if port4 is connected with PCS0, which will works on sgmii/2500basex mode, these configuration is controlled by register instead of boot strapping.
On Mon, Nov 27, 2023 at 02:21:46PM +0800, Jie Luo wrote: > > > On 11/27/2023 1:31 AM, Andrew Lunn wrote: > > > + /* There are two PCSs available for QCA8084, which support the > > > + * following interface modes. > > > + * > > > + * 1. PHY_INTERFACE_MODE_10G_QXGMII utilizes PCS1 for all > > > + * available 4 ports, which is for all link speeds. > > > + * > > > + * 2. PHY_INTERFACE_MODE_2500BASEX utilizes PCS0 for the > > > + * fourth port, which is only for the link speed 2500M same > > > + * as QCA8081. > > > + * > > > + * 3. PHY_INTERFACE_MODE_SGMII utilizes PCS0 for the fourth > > > + * port, which is for the link speed 10M, 100M and 1000M same > > > + * as QCA8081. > > > + */ > > > > How are these 3 modes configured? I don't see any software > > configuration of this in these drivers. Can it only by configured by > > strapping? > > The interface mode is passed in the .config_init, which is configured > by the PCS driver, the hardware register is located in the PCS, this > driver will be pushed later. Is this the same as how the syqca807x works? Can the PCS driver be shared by these two drivers? What i don't like at the moment is that we have two driver developments going on at once for hardware which seems very similar, but no apparent cooperation? Andrew
On 11/27/2023 9:22 PM, Andrew Lunn wrote: > On Mon, Nov 27, 2023 at 02:21:46PM +0800, Jie Luo wrote: >> >> >> On 11/27/2023 1:31 AM, Andrew Lunn wrote: >>>> + /* There are two PCSs available for QCA8084, which support the >>>> + * following interface modes. >>>> + * >>>> + * 1. PHY_INTERFACE_MODE_10G_QXGMII utilizes PCS1 for all >>>> + * available 4 ports, which is for all link speeds. >>>> + * >>>> + * 2. PHY_INTERFACE_MODE_2500BASEX utilizes PCS0 for the >>>> + * fourth port, which is only for the link speed 2500M same >>>> + * as QCA8081. >>>> + * >>>> + * 3. PHY_INTERFACE_MODE_SGMII utilizes PCS0 for the fourth >>>> + * port, which is for the link speed 10M, 100M and 1000M same >>>> + * as QCA8081. >>>> + */ >>> >>> How are these 3 modes configured? I don't see any software >>> configuration of this in these drivers. Can it only by configured by >>> strapping? >> >> The interface mode is passed in the .config_init, which is configured >> by the PCS driver, the hardware register is located in the PCS, this >> driver will be pushed later. > > Is this the same as how the syqca807x works? Can the PCS driver be > shared by these two drivers? I am not sure syqca807x, would you point me the code path of this driver? > > What i don't like at the moment is that we have two driver > developments going on at once for hardware which seems very similar, > but no apparent cooperation? > > Andrew The PCS of qca8084 is the PHY PCS, which should be new PCS driver, in the previous chips, we don't have this kind of PHY PCS.
On Tue, Nov 28, 2023 at 03:16:45PM +0800, Jie Luo wrote: > > > The interface mode is passed in the .config_init, which is configured > > > by the PCS driver, the hardware register is located in the PCS, this > > > driver will be pushed later. > > > > Is this the same as how the syqca807x works? Can the PCS driver be > > shared by these two drivers? > > I am not sure syqca807x, would you point me the code path of this driver? > > > > > What i don't like at the moment is that we have two driver > > developments going on at once for hardware which seems very similar, > > but no apparent cooperation? > > > > Andrew > > The PCS of qca8084 is the PHY PCS, which should be new PCS driver, > in the previous chips, we don't have this kind of PHY PCS. No. PCS drivers are for MAC-side PCS drivers, not PHY-side PCS drivers. +------------- | PHY MAC---PCS --- link --- PCS --- ... ^ | ^ | +--|---------- For this PCS | Not for this PCS
On 11/28/2023 5:00 PM, Russell King (Oracle) wrote: > On Tue, Nov 28, 2023 at 03:16:45PM +0800, Jie Luo wrote: >>>> The interface mode is passed in the .config_init, which is configured >>>> by the PCS driver, the hardware register is located in the PCS, this >>>> driver will be pushed later. >>> >>> Is this the same as how the syqca807x works? Can the PCS driver be >>> shared by these two drivers? >> >> I am not sure syqca807x, would you point me the code path of this driver? >> >>> >>> What i don't like at the moment is that we have two driver >>> developments going on at once for hardware which seems very similar, >>> but no apparent cooperation? >>> >>> Andrew >> >> The PCS of qca8084 is the PHY PCS, which should be new PCS driver, >> in the previous chips, we don't have this kind of PHY PCS. > > No. PCS drivers are for MAC-side PCS drivers, not PHY-side PCS drivers. > > +------------- > | PHY > MAC---PCS --- link --- PCS --- ... > ^ | ^ > | +--|---------- > For this PCS | > Not for this PCS > The PCS drivers in drivers/net/pcs/ should be in PHY side, such as pcs-lynx.c and pcs-xpcs.c, they are configuring the MDIO device registers.
On Tue, Nov 28, 2023 at 05:50:41PM +0800, Jie Luo wrote: > > > On 11/28/2023 5:00 PM, Russell King (Oracle) wrote: > > On Tue, Nov 28, 2023 at 03:16:45PM +0800, Jie Luo wrote: > > > > > The interface mode is passed in the .config_init, which is configured > > > > > by the PCS driver, the hardware register is located in the PCS, this > > > > > driver will be pushed later. > > > > > > > > Is this the same as how the syqca807x works? Can the PCS driver be > > > > shared by these two drivers? > > > > > > I am not sure syqca807x, would you point me the code path of this driver? > > > > > > > > > > > What i don't like at the moment is that we have two driver > > > > developments going on at once for hardware which seems very similar, > > > > but no apparent cooperation? > > > > > > > > Andrew > > > > > > The PCS of qca8084 is the PHY PCS, which should be new PCS driver, > > > in the previous chips, we don't have this kind of PHY PCS. > > > > No. PCS drivers are for MAC-side PCS drivers, not PHY-side PCS drivers. > > > > +------------- > > | PHY > > MAC---PCS --- link --- PCS --- ... > > ^ | ^ > > | +--|---------- > > For this PCS | > > Not for this PCS > > > > The PCS drivers in drivers/net/pcs/ should be in PHY side, such as > pcs-lynx.c and pcs-xpcs.c, they are configuring the MDIO device > registers. Wrong. No they are not. Just because they are accessed via MDIO does not mean they are in the PHY. MDIO can be used for more than just the PHY, and is on a lot of platforms. LX2160A for example has many MDIO buses, and the PCSes (of which there are multiple inside the chip, and use pcs-lynx) are accessed through the MDIO bus specific to each port. They are not MMIO mapped. The same is true on stmmac platforms, where xpcs is used - xpcs is the _MAC_ side PCS. Sorry but you are wrong.
On 11/28/2023 6:35 PM, Russell King (Oracle) wrote: > On Tue, Nov 28, 2023 at 05:50:41PM +0800, Jie Luo wrote: >> >> >> On 11/28/2023 5:00 PM, Russell King (Oracle) wrote: >>> On Tue, Nov 28, 2023 at 03:16:45PM +0800, Jie Luo wrote: >>>>>> The interface mode is passed in the .config_init, which is configured >>>>>> by the PCS driver, the hardware register is located in the PCS, this >>>>>> driver will be pushed later. >>>>> >>>>> Is this the same as how the syqca807x works? Can the PCS driver be >>>>> shared by these two drivers? >>>> >>>> I am not sure syqca807x, would you point me the code path of this driver? >>>> >>>>> >>>>> What i don't like at the moment is that we have two driver >>>>> developments going on at once for hardware which seems very similar, >>>>> but no apparent cooperation? >>>>> >>>>> Andrew >>>> >>>> The PCS of qca8084 is the PHY PCS, which should be new PCS driver, >>>> in the previous chips, we don't have this kind of PHY PCS. >>> >>> No. PCS drivers are for MAC-side PCS drivers, not PHY-side PCS drivers. >>> >>> +------------- >>> | PHY >>> MAC---PCS --- link --- PCS --- ... >>> ^ | ^ >>> | +--|---------- >>> For this PCS | >>> Not for this PCS >>> >> >> The PCS drivers in drivers/net/pcs/ should be in PHY side, such as >> pcs-lynx.c and pcs-xpcs.c, they are configuring the MDIO device >> registers. > > Wrong. No they are not. Just because they are accessed via MDIO does > not mean they are in the PHY. MDIO can be used for more than just the > PHY, and is on a lot of platforms. > > LX2160A for example has many MDIO buses, and the PCSes (of which there > are multiple inside the chip, and use pcs-lynx) are accessed through > the MDIO bus specific to each port. They are not MMIO mapped. > > The same is true on stmmac platforms, where xpcs is used - xpcs is the > _MAC_ side PCS. > > Sorry but you are wrong. > OK, but it creates the PCS driver based on the MDIO device in pcs-lynx.c looks like this PCS is located in PHY device from hardware perspective.
On Wed, Nov 29, 2023 at 06:34:16PM +0800, Jie Luo wrote: > > > The PCS drivers in drivers/net/pcs/ should be in PHY side, such as > > > pcs-lynx.c and pcs-xpcs.c, they are configuring the MDIO device > > > registers. > > > > Wrong. No they are not. Just because they are accessed via MDIO does > > not mean they are in the PHY. MDIO can be used for more than just the > > PHY, and is on a lot of platforms. > > > > LX2160A for example has many MDIO buses, and the PCSes (of which there > > are multiple inside the chip, and use pcs-lynx) are accessed through > > the MDIO bus specific to each port. They are not MMIO mapped. > > > > The same is true on stmmac platforms, where xpcs is used - xpcs is the > > _MAC_ side PCS. > > > > Sorry but you are wrong. > > > > OK, but it creates the PCS driver based on the MDIO device in pcs-lynx.c > looks like this PCS is located in PHY device from hardware perspective. In some ways, this contradiction has a potato-patato aspect to it. As Russell says, NXP devices do have internal SGMII/USXGMII/10GBASE-R ports which use pcs-lynx.c to access the registers of the PCS layer (which are on MDIO buses internal to the SoC). They could legally be called PHYs, because they have all the layers that 802.3 says a PHY should have: a PCS, a PMA and a PMD. But what phylib understands a phy_device to be is a more restricted definition than just "a PHY - any PHY". Originally, phylib considered a struct phy_device to be something (a discrete chip) that has pins and a phy_interface_t towards its host side, and pins + an ethtool_link_mode_bit_indices on its media side. Traditionally, the media side is exclusively copper (BASE-T, BASE-T1) or fiber (BASE-SX/LX). A struct phy_device was then also used with PHY_INTERFACE_MODE_INTERNAL to represent the built-in BASE-T PHYs that are embedded within certain small/medium business Ethernet switches. And then, more and more other similar embedded copper PHYs. The idea is that (1) a phy_device connects to a remote system, and (2) the phylib API does not have insight into the components of the PHY it controls: PCS, PMA, PMD. It's all just a monolithic struct phy_device. Because there are serial phy_interface_t modes where the MAC also need a PHY to even connect to the phylib PHY, a problem presented itself: phylib only has support for a single phy_device. So a new framework appeared: phylink, which uses the unmodified phylib layer for the external PHY, but models the MAC-side PHY using a different API. Later on, that API became the phylink_pcs. To muddy the waters, a phylink_pcs structure usually connects to another local component as described above, like a phylib PHY (on-board or on an SFP module). But it can also connect directly to a remote system (like a phy_device would). But the phylink_pcs is always integrated in silicon with the MAC, and the "media side" of it is a phy_interface_t type, not an ethtool_link_mode_bit_indices type. Having a separate phylink_pcs is what allows us to work around phylib's limitation of having a single phy_device. The reverse is also true: you can have a single phylink_pcs, and that belongs to the client MAC driver. The other layers (PMA/PMD) of the MAC-side PHY are modeled in the kernel as a struct phy (https://docs.kernel.org/driver-api/phy/index.html), and we have the phy_set_mode_ext() API for reconfiguring this layer to a different mode. Again, this is not applicable for phylib PHYs, which are monolithic. Given the above definitions, what NXP has and drives with pcs-lynx.c is not a struct phy_device, but a MAC-side PCS represented by a phylink_pcs. It absolutely does not matter that the register access method for the PCS is an internal MDIO bus. FWIW, the PMA/PMD layer is at drivers/phy/freescale/phy-fsl-lynx-28g.c. So, if put into the proper context, what Russell is saying is correct, but I think you need a bit of history to not get even more confused about why it is the way it is.
On 11/29/2023 8:04 PM, Vladimir Oltean wrote: > On Wed, Nov 29, 2023 at 06:34:16PM +0800, Jie Luo wrote: >>>> The PCS drivers in drivers/net/pcs/ should be in PHY side, such as >>>> pcs-lynx.c and pcs-xpcs.c, they are configuring the MDIO device >>>> registers. >>> >>> Wrong. No they are not. Just because they are accessed via MDIO does >>> not mean they are in the PHY. MDIO can be used for more than just the >>> PHY, and is on a lot of platforms. >>> >>> LX2160A for example has many MDIO buses, and the PCSes (of which there >>> are multiple inside the chip, and use pcs-lynx) are accessed through >>> the MDIO bus specific to each port. They are not MMIO mapped. >>> >>> The same is true on stmmac platforms, where xpcs is used - xpcs is the >>> _MAC_ side PCS. >>> >>> Sorry but you are wrong. >>> >> >> OK, but it creates the PCS driver based on the MDIO device in pcs-lynx.c >> looks like this PCS is located in PHY device from hardware perspective. > > In some ways, this contradiction has a potato-patato aspect to it. > As Russell says, NXP devices do have internal SGMII/USXGMII/10GBASE-R > ports which use pcs-lynx.c to access the registers of the PCS layer > (which are on MDIO buses internal to the SoC). They could legally be > called PHYs, because they have all the layers that 802.3 says a PHY > should have: a PCS, a PMA and a PMD. > > But what phylib understands a phy_device to be is a more restricted > definition than just "a PHY - any PHY". Originally, phylib considered a > struct phy_device to be something (a discrete chip) that has pins and a > phy_interface_t towards its host side, and pins + an ethtool_link_mode_bit_indices > on its media side. > > Traditionally, the media side is exclusively copper (BASE-T, BASE-T1) or > fiber (BASE-SX/LX). > > A struct phy_device was then also used with PHY_INTERFACE_MODE_INTERNAL > to represent the built-in BASE-T PHYs that are embedded within certain > small/medium business Ethernet switches. And then, more and more other > similar embedded copper PHYs. > > The idea is that (1) a phy_device connects to a remote system, and > (2) the phylib API does not have insight into the components of the > PHY it controls: PCS, PMA, PMD. It's all just a monolithic struct phy_device. > > Because there are serial phy_interface_t modes where the MAC also need a > PHY to even connect to the phylib PHY, a problem presented itself: > phylib only has support for a single phy_device. So a new framework > appeared: phylink, which uses the unmodified phylib layer for the > external PHY, but models the MAC-side PHY using a different API. Later > on, that API became the phylink_pcs. > > To muddy the waters, a phylink_pcs structure usually connects to another > local component as described above, like a phylib PHY (on-board or on an > SFP module). But it can also connect directly to a remote system (like a > phy_device would). But the phylink_pcs is always integrated in silicon > with the MAC, and the "media side" of it is a phy_interface_t type, not > an ethtool_link_mode_bit_indices type. > > Having a separate phylink_pcs is what allows us to work around phylib's > limitation of having a single phy_device. The reverse is also true: you > can have a single phylink_pcs, and that belongs to the client MAC driver. > > The other layers (PMA/PMD) of the MAC-side PHY are modeled in the kernel > as a struct phy (https://docs.kernel.org/driver-api/phy/index.html), and > we have the phy_set_mode_ext() API for reconfiguring this layer to a > different mode. Again, this is not applicable for phylib PHYs, which are > monolithic. > > Given the above definitions, what NXP has and drives with pcs-lynx.c is > not a struct phy_device, but a MAC-side PCS represented by a phylink_pcs. > It absolutely does not matter that the register access method for the > PCS is an internal MDIO bus. FWIW, the PMA/PMD layer is at > drivers/phy/freescale/phy-fsl-lynx-28g.c. > > So, if put into the proper context, what Russell is saying is correct, > but I think you need a bit of history to not get even more confused > about why it is the way it is. Thanks Vladimir for the detail information, i just get this message, which is helpful to me.
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c index 37fb033e1c29..f376d794d170 100644 --- a/drivers/net/phy/at803x.c +++ b/drivers/net/phy/at803x.c @@ -176,6 +176,7 @@ #define AT8030_PHY_ID_MASK 0xffffffef #define QCA8081_PHY_ID 0x004dd101 +#define QCA8084_PHY_ID 0x004dd180 #define QCA8327_A_PHY_ID 0x004dd033 #define QCA8327_B_PHY_ID 0x004dd034 @@ -1760,6 +1761,9 @@ static bool qca808x_is_prefer_master(struct phy_device *phydev) static bool qca808x_has_fast_retrain_or_slave_seed(struct phy_device *phydev) { + if (phydev_id_compare(phydev, QCA8084_PHY_ID)) + return false; + return linkmode_test_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT, phydev->supported); } @@ -1824,6 +1828,23 @@ static int qca808x_read_status(struct phy_device *phydev) return ret; if (phydev->link) { + /* There are two PCSs available for QCA8084, which support the + * following interface modes. + * + * 1. PHY_INTERFACE_MODE_10G_QXGMII utilizes PCS1 for all + * available 4 ports, which is for all link speeds. + * + * 2. PHY_INTERFACE_MODE_2500BASEX utilizes PCS0 for the + * fourth port, which is only for the link speed 2500M same + * as QCA8081. + * + * 3. PHY_INTERFACE_MODE_SGMII utilizes PCS0 for the fourth + * port, which is for the link speed 10M, 100M and 1000M same + * as QCA8081. + */ + if (phydev->interface == PHY_INTERFACE_MODE_10G_QXGMII) + return 0; + if (phydev->speed == SPEED_2500) phydev->interface = PHY_INTERFACE_MODE_2500BASEX; else @@ -1958,6 +1979,14 @@ static int qca808x_cable_test_start(struct phy_device *phydev) phy_write_mmd(phydev, MDIO_MMD_PCS, 0x807a, 0xc060); phy_write_mmd(phydev, MDIO_MMD_PCS, 0x807e, 0xb060); + if (phydev_id_compare(phydev, QCA8084_PHY_ID)) { + /* Adjust the positive and negative pulse thereshold of CDT */ + phy_write_mmd(phydev, MDIO_MMD_PCS, 0x8075, 0xa060); + + /* Disable the near echo bypass */ + phy_modify_mmd(phydev, MDIO_MMD_PCS, 0x807f, BIT(15), 0); + } + return 0; } @@ -2227,6 +2256,26 @@ static struct phy_driver at803x_driver[] = { .cable_test_start = qca808x_cable_test_start, .cable_test_get_status = qca808x_cable_test_get_status, .link_change_notify = qca808x_link_change_notify, +}, { + /* Qualcomm QCA8084 */ + PHY_ID_MATCH_MODEL(QCA8084_PHY_ID), + .name = "Qualcomm QCA8084", + .flags = PHY_POLL_CABLE_TEST, + .probe = at803x_probe, + .config_intr = at803x_config_intr, + .handle_interrupt = at803x_handle_interrupt, + .get_tunable = at803x_get_tunable, + .set_tunable = at803x_set_tunable, + .set_wol = at803x_set_wol, + .get_wol = at803x_get_wol, + .get_features = qca808x_get_features, + .config_aneg = at803x_config_aneg, + .suspend = genphy_suspend, + .resume = genphy_resume, + .read_status = qca808x_read_status, + .soft_reset = qca808x_soft_reset, + .cable_test_start = qca808x_cable_test_start, + .cable_test_get_status = qca808x_cable_test_get_status, }, }; module_phy_driver(at803x_driver); @@ -2242,6 +2291,7 @@ static struct mdio_device_id __maybe_unused atheros_tbl[] = { { PHY_ID_MATCH_EXACT(QCA8327_B_PHY_ID) }, { PHY_ID_MATCH_EXACT(QCA9561_PHY_ID) }, { PHY_ID_MATCH_EXACT(QCA8081_PHY_ID) }, + { PHY_ID_MATCH_MODEL(QCA8084_PHY_ID) }, { } };