Message ID | 20240212115043.1725918-1-robimarko@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-61455-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:50ea:b0:106:860b:bbdd with SMTP id r10csp2375682dyd; Mon, 12 Feb 2024 03:51:15 -0800 (PST) X-Google-Smtp-Source: AGHT+IHN8yE0/BhwQdNaO6HaYNkQ9GdPzYpltL0PaFKKRv82SP1SvzdA6M9FnZ6U+L61/q9r00od X-Received: by 2002:a05:6359:2411:b0:178:b93f:f60c with SMTP id ls17-20020a056359241100b00178b93ff60cmr7688049rwb.32.1707738674976; Mon, 12 Feb 2024 03:51:14 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707738674; cv=pass; d=google.com; s=arc-20160816; b=iHkAi8LxSQejfXKKp4CbL9JLC5/H+opqGVbMtYMxgIKUqOObsLVLiSc/8lNCPHworN 5KvJbVy0+BKsoiOhfS803aPMFh5E2Ln/BfxuKplnQaKVG98eFNhdkWh4MnJiazzIFXsl SRh+25hwnFVL5R0pDysVbtTIgCL2/jLuEHfTPs9hd60zpQd4+A4dZGy2b81q5IlZ3diR iPZ323maNfje4iC8iC+lqP78b6CuXVvAkFXjKGi7yWDFR/WiF+RgNEZJNe6DznXBvC/X 47q6PwkXAwWf4PICpImFHOMrp5t8SB5HMsY7cyMLVULxcVqsdL9aXOLh54Aa2Et51hCP yklg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=DI/JPUx6NGwjBeuZnuCsSQdfuZnc/sODY2AjTvUNJeU=; fh=xYdvbtFVZfh7490BEanR+veY7TWgMgf18BhBX+6OjsA=; b=WdW8YyZbccbILAWovV0ZPCRFvUXSAr9mx+ZJGw8rh8G1jlg6JhoyOW+40RbZexjcjy xaxoTn0ST2imgaPKwFXctvnfH0JOZalkCjQEzn3STRc5R5pwSVMemm/z+p4r5DznKPAB ufc7Gi+K+jN1tPsIZTCtPLCKZ3j415eVcxt9tXgfQPN6UjkAHpLFCU8VxbMEqkoR/P+h 23utQrK42ecZyDOyV8q9nAp/oq+QHTO63C+fKVjht66wPyE0wUXcBrSm96ESTIpLmWI/ BKRyheeK6a7oZk8jGR2+j/s1cVUALwJpzQVrVMqX/oaRXy6aOcau6W9lt8m3OatyVRf2 0bqA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=FTLBdJQ2; arc=pass (i=1 spf=pass spfdomain=gmail.com dkim=pass dkdomain=gmail.com dmarc=pass fromdomain=gmail.com); spf=pass (google.com: domain of linux-kernel+bounces-61455-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-61455-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com X-Forwarded-Encrypted: i=2; AJvYcCX0ROrVaQ+kosJVj+/aXc6/rXCTrhKswhZs5zdvke+daYimRwpc+8AyHPe6BxowsfnSVghvcv8GKUtsLBKEfmTyS4el7A== Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id t30-20020a63b25e000000b005d645323583si125317pgo.755.2024.02.12.03.51.14 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Feb 2024 03:51:14 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-61455-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=FTLBdJQ2; arc=pass (i=1 spf=pass spfdomain=gmail.com dkim=pass dkdomain=gmail.com dmarc=pass fromdomain=gmail.com); spf=pass (google.com: domain of linux-kernel+bounces-61455-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-61455-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id B6073283983 for <ouuuleilei@gmail.com>; Mon, 12 Feb 2024 11:51:14 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3B70A39FC6; Mon, 12 Feb 2024 11:50:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="FTLBdJQ2" Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) (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 EB84439AC5; Mon, 12 Feb 2024 11:50:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.53 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707738650; cv=none; b=GkboYvZlip2J9bBuIdIPYqYkoD58BhbP1ohocMF2iqohR58U5cRCxXVZz6Lx69Dioq6QKI1gIbHqEIy8ZqVnG4rRnZbbH+B6C7vfYHD406TdFHJsPjxq5kpBhKyE/gPVY35AQB/YU48qXMyYYZ5C94qg1QTnKYPwVdpHq03V0hI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707738650; c=relaxed/simple; bh=/kq5w1POb6DWCXoFZuLee/5Hf4I/xNQaA8461i2aYSA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=V1bg31JkKIFkvKMqkdpc5g4l15MPJFBRTYTB7kHxunr0DhRYKCowTngf6db3UypbupvdKaJqggY0pJOmMcsSuENO0ku6cT2g7DpnYpB61t3YyJCdszHyadZL/XZ0Pb3mkjditRlweJUFytDUrue2PjLZzzaMX+0UCKoCIaW4JSk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=FTLBdJQ2; arc=none smtp.client-ip=209.85.208.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-56003c97d98so3747899a12.3; Mon, 12 Feb 2024 03:50:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707738647; x=1708343447; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=DI/JPUx6NGwjBeuZnuCsSQdfuZnc/sODY2AjTvUNJeU=; b=FTLBdJQ283KTR3DsSkmPReJMxq+6GmAgDKfzHv58ydao6ChRYDucKmH57R5O6Cf06k fYWex8vEV+Z01Up50kAa1sPXAB/lPo/N0C6GSDItfSqifeIbGq4Vf7U+sCE0FX2e4lJl MZoFoH4U+DA1hhJJWwmqGdsbDKUxrI9FYkwEThX9MQBBVSces5AUDkboQDNL4Ljkst23 QOeL2szXyTTMW/O6lZgGSA2+yGVMY7XP7rzzQpk4S1ilCKyp7KXagtCVy5Rga16+4hEp vDO3QvORc6Km/66mYvobUnezm4VOnUtC4hFEyzu6VdQjubpFWSdYr4Y5bihP9RxdO9XT O2Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707738647; x=1708343447; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DI/JPUx6NGwjBeuZnuCsSQdfuZnc/sODY2AjTvUNJeU=; b=jTQa4tWLjcZoDd0Yz/33y5ONVqPBuIf0v92sRdSjEFYdFU8HaJZf6ODL+E2W9KdDYu lcluKooKDN7RYOcLMMtGwJZpvzxx7qxuChWNfIN9w9XLXiWWVNlN6vt1DCjh6wfuhuV1 XrGJNFcNwQu7MQ1VfFN1bb/wDY48zKG7xMwf/XfCbEufnFFgshbkjthOkCTp+RciUJgJ 16Cg/XsFDgUmkLrkmVtCjlgQxYjwCD81yTAKcgzDbHktYlKO8+AmHGXAtxLqdMPutiTL pJBw23Ua7rNLlp7u/8L+VRF6bBkWiGW+noN14ZIA5L4sjjYsWrmJ9n3iqazqHViS1tJq qB5A== X-Gm-Message-State: AOJu0YxJ8chfxpTBZ6UKU76bh3BTZWi1MT4mjDhtShGrxXK7pIWK0Cfb Qi+kvHK11jFshxqBoc2t5To2H0suvGXEIXPB7y+NEH12hvBrIrpoN/20mkq2bpI= X-Received: by 2002:a17:906:2787:b0:a3c:c451:2115 with SMTP id j7-20020a170906278700b00a3cc4512115mr845655ejc.77.1707738646617; Mon, 12 Feb 2024 03:50:46 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCUvVnYjwl1kXCkY6Q5HCHxosLviHu0mbZd4UfAyKqv/n4THscQ62fBfKS0esaHexyd7rx/jI8u3C4ruKxWli4Q/3iGG+VrFG6IOMgbY4mNC7CJ4YU1vAf9baLjz74PpeNf7ph4jCRpOvOQhGSxDvv5HUOrQGEC6a57CzVLBjACv6guMqWBVuf2SGTE8KqtJBvSDLYKj0mO3Iozednaii92VE5UZmu7C9TwJh5tGJiaE5NwhylMcoOPqtcH41jRzk96pKfZJJr+uQOwmpOSxlFf4cnBrBXfHlUIzmHgX8enw4w0RDuGX0kkGbV8mBD5aBxRg2wAcwrNwvqNVys5J4KR3jlvydQfwBsGwUJAE/Pj8g3UjuGEe6Vf+ICImwdeN+RvHvE03uecQLUG9IFfP4Js3k0TKvz7SjprkDf5Q1D4= Received: from fedora.. (cpe-109-60-83-183.zg3.cable.xnet.hr. [109.60.83.183]) by smtp.googlemail.com with ESMTPSA id n7-20020a170906118700b00a3845a75eb7sm126534eja.189.2024.02.12.03.50.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Feb 2024 03:50:46 -0800 (PST) From: Robert Marko <robimarko@gmail.com> To: andersson@kernel.org, konrad.dybcio@linaro.org, andrew@lunn.ch, hkallweit1@gmail.com, linux@armlinux.org.uk, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, ansuelsmth@gmail.com, linux-arm-msm@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Robert Marko <robimarko@gmail.com> Subject: [PATCH net-next] net: phy: qca807x: move interface mode check to .config_init_once Date: Mon, 12 Feb 2024 12:49:34 +0100 Message-ID: <20240212115043.1725918-1-robimarko@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790693788597819842 X-GMAIL-MSGID: 1790693788597819842 |
Series |
[net-next] net: phy: qca807x: move interface mode check to .config_init_once
|
|
Commit Message
Robert Marko
Feb. 12, 2024, 11:49 a.m. UTC
Currently, we are checking whether the PHY package mode matches the
individual PHY interface modes at PHY package probe time, but at that time
we only know the PHY package mode and not the individual PHY interface
modes as of_get_phy_mode() that populates it will only get called once the
netdev to which PHY-s are attached to is being probed and thus this check
will always fail and return -EINVAL.
So, lets move this check to .config_init_once as at that point individual
PHY interface modes should be populated.
Fixes: d1cb613efbd3 ("net: phy: qcom: add support for QCA807x PHY Family")
Signed-off-by: Robert Marko <robimarko@gmail.com>
---
drivers/net/phy/qcom/qca807x.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
Comments
On Mon, Feb 12, 2024 at 12:49:34PM +0100, Robert Marko wrote: > Currently, we are checking whether the PHY package mode matches the > individual PHY interface modes at PHY package probe time, but at that time > we only know the PHY package mode and not the individual PHY interface > modes as of_get_phy_mode() that populates it will only get called once the > netdev to which PHY-s are attached to is being probed and thus this check > will always fail and return -EINVAL. > > So, lets move this check to .config_init_once as at that point individual > PHY interface modes should be populated. Just for my own understanding, not directly about this patch... priv->package_mode is about PSGMII vs QSGMII for one of the SERDES interfaces? We expect the individual PHYs sharing that interface to also indicate PSGMII or QSGMII? But what about the other SERDES, which can be connected to an SFP cage. You would normally set that to SGMII, or 1000BaseX. When an SFP module is inserted, the correct interface mode is then determined from the contests of the EEPROM and the PCS needs to be reconfigured. So i'm just wondering how this check works in this situation? Andrew
On Mon, 12 Feb 2024 at 15:51, Andrew Lunn <andrew@lunn.ch> wrote: > > On Mon, Feb 12, 2024 at 12:49:34PM +0100, Robert Marko wrote: > > Currently, we are checking whether the PHY package mode matches the > > individual PHY interface modes at PHY package probe time, but at that time > > we only know the PHY package mode and not the individual PHY interface > > modes as of_get_phy_mode() that populates it will only get called once the > > netdev to which PHY-s are attached to is being probed and thus this check > > will always fail and return -EINVAL. > > > > So, lets move this check to .config_init_once as at that point individual > > PHY interface modes should be populated. > > Just for my own understanding, not directly about this patch... > > priv->package_mode is about PSGMII vs QSGMII for one of the SERDES > interfaces? We expect the individual PHYs sharing that interface to > also indicate PSGMII or QSGMII? Yes, that is the idea, all of the individual PHY-s in the package should be indicating the same PHY interface mode. > > But what about the other SERDES, which can be connected to an SFP > cage. You would normally set that to SGMII, or 1000BaseX. When an SFP > module is inserted, the correct interface mode is then determined from > the contests of the EEPROM and the PCS needs to be reconfigured. So > i'm just wondering how this check works in this situation? I just went to retest SFP support and it works as intended, as soon as the SFP is inserted, PHY will get reconfigured to "combo" mode so that fifth PHY can support both fiber (100Base-FX or 1000Base-X) or regular copper connections. So, the check will not interfere with SFP support. Regards, Robert > > Andrew
On Mon, Feb 12, 2024 at 07:09:04PM +0100, Robert Marko wrote: > On Mon, 12 Feb 2024 at 15:51, Andrew Lunn <andrew@lunn.ch> wrote: > > > > On Mon, Feb 12, 2024 at 12:49:34PM +0100, Robert Marko wrote: > > > Currently, we are checking whether the PHY package mode matches the > > > individual PHY interface modes at PHY package probe time, but at that time > > > we only know the PHY package mode and not the individual PHY interface > > > modes as of_get_phy_mode() that populates it will only get called once the > > > netdev to which PHY-s are attached to is being probed and thus this check > > > will always fail and return -EINVAL. > > > > > > So, lets move this check to .config_init_once as at that point individual > > > PHY interface modes should be populated. > > > > Just for my own understanding, not directly about this patch... > > > > priv->package_mode is about PSGMII vs QSGMII for one of the SERDES > > interfaces? We expect the individual PHYs sharing that interface to > > also indicate PSGMII or QSGMII? > > Yes, that is the idea, all of the individual PHY-s in the package > should be indicating > the same PHY interface mode. > > > > > But what about the other SERDES, which can be connected to an SFP > > cage. You would normally set that to SGMII, or 1000BaseX. When an SFP > > module is inserted, the correct interface mode is then determined from > > the contests of the EEPROM and the PCS needs to be reconfigured. So > > i'm just wondering how this check works in this situation? > > I just went to retest SFP support and it works as intended, as soon as the SFP > is inserted, PHY will get reconfigured to "combo" mode so that fifth PHY can > support both fiber (100Base-FX or 1000Base-X) or regular copper connections. > > So, the check will not interfere with SFP support. So for the port with the SFP you also have phy-mode of PSGMII or QSGMII? That then gets changed when the SFP is hot plugged? Andrew
On Mon, 12 Feb 2024 at 20:48, Andrew Lunn <andrew@lunn.ch> wrote: > > On Mon, Feb 12, 2024 at 07:09:04PM +0100, Robert Marko wrote: > > On Mon, 12 Feb 2024 at 15:51, Andrew Lunn <andrew@lunn.ch> wrote: > > > > > > On Mon, Feb 12, 2024 at 12:49:34PM +0100, Robert Marko wrote: > > > > Currently, we are checking whether the PHY package mode matches the > > > > individual PHY interface modes at PHY package probe time, but at that time > > > > we only know the PHY package mode and not the individual PHY interface > > > > modes as of_get_phy_mode() that populates it will only get called once the > > > > netdev to which PHY-s are attached to is being probed and thus this check > > > > will always fail and return -EINVAL. > > > > > > > > So, lets move this check to .config_init_once as at that point individual > > > > PHY interface modes should be populated. > > > > > > Just for my own understanding, not directly about this patch... > > > > > > priv->package_mode is about PSGMII vs QSGMII for one of the SERDES > > > interfaces? We expect the individual PHYs sharing that interface to > > > also indicate PSGMII or QSGMII? > > > > Yes, that is the idea, all of the individual PHY-s in the package > > should be indicating > > the same PHY interface mode. > > > > > > > > But what about the other SERDES, which can be connected to an SFP > > > cage. You would normally set that to SGMII, or 1000BaseX. When an SFP > > > module is inserted, the correct interface mode is then determined from > > > the contests of the EEPROM and the PCS needs to be reconfigured. So > > > i'm just wondering how this check works in this situation? > > > > I just went to retest SFP support and it works as intended, as soon as the SFP > > is inserted, PHY will get reconfigured to "combo" mode so that fifth PHY can > > support both fiber (100Base-FX or 1000Base-X) or regular copper connections. > > > > So, the check will not interfere with SFP support. > > So for the port with the SFP you also have phy-mode of PSGMII or > QSGMII? That then gets changed when the SFP is hot plugged? Yes, that is correct and when SFP is plugged in it will be reconfigured by the driver into combo mode as that port can actually be used for fiber and copper at the same time by changing the priority. Regards, Robert > > Andrew
On Tue, Feb 13, 2024 at 11:16:47AM +0100, Robert Marko wrote: > On Mon, 12 Feb 2024 at 20:48, Andrew Lunn <andrew@lunn.ch> wrote: > > > > On Mon, Feb 12, 2024 at 07:09:04PM +0100, Robert Marko wrote: > > > On Mon, 12 Feb 2024 at 15:51, Andrew Lunn <andrew@lunn.ch> wrote: > > > > > > > > On Mon, Feb 12, 2024 at 12:49:34PM +0100, Robert Marko wrote: > > > > > Currently, we are checking whether the PHY package mode matches the > > > > > individual PHY interface modes at PHY package probe time, but at that time > > > > > we only know the PHY package mode and not the individual PHY interface > > > > > modes as of_get_phy_mode() that populates it will only get called once the > > > > > netdev to which PHY-s are attached to is being probed and thus this check > > > > > will always fail and return -EINVAL. > > > > > > > > > > So, lets move this check to .config_init_once as at that point individual > > > > > PHY interface modes should be populated. > > > > > > > > Just for my own understanding, not directly about this patch... > > > > > > > > priv->package_mode is about PSGMII vs QSGMII for one of the SERDES > > > > interfaces? We expect the individual PHYs sharing that interface to > > > > also indicate PSGMII or QSGMII? > > > > > > Yes, that is the idea, all of the individual PHY-s in the package > > > should be indicating > > > the same PHY interface mode. > > > > > > > > > > > But what about the other SERDES, which can be connected to an SFP > > > > cage. You would normally set that to SGMII, or 1000BaseX. When an SFP > > > > module is inserted, the correct interface mode is then determined from > > > > the contests of the EEPROM and the PCS needs to be reconfigured. So > > > > i'm just wondering how this check works in this situation? > > > > > > I just went to retest SFP support and it works as intended, as soon as the SFP > > > is inserted, PHY will get reconfigured to "combo" mode so that fifth PHY can > > > support both fiber (100Base-FX or 1000Base-X) or regular copper connections. > > > > > > So, the check will not interfere with SFP support. > > > > So for the port with the SFP you also have phy-mode of PSGMII or > > QSGMII? That then gets changed when the SFP is hot plugged? > > Yes, that is correct and when SFP is plugged in it will be reconfigured > by the driver into combo mode as that port can actually be used for fiber and > copper at the same time by changing the priority. > Hi Andrew, just to make sure this doesn't get confused. There is a HW limitation here and it's described in Documentation: - In QSGMII mode the SFP Cage can't be connected or mounted physically as in this mode only 5 copper port can be connected, it would go against the HW design of the chip. In this configuration the first 4 port are qsgmii and the 5th port is sgmii. (we enforce qsgmii on all ports out of simplicity to make sure we have a sane configuration in DT) - In PSGMII mode the 5th port is always a combo port that can either be a copper port or a fiber port (with SFP cage). To set the 5th port to fiber mode, the mode has to be switched but the other 4 port are always copper. Also it's ok to set the initial PSGMII mode to 5 copper port as it will be changed as soon as a SFP cage is connected. (can't happen to have a device with both a copper port and a SFP cage connected to the 5th port, it's one or the other. Again it would go against the HW design. Hope it's clear now why the check was introduced and the HW limitation of it as with the previous message one might think the 5th port is totally separated and can go to his own mode (PSGMII or QSGMII)
> > Yes, that is correct and when SFP is plugged in it will be reconfigured > > by the driver into combo mode as that port can actually be used for fiber and > > copper at the same time by changing the priority. > > > > Hi Andrew, just to make sure this doesn't get confused. > > There is a HW limitation here and it's described in Documentation: > > - In QSGMII mode the SFP Cage can't be connected or mounted physically > as in this mode only 5 copper port can be connected, it would go > against the HW design of the chip. In this configuration the first 4 > port are qsgmii and the 5th port is sgmii. (we enforce qsgmii on all > ports out of simplicity to make sure we have a sane configuration in > DT) > > - In PSGMII mode the 5th port is always a combo port that can either be > a copper port or a fiber port (with SFP cage). To set the 5th port to > fiber mode, the mode has to be switched but the other 4 port are > always copper. > Also it's ok to set the initial PSGMII mode to 5 copper port as it > will be changed as soon as a SFP cage is connected. (can't happen to > have a device with both a copper port and a SFP cage connected to the > 5th port, it's one or the other. Again it would go against the HW > design. > > Hope it's clear now why the check was introduced and the HW limitation > of it as with the previous message one might think the 5th port is > totally separated and can go to his own mode (PSGMII or QSGMII) Thanks for the explanation I'm more used to it being like: ð2 { /* ethernet@34000 */ bm,pool-long = <3>; bm,pool-short = <1>; buffer-manager = <&bm>; managed = "in-band-status"; phys = <&comphy5 1>; phy-mode = "sgmii"; sfp = <&sfp0>; status = "okay"; }; Here phy-mode is set to one of the modes the SFP will use, either sgmii or 1000baseX. But i don't think it matters what value is used. Andrew
On Mon, Feb 12, 2024 at 12:49:34PM +0100, Robert Marko wrote: > Currently, we are checking whether the PHY package mode matches the > individual PHY interface modes at PHY package probe time, but at that time > we only know the PHY package mode and not the individual PHY interface > modes as of_get_phy_mode() that populates it will only get called once the > netdev to which PHY-s are attached to is being probed and thus this check > will always fail and return -EINVAL. > > So, lets move this check to .config_init_once as at that point individual > PHY interface modes should be populated. > > Fixes: d1cb613efbd3 ("net: phy: qcom: add support for QCA807x PHY Family") > Signed-off-by: Robert Marko <robimarko@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Andrew
Hello: This patch was applied to netdev/net-next.git (main) by Paolo Abeni <pabeni@redhat.com>: On Mon, 12 Feb 2024 12:49:34 +0100 you wrote: > Currently, we are checking whether the PHY package mode matches the > individual PHY interface modes at PHY package probe time, but at that time > we only know the PHY package mode and not the individual PHY interface > modes as of_get_phy_mode() that populates it will only get called once the > netdev to which PHY-s are attached to is being probed and thus this check > will always fail and return -EINVAL. > > [...] Here is the summary with links: - [net-next] net: phy: qca807x: move interface mode check to .config_init_once https://git.kernel.org/netdev/net-next/c/3be0d950b628 You are awesome, thank you!
diff --git a/drivers/net/phy/qcom/qca807x.c b/drivers/net/phy/qcom/qca807x.c index 01815f947060..780c28e2e4aa 100644 --- a/drivers/net/phy/qcom/qca807x.c +++ b/drivers/net/phy/qcom/qca807x.c @@ -562,6 +562,11 @@ static int qca807x_phy_package_config_init_once(struct phy_device *phydev) struct qca807x_shared_priv *priv = shared->priv; int val, ret; + /* Make sure PHY follow PHY package mode if enforced */ + if (priv->package_mode != PHY_INTERFACE_MODE_NA && + phydev->interface != priv->package_mode) + return -EINVAL; + phy_lock_mdio_bus(phydev); /* Set correct PHY package mode */ @@ -718,11 +723,6 @@ static int qca807x_probe(struct phy_device *phydev) shared = phydev->shared; shared_priv = shared->priv; - /* Make sure PHY follow PHY package mode if enforced */ - if (shared_priv->package_mode != PHY_INTERFACE_MODE_NA && - phydev->interface != shared_priv->package_mode) - return -EINVAL; - priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); if (!priv) return -ENOMEM;