From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) (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 C80231E5B95; Thu, 5 Jun 2025 13:20:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=156.67.10.101 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749129661; cv=none; b=lsFTcGBbeXZcfF8tcyQZp3qS2f1H2nFY0GTBc7qkjCZxI7CEmHNYmy62VesA46WPtKorGTD6YOhMcki3AIjQmR0mFdCl90Jv4pSa97mIafmBsvBNlOtuaQZTHwHq3VPdejjc3xe4nNbyVmifQMj8MYgjeZCoZvVoMscV4oA2/aU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749129661; c=relaxed/simple; bh=IbVjDlJ1LhjKgB3WqYIBNmH2O1Kjjxb8PtBFxfYMhYM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mRizQXJhh9+luT5fsiOxSpGNZIoJP9iBDPByn8iKqhfGXw1wPBSmcxGXanoIa5IuU/XmD33ZVg/ly+HVp64WHbep6kGC+RXZVe8xCQq8PVFlsGAZx3TsJ7AGtTX1PBlCoC0Qgzwar7EfSa2bEmkqFcUlCVZqDENrYBhN0POE1xo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lunn.ch; spf=pass smtp.mailfrom=lunn.ch; dkim=pass (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b=DWO8+mjR; arc=none smtp.client-ip=156.67.10.101 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lunn.ch Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lunn.ch Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="DWO8+mjR" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=4Gx+44VNAwh2nJ7uA+08Jgl1iBxYZsQ6aOzwSW1WEA0=; b=DWO8+mjRZ/4bKNTzzBrVD7UrHe xCFH6vd6BJF/G33XVCTybt05IuKx97iMEzGm1kZ14NLJJ22ap9H8IIzdC+QqblOp1AntUpFarqMii cDtE78R1CeYPneuS3hRjSaUXMcOd3C5qtvM8quWAfO/1j5QvzX5tPG34djXX9aKMF+hE=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1uNAWN-00ElxD-7O; Thu, 05 Jun 2025 15:20:39 +0200 Date: Thu, 5 Jun 2025 15:20:39 +0200 From: Andrew Lunn To: "Russell King (Oracle)" Cc: Icenowy Zheng , Rob Herring , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Krzysztof Kozlowski , Conor Dooley , Chaoyi Chen , Matthias Schiffer , Heiner Kallweit , netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net v2] dt-bindings: net: ethernet-controller: Add informative text about RGMII delays Message-ID: References: <20250430-v6-15-rc3-net-rgmii-delays-v2-1-099ae651d5e5@lunn.ch> <2e42f2f7985fb036bec6ab085432a49961c8dc42.camel@icenowy.me> 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=us-ascii Content-Disposition: inline In-Reply-To: > > > If you want the kernel to not touch the PHY, use > > > > > > phy-mode = 'internal' > > > > This sounds weird, and may introduce side effect on the MAC side. > > > > Well we might need to allow PHY to have phy-mode property in addition > > to MAC, in this case MAC phy-mode='rgmii*' and PHY phy-mode='internal' > > might work? > > I'm not convinced that adding more possibilities to the problem (i.o.w. > the idea that phy=mode = "internal" can be used to avoid the delays > being messed with) is a good idea - not at this point, because as you > point out MACs (and PHYs) won't know that they need to be configured > for RGMII mode. "internal" doesn't state this, and if we do start doing > this, we'll end up with "internal" selecting RGMII mode which may work > for some platforms but not all. > > So, IMHO this is a bad idea. I agree, and if actually see a MAC/PHY pair doing this, i will ask why. Using "internal" like is currently mostly hypothetical, i don't actually know of any real users. Those DT blobs which do use "internal" actually are internal interfaces within a SoC and it is some vendor proprietary interface which does not need any configuration. That is the original meaning for "internal", but it has been noticed it can be used to side step RGMII delay configuration. It _might_ play a role when developers decide to clean up a mess with RGMII delays, and decide to just go with the strapping resistors rather than try to figure out what is actually happening vs what DT says should be happening, and issue warning the DT blob is out of date. But still, i would consider "internal" a lazy hack, not a proper fix. Andrew