From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) (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 AB83B30DD25; Thu, 26 Feb 2026 20:45:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=78.32.30.218 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772138711; cv=none; b=jxIw1VfnDcfCbwMrwrkTDIojEhiuPHsHduqbo5OOwd5By9Drmrxe49nbHPgN+tbT5earnfvh0QSXwqlvg7b8pYPjyxQquzCz0MItXUvJ6iqmT6mzu1JO2anYoL4BxjOGhpHwHYIzoQhm9fuGoQWKYhxldWxzznZC0+Z0CJweqW0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772138711; c=relaxed/simple; bh=mIqMdrRwANI9MqmAL5m1Ir5mAyYzwv3j8dxD7o48Dtw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=O5uKWtnz8tYVjGfezzrjYPOAZfC7XRlh5qrY0mN2ZHbhAZZ5iDBg5PIXW5fgd23jhiXie2QbJ3sliXnOsxM3nNUV1rvnzqLxpQwlN0baVrmuZ0rszKvaFLQpkqxkQQxm71TuzxueMXGZdQx45b4KJoexOosU4xd21+EdmNLyiaM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk; spf=none smtp.mailfrom=armlinux.org.uk; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b=y/AxUqks; arc=none smtp.client-ip=78.32.30.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="y/AxUqks" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ogPD/lXZWLTreSJKiI+SxSAF1QGabbqMCr+KWW3Nhyw=; b=y/AxUqksZk23ZyoQ20SEZ7Sszj bR7P9FfMvHMtPGWOjt2L33faE3nNRhxIAAlZ/oD6Kz/yS5REoXNSZyWiKUr3iJxjeiMgYnuQ/Poyc npBcqj/t37SvY3nHdwIwtO3wiyrBIMClh24wThYj0/SCKqzeKCWVWK1ll4m6dDD+cJfEXaTLW8SI8 EwUF0jXHqviiwv8AZy6QHR5Qmnsje/nh9Qhzk0BPtNji+C99vEDYg+xr9TW7YcWb3by/8AfKDgb5u Gch3ri3t+rB2L+yS9kQYrMw3l/7fvfj5aQPRuRdcqY12NvLVBXkbQGkTRcBlkHRrxCiWJimOrKP8D XSMb1ekQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:41126) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vviEC-000000008PR-37sB; Thu, 26 Feb 2026 20:44:56 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.98.2) (envelope-from ) id 1vviE9-000000002MW-3D5P; Thu, 26 Feb 2026 20:44:53 +0000 Date: Thu, 26 Feb 2026 20:44:53 +0000 From: "Russell King (Oracle)" To: Conor Dooley Cc: =?iso-8859-1?Q?Th=E9o?= Lebrun , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Nicolas Ferre , Claudiu Beznea , netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, =?iso-8859-1?Q?Beno=EEt?= Monin , =?iso-8859-1?Q?Gr=E9gory?= Clement , Maxime Chevallier , Tawfik Bayouk , Thomas Petazzoni , Vladimir Kondratiev Subject: Re: [PATCH net-next v3 5/5] net: macb: Add "mobileye,eyeq5-gem" compatible Message-ID: References: <20251023-macb-eyeq5-v3-0-af509422c204@bootlin.com> <20251023-macb-eyeq5-v3-5-af509422c204@bootlin.com> <20260226-folic-excitable-82eff83a125a@spud> <20260226-perennial-sanctity-25c6adae5ec0@spud> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260226-perennial-sanctity-25c6adae5ec0@spud> Sender: Russell King (Oracle) On Thu, Feb 26, 2026 at 08:20:41PM +0000, Conor Dooley wrote: > On Thu, Feb 26, 2026 at 07:24:47PM +0000, Russell King (Oracle) wrote: > > On Thu, Feb 26, 2026 at 10:46:24AM +0000, Conor Dooley wrote: > > > On Thu, Oct 23, 2025 at 06:22:55PM +0200, Théo Lebrun wrote: > > > > Add support for the two GEM instances inside Mobileye EyeQ5 SoCs, using > > > > compatible "mobileye,eyeq5-gem". With it, add a custom init sequence > > > > that must grab a generic PHY and initialise it. > > > > > > > > We use bp->phy in both RGMII and SGMII cases. Tell our mode by adding a > > > > phy_set_mode_ext() during macb_open(), before phy_power_on(). We are > > > > the first users of bp->phy that use it in non-SGMII cases. > > > > > > > > The phy_set_mode_ext() call is made unconditionally. It cannot cause > > > > issues on platforms where !bp->phy or !bp->phy->ops->set_mode as, in > > > > those cases, the call is a no-op (returning zero). From reading > > > > upstream DTS, we can figure out that no platform has a bp->phy and a > > > > PHY driver that has a .set_mode() implementation: > > > > - cdns,zynqmp-gem: no DTS upstream. > > > > - microchip,mpfs-macb: microchip/mpfs.dtsi, &mac0..1, no PHY attached. > > > > - xlnx,versal-gem: xilinx/versal-net.dtsi, &gem0..1, no PHY attached. > > > > - xlnx,zynqmp-gem: xilinx/zynqmp.dtsi, &gem0..3, PHY attached to > > > > drivers/phy/xilinx/phy-zynqmp.c which has no .set_mode(). > > > > > > Ran into this patch while looking at other stuff. Theo could you explain > > > this analysis to someone not really au fait with phys? Looking at > > > soc.dtsi files won't show you phys, since that's a board level decision, > > > but you have found one for the zynqmp-gem so I guess that's just the way > > > you presented the data? > > > mpfs definitely has phys attached, so is you not finding one for it but > > > finding for zynqmp, an indication that you were only looking for rgmii > > > phys? Also, is the analysis of the connected phy driver accurate for > > > zynmqmp? > > > zynqmp-zc1751-xm018-dc4.dts seems to have 4 ethernet phys: > > > ethernet_phy0: ethernet-phy@0 { /* Marvell 88e1512 */ > > > reg = <0>; > > > }; > > > ethernet_phy7: ethernet-phy@7 { /* Vitesse VSC8211 */ > > > reg = <7>; > > > }; > > > ethernet_phy3: ethernet-phy@3 { /* Realtek RTL8211DN */ > > > reg = <3>; > > > }; > > > ethernet_phy8: ethernet-phy@8 { /* Vitesse VSC8211 */ > > > reg = <8>; > > > }; > > > > Ethernet PHYs (drivers/net/phy/) are different from generic PHYs > > (drivers/phy/). Ethernet PHYs are completely different beast with a > > completely separate subsystem, which doesn't have a "set_mode" method. > > > > Théo is referring to generic PHYs not Ethernet PHYs. > > Right, that's pretty much what I figured and cos of that the patch > itself seemed like it was fine to me. It is the analysis of users in > devicetrees that I don't understand - the "no PHY attached" bits > seemed to me like they should be saying "ethernet-only PHY attached, so > no .set_mode()". Ultimately, I think it makes no difference to the patch > itself, I just wanted to understand the commit message. I think you're still thinking that ethernet PHYs and generic PHYs are the same, but only differ in e.g. whether .set_mode() is populated. This is completely wrong. Ethernet PHYs are _completely_ separate from Generic PHYs. Forget the "PHY" bit, that's totally irrelevant that they happen to be called the same. The two classes share _no_ common infrastructure in the kernel. Ethernet PHYs can't have phy_set_mode_ext() called on them, because ethernet PHYs have no "struct phy" associated with them. They also can't have phy_power_on() either for the same reason, nor any of the other generic PHY API calls. Ethernet PHYs aren't a sub-class of generic PHYs. As I said, Ethernet PHYs and generic PHYs are two entirely separate and different subsystems with no commonality. So... the commit message states "generic PHY". It states the generic PHY API calls of phy_set_mode_ext() and phy_power_up(). From that we deduce that bp->phy is a generic PHY. Thus, the commit message is talking about generic PHYs not ethernet PHYs. Ethernet PHYs are described in Ethernet controller DT using the "phy-handle" property (and previously "phy" or "phy-device" Generic PHYs are described using the "phys" property. The presence of an ethernet-phy node in DT does not automatically associate that device with anything - it has to be referenced by a "phy-handle" property to connect it to an Ethernet controller. However, as I've been trying to point out, as this commit is about generic PHYs, Ethernet PHYs are just not relevant to this commit. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!