From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from metis.whiteo.stw.pengutronix.de (metis.whiteo.stw.pengutronix.de [185.203.201.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C67FF3054CD for ; Wed, 20 Aug 2025 12:26:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.203.201.7 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755692796; cv=none; b=GE9oHdP+EXCk6+sdE3IcXShu1KUXOHjcFhENnqdat1HIqxT1v2dRpPbhm+KefQ4M76k79vievnPn6F3Bkg4pFV3jHzDvT6RK41yyWGD6ICwq0VVq8ROM1MW24yjtw5zDa+x78Xt5OYyO4YcZzkMQYwNciWDLihJi5ZVl5kCmn+Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755692796; c=relaxed/simple; bh=ZUckhx0b1FZYrbO+0sEf2kPmwrX8tp3wUpLQSDeGdp8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=E2ZEkW+sN03O6XuJedAMtPWpIBckkdu/wBTFc+l3Vje2gPeuA0bjx9oIUlWIus/do/A9O+BDQuKpipHIYdDizzhqUVJmCU/eHRCsWdwUwE9SwL4dJ8sI10UGfsMYncfYK6ax5uq3rAol+Hg8FYAm+FutEACD45BwBPOul9mEur8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de; spf=pass smtp.mailfrom=pengutronix.de; arc=none smtp.client-ip=185.203.201.7 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pengutronix.de Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1uohtJ-0000bE-Ig; Wed, 20 Aug 2025 14:26:09 +0200 Received: from pty.whiteo.stw.pengutronix.de ([2a0a:edc0:2:b01:1d::c5]) by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uohtH-001FD8-0H; Wed, 20 Aug 2025 14:26:07 +0200 Received: from ore by pty.whiteo.stw.pengutronix.de with local (Exim 4.96) (envelope-from ) id 1uohtG-005wUD-36; Wed, 20 Aug 2025 14:26:06 +0200 Date: Wed, 20 Aug 2025 14:26:06 +0200 From: Oleksij Rempel To: Andrew Lunn Cc: Maxime Chevallier , Jakub Kicinski , "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Donald Hunter , Jonathan Corbet , Heiner Kallweit , Russell King , Kory Maincent , Nishanth Menon , kernel@pengutronix.de, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, UNGLinuxDriver@microchip.com, linux-doc@vger.kernel.org, Michal Kubecek , Roan van Dijk Subject: Re: [PATCH net-next v2 5/5] net: phy: dp83td510: add MSE interface support for 10BASE-T1L Message-ID: References: <20250815063509.743796-1-o.rempel@pengutronix.de> <20250815063509.743796-6-o.rempel@pengutronix.de> <1df-68a2e100-1-20bf1840@149731379> <94745663-b68c-4a4c-95d8-36933c305e34@lunn.ch> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <94745663-b68c-4a4c-95d8-36933c305e34@lunn.ch> X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-Accept-Language: de,en X-Accept-Content-Type: text/plain X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: ore@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org On Wed, Aug 20, 2025 at 02:11:57PM +0200, Andrew Lunn wrote: > > > The doc in patch 1 says : > > > > > > > + * Link-wide mode: > > > > + * - Some PHYs only expose a link-wide aggregate MSE, or cannot map their > > > > + * measurement to a specific channel/pair (e.g. 100BASE-TX when MDI/MDI-X > > > > + * resolution is unknown). In that case, callers must use the LINK selector. > > > > > > The way I understand that is that PHYs will report either channel-specific values or > > > link-wide values. Is that correct or are both valid ? In BaseT1 this is the same thing, > > > but maybe for consistency, we should report either channel values or link-wide values ? > > > > for 100Base-T1 the LINK and channel-A selectors are effectively the > > same, since the PHY only has a single channel. In this case both are > > valid, and the driver will return the same answer for either request. > > > > I decided to expose both for consistency: > > - on one side, the driver already reports pair_A information for the > > cable test, so it makes sense to allow channel-A here as well; > > - on the other side, if a caller such as a generic link-status/health > > request asks for LINK, we can also provide that without special > > casing. > > > > So the driver just answers what it can. For this PHY, LINK and > > channel-A map to the same hardware register, and all other selectors > > return -EOPNOTSUPP. > > The document you referenced explicitly says it is for 100BASE-T1. Are > there other Open Alliance documents which extend the concept to -T2 > and -T4 links? Do you have access to -T2 or -T4 PHYs which implement > the concept for multiple pairs? So far I know, following T2/T4 PHYs support MSE: LAN8830, KSZ9131, LAN8831, LAN8840, LAN8841 DP83826*, DP83640, DP83867*, DP83869HM I have access at least to LAN8841. > I think it is good you are thinking about the API, how it could work > with -T2 and -T4, but do we need this complexity now? Hm.. I just fear to make same mistake as I did with SQI. So, I analyzed as many datasheets as possible. -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |