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 0C42128E0F; Tue, 29 Apr 2025 12:08:21 +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=1745928503; cv=none; b=swMkRb/E212yZPR2fMEa210wBGCpkrNjcFOn90hMP6Jw8ZuzlCs5a/nzAf42Ehs4jph2go0gMKbTvkF/ITL+NIwSMUClRwLiugGhywxwuU8SDR0az/B755DePBFpEtM61yH84oBC2xO7MQR6NZ4XOKGsyKZ5cjjz/d3p6/KKu4I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745928503; c=relaxed/simple; bh=u2KDSl6Z8S8d/VXvdkeAcfQ+QeA7wKWNNDMj2h67vhA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KCtt/FyH3E8AYYyE2qvcPfGt9Wf/7rNXboaupqp5kW2kcFJIovij0Qsaggpwp/eH6H0tXHVqg9E6kzErjvkohGF/qQ0qka4Xjz8aHOmdxjQ1nTjJDI5AsL0xzTReci1VbqNtcTEQlfkVpVtz0+wbLNBPj3cd3ESw/t3UDCm+1rE= 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=SkZtFKRB; 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="SkZtFKRB" 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=KBTM9WY09lm/gGdZhulr7/dP5G3uqnfHYWiy8iUJ1N4=; b=SkZtFKRBDYSjtCqVbzOhcQEuRj DWyy1aTiVIPrrCWaBx6JUhx9WKbn3kEKxrlq7I9x/KVZ1HuLvhkN1sL/+Z0ziDpGobC1e/avHvFAC psMCCdKOBLmsghcs3mywZeA3U6QJA7FBD12XTQa0tvtrNQ3osLdKcoOXs9/Fv47Zw9+E=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1u9jkn-00Avy8-8E; Tue, 29 Apr 2025 14:08:01 +0200 Date: Tue, 29 Apr 2025 14:08:01 +0200 From: Andrew Lunn To: Matthias Schiffer Cc: "Russell King (Oracle)" , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Andy Whitcroft , Dwaipayan Ray , Lukas Bulwahn , Joe Perches , Jonathan Corbet , Nishanth Menon , Vignesh Raghavendra , Siddharth Vadapalli , Roger Quadros , Tero Kristo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux@ew.tq-group.com Subject: Re: [PATCH net-next 1/4] dt-bindings: net: ethernet-controller: update descriptions of RGMII modes Message-ID: References: <218a27ae2b2ef2db53fdb3573b58229659db65f9.1744710099.git.matthias.schiffer@ew.tq-group.com> <9b9fc5d0-e973-4f4f-8dd5-d3896bf29093@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=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Apr 29, 2025 at 09:24:49AM +0200, Matthias Schiffer wrote: > On Mon, 2025-04-28 at 16:08 +0200, Andrew Lunn wrote: > > > > > > However, with the yaml stuff, if that is basically becoming "DT > > > > specification" then it needs to be clearly defined what each value > > > > actually means for the system, and not this vague airy-fairy thing > > > > we have now. > > > > > > > I agree with Russell that it seems preferable to make it unambiguous whether > > > delays are added on the MAC or PHY side, in particular for fine-tuning. If > > > anything is left to the implementation, we should make the range of acceptable > > > driver behavior very clear in the documentation. > > > > I think we should try the "Informative" route first, see what the DT > > Maintainers think when we describe in detail how Linux interprets > > these values. > > Oh, we should not be Linux-specific. We should describe in detail how *any OS* > must interpret values. There is two things here. One is related to delays on the PCB. Those are OS agnostic and clearly you are describing hardware. But once you get to implementing the delay in the MAC or the PHY, it is policy if the PHY does it, or the MAC does it. Different OSes can have different policy. We cannot force other OSes to do the same as Linux. I drafted some text last night. I need to review it because i often make typos, and then i will post it. Andrew