[net-next,1/3] dt-bindings: net: dp83822: support configuring RMII master/slave mode
Message ID | 20240222103117.526955-2-jeremie.dautheribes@bootlin.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-76337-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:aa16:b0:108:e6aa:91d0 with SMTP id by22csp161229dyb; Thu, 22 Feb 2024 02:32:16 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXsIStfx0yqPTgpgWS9xMuF7cbYM2dBT+jVEErJIe+6c2SJPi1iNwruEKLpPqL+KqqkVdF5GiczW5s374+eYdEyGo8tsg== X-Google-Smtp-Source: AGHT+IGmXWyo8HF5w6bWpmzTSVOn0fyAVZnZ7CyZrkLJAN3GE4v5mFQzjLJy7Q60aB4z5soAdwJB X-Received: by 2002:a05:6102:2150:b0:470:3aae:7bfc with SMTP id h16-20020a056102215000b004703aae7bfcmr11657529vsg.7.1708597936652; Thu, 22 Feb 2024 02:32:16 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708597936; cv=pass; d=google.com; s=arc-20160816; b=rMboyo64ngq66HWo8OT/MSjbRTpRcONZmBegsdAvANkYhROgALE7jtoNRznBIA2E+V niLZ7efkOIJ4NgMG1NhmaQfLeMrcqzmSNKF7KiLZtaYZ85u4gLgMvnW+96gWUoWzO6FT Z1S9VvQcdTkC7iuDRCxn5W/aL4gvbzvYGZcHSiie21x7u9Rmm9ob78FHiKTA47k6/hj8 MAuSBz4jqatSuSd2mcsqVZpq4LyFb0NGLeJmps7vKPD7/Ztb1tRaVpv1DzsZ6wfqRrzm 5FwfsXHIKt2acm6LgsZYNU9cqQYzukybXSSjFvxHrvSy8gPKv3qip2akgs5Zpei0UjJX eX9g== 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:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=TZ0cUDvYq4R1bU50dHJq2WkbKtaTugSYh0eL5IQfQUI=; fh=NV4JY3TRCs9o+gW717PVoUKK/H/wDO8M32W8z62HLwY=; b=Po3sAxwaWx25uB0nnIBCDIVPsak1p2aWkPNIiG5eeGIiIDNeMIy2M/8A0jPk7FgP+L 6tar/OM4jPARf2pQkHqObNsf8qWBhP7RcMf5SVAOCQyOCLtyIeY6ebdIfXY+pTgkgYmp zCyfXTVtVThY/FyPg3Rr5PBoT3DHMjfdEiOOSm6rBujyP1y6f+Uo0ECOv5z9KlLvL5fx ukUK5tUJ6nDr9F/IenipqVrQMrKpP49ZQ6nz+ezMJcM6wfMNHUoc48Acm65Z3YSp4Wt/ drZqGgYRejYggq2VRT7ZfHJtYqBO4aI/gq0raQ0KQRsKrB9LiVITu78LQT6CNpyRbhFs /RIw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=Y4WfRmy9; arc=pass (i=1 spf=pass spfdomain=bootlin.com dkim=pass dkdomain=bootlin.com dmarc=pass fromdomain=bootlin.com); spf=pass (google.com: domain of linux-kernel+bounces-76337-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-76337-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id g12-20020ac870cc000000b0042e539209f7si380665qtp.53.2024.02.22.02.32.16 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Feb 2024 02:32:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-76337-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=Y4WfRmy9; arc=pass (i=1 spf=pass spfdomain=bootlin.com dkim=pass dkdomain=bootlin.com dmarc=pass fromdomain=bootlin.com); spf=pass (google.com: domain of linux-kernel+bounces-76337-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-76337-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.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 ny.mirrors.kernel.org (Postfix) with ESMTPS id 6F0AF1C212CD for <ouuuleilei@gmail.com>; Thu, 22 Feb 2024 10:32:16 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 54EF144393; Thu, 22 Feb 2024 10:31:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="Y4WfRmy9" Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) (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 B71A01E53A; Thu, 22 Feb 2024 10:31:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.70.183.199 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708597889; cv=none; b=jvlomQVbJzZwxpwMwP5/BKNSHWP/0PXFtkVmrg9AoLelEgU4mKkTNroU66iQSIPO07Dr9ZC9q/SgOqTnpFpS/ARFpNoKjT+pK+/u28UKYMLgtwdOZuaBn6yFAR6Y2eX/yz1eEWa6bIUGXQcTZKwuDIpXljyPK6f3XSdGyMHgGoE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708597889; c=relaxed/simple; bh=Z8S1pm3sZXOEcha/HzGW8TfXPCgUETag5hRGfbJIfdM=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=LaC+YB8r0bOz4BDi6oEnIRErUCh2i9/pbb4kMuDYpTmMrHXDhRCuOB7EQSK3thDZauvjg9AdZdyhEaU7XVpxlIcUhiMWsoXzmGDeHN9MJ7yMShJHihgXenb5RyLnmEMhtwdvkEGwzshvT0n0o+lXBHV4nJXiaKwOHE+QKqx/zVM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=Y4WfRmy9; arc=none smtp.client-ip=217.70.183.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Received: by mail.gandi.net (Postfix) with ESMTPSA id 3C12BFF816; Thu, 22 Feb 2024 10:31:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1708597886; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TZ0cUDvYq4R1bU50dHJq2WkbKtaTugSYh0eL5IQfQUI=; b=Y4WfRmy9vBrtrQp2BWz0JcEKr4TgGLE8PZOZ9WcbX+h0FH+mND7t6Ab528pxfQx5M9zXfP PV+dqhWBuU6VzUo0E5NH4Dea3Itz47NNig+6jnL0a+FONsJmLh7JKjXrr9jZaSfZ/ouLgH MDLzfmOJzceQgG/hdXVVReh6pUuSrxK77hVeLtsJFN/2NGLJIMmeeV1oByhcupb3jGifQB ZW9MuEmJEBMF/HrbDBM85PN4vVSZWxigX2dLUTgrGkHUbOEea4+mPBYIUqdeZ5e9RGMNo6 sFCGh1YNNwOZUEwaytp/p/g2TOfgXb8R3hBxz5qIo+vPooqqgB/2Nts/HW24Kw== From: =?utf-8?b?SsOpcsOpbWllIERhdXRoZXJpYmVz?= <jeremie.dautheribes@bootlin.com> To: "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Andrew Lunn <andrew@lunn.ch>, Heiner Kallweit <hkallweit1@gmail.com>, Russell King <linux@armlinux.org.uk>, Andrew Davis <afd@ti.com> Cc: netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Petazzoni <thomas.petazzoni@bootlin.com>, =?utf-8?q?Miqu=C3=A8l_Rayn?= =?utf-8?q?al?= <miquel.raynal@bootlin.com>, Yen-Mei Goh <yen-mei.goh@keysight.com>, Maxime Chevallier <maxime.chevallier@bootlin.com>, =?utf-8?b?SsOpcsOpbWll?= =?utf-8?b?IERhdXRoZXJpYmVz?= <jeremie.dautheribes@bootlin.com> Subject: [PATCH net-next 1/3] dt-bindings: net: dp83822: support configuring RMII master/slave mode Date: Thu, 22 Feb 2024 11:31:15 +0100 Message-Id: <20240222103117.526955-2-jeremie.dautheribes@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240222103117.526955-1-jeremie.dautheribes@bootlin.com> References: <20240222103117.526955-1-jeremie.dautheribes@bootlin.com> 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-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-GND-Sasl: jeremie.dautheribes@bootlin.com X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791594789711273182 X-GMAIL-MSGID: 1791594789711273182 |
Series |
Add support for TI DP83826 configuration
|
|
Commit Message
Jérémie Dautheribes
Feb. 22, 2024, 10:31 a.m. UTC
Add property ti,rmii-mode to support selecting the RMII operation mode
between:
- master mode (PHY operates from a 25MHz clock reference)
- slave mode (PHY operates from a 50MHz clock reference)
If not set, the operation mode is configured by hardware straps.
Signed-off-by: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
---
.../devicetree/bindings/net/ti,dp83822.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
Comments
On 22/02/2024 11:31, Jérémie Dautheribes wrote: > Add property ti,rmii-mode to support selecting the RMII operation mode > between: > - master mode (PHY operates from a 25MHz clock reference) > - slave mode (PHY operates from a 50MHz clock reference) > > If not set, the operation mode is configured by hardware straps. > > Signed-off-by: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com> > --- Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof
On Thu, Feb 22, 2024 at 11:31:15AM +0100, Jérémie Dautheribes wrote: > Add property ti,rmii-mode to support selecting the RMII operation mode > between: > - master mode (PHY operates from a 25MHz clock reference) > - slave mode (PHY operates from a 50MHz clock reference) > > If not set, the operation mode is configured by hardware straps. > > Signed-off-by: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com> > --- > .../devicetree/bindings/net/ti,dp83822.yaml | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/ti,dp83822.yaml b/Documentation/devicetree/bindings/net/ti,dp83822.yaml > index 8f4350be689c..8f23254c0458 100644 > --- a/Documentation/devicetree/bindings/net/ti,dp83822.yaml > +++ b/Documentation/devicetree/bindings/net/ti,dp83822.yaml > @@ -80,6 +80,22 @@ properties: > 10625, 11250, 11875, 12500, 13125, 13750, 14375, 15000] > default: 10000 > > + ti,rmii-mode: > + description: | > + If present, select the RMII operation mode. Two modes are > + available: > + - RMII master, where the PHY operates from a 25MHz clock reference, > + provided by a crystal or a CMOS-level oscillator > + - RMII slave, where the PHY operates from a 50MHz clock reference, > + provided by a CMOS-level oscillator What has master and slave got to do with this? Sometimes, the MAC provides a clock to the PHY, and all data transfer over the RMII bus is timed by that. Sometimes, the PHY provides a clock to the MAC, and all data transfer over the RMII bus is timed by that. Here there is a clear master/slave relationship, who is providing the clock, who is consuming the clock. However, what you describe does not fit that. Maybe look at other PHY bindings, and copy what they do for clocks. Andrew
Hi Andrew, On 26/02/2024 16:28, Andrew Lunn wrote: > On Thu, Feb 22, 2024 at 11:31:15AM +0100, Jérémie Dautheribes wrote: >> Add property ti,rmii-mode to support selecting the RMII operation mode >> between: >> - master mode (PHY operates from a 25MHz clock reference) >> - slave mode (PHY operates from a 50MHz clock reference) >> >> If not set, the operation mode is configured by hardware straps. >> >> Signed-off-by: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com> >> --- >> .../devicetree/bindings/net/ti,dp83822.yaml | 16 ++++++++++++++++ >> 1 file changed, 16 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/net/ti,dp83822.yaml b/Documentation/devicetree/bindings/net/ti,dp83822.yaml >> index 8f4350be689c..8f23254c0458 100644 >> --- a/Documentation/devicetree/bindings/net/ti,dp83822.yaml >> +++ b/Documentation/devicetree/bindings/net/ti,dp83822.yaml >> @@ -80,6 +80,22 @@ properties: >> 10625, 11250, 11875, 12500, 13125, 13750, 14375, 15000] >> default: 10000 >> >> + ti,rmii-mode: >> + description: | >> + If present, select the RMII operation mode. Two modes are >> + available: >> + - RMII master, where the PHY operates from a 25MHz clock reference, >> + provided by a crystal or a CMOS-level oscillator >> + - RMII slave, where the PHY operates from a 50MHz clock reference, >> + provided by a CMOS-level oscillator > > What has master and slave got to do with this? > > Sometimes, the MAC provides a clock to the PHY, and all data transfer > over the RMII bus is timed by that. > > Sometimes, the PHY provides a clock to the MAC, and all data transfer > over the RMII bus is timed by that. > > Here there is a clear master/slave relationship, who is providing the > clock, who is consuming the clock. However, what you describe does not > fit that. Maybe look at other PHY bindings, and copy what they do for > clocks. In fact, I hesitated a lot before choosing this master/slave designation because of the same reasoning as you. But the TI DP83826 datasheet [1] uses this name for two orthogonal yet connected meanings, here's a copy of the corresponding § (in section 9.3.10): "The DP83826 offers two types of RMII operations: RMII Slave and RMII Master. In RMII Master operation, the DP83826 operates from either a 25-MHz CMOS-level oscillator connected to XI pin, a 25-MHz crystal connected across XI and XO pins. A 50-MHz output clock referenced from DP83826 can be connected to the MAC. In RMII Slave operation, the DP83826 operates from a 50-MHz CMOS-level oscillator connected to the XI pin and shares the same clock as the MAC. Alternatively, in RMII slave mode, the PHY can operate from a 50-MHz clock provided by the Host MAC." So it seems that in some cases this also fits the master/slave relationship you describe. That said, would you like me to include this description (or some parts) in the binding in addition to what I've already written? Or would you prefer me to use a more meaningful property name? BTW, this series has already been merged into the net-next tree, I'm not sure what procedure to follow in such cases. Best regards, Jérémie [1] https://www.ti.com/lit/ds/symlink/dp83826i.pdf?ts=1708075771406&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FDP83826I
> > > --- a/Documentation/devicetree/bindings/net/ti,dp83822.yaml > > > +++ b/Documentation/devicetree/bindings/net/ti,dp83822.yaml > > > @@ -80,6 +80,22 @@ properties: > > > 10625, 11250, 11875, 12500, 13125, 13750, 14375, 15000] > > > default: 10000 > > > + ti,rmii-mode: > > > + description: | > > > + If present, select the RMII operation mode. Two modes are > > > + available: > > > + - RMII master, where the PHY operates from a 25MHz clock reference, > > > + provided by a crystal or a CMOS-level oscillator > > > + - RMII slave, where the PHY operates from a 50MHz clock reference, > > > + provided by a CMOS-level oscillator > > > > What has master and slave got to do with this? > > > > Sometimes, the MAC provides a clock to the PHY, and all data transfer > > over the RMII bus is timed by that. > > > > Sometimes, the PHY provides a clock to the MAC, and all data transfer > > over the RMII bus is timed by that. > > > > Here there is a clear master/slave relationship, who is providing the > > clock, who is consuming the clock. However, what you describe does not > > fit that. Maybe look at other PHY bindings, and copy what they do for > > clocks. > > In fact, I hesitated a lot before choosing this master/slave designation > because of the same reasoning as you. But the TI DP83826 datasheet [1] uses > this name for two orthogonal yet connected meanings, here's a copy of the > corresponding § (in section 9.3.10): > > "The DP83826 offers two types of RMII operations: RMII Slave and RMII > Master. In RMII Master operation, the DP83826 operates from either a 25-MHz > CMOS-level oscillator connected to XI pin, a 25-MHz crystal connected across > XI and XO pins. A 50-MHz output clock referenced from DP83826 can be > connected to the MAC. In RMII Slave operation, the DP83826 operates from a > 50-MHz CMOS-level oscillator connected to the XI pin and shares the same > clock as the MAC. Alternatively, in RMII slave mode, the PHY can operate > from a 50-MHz clock provided by the Host MAC." > > So it seems that in some cases this also fits the master/slave relationship > you describe. We are normally interested in this 50Mhz reference clock. So i would drop all references to 25Mhz. It is not relevant to the binding, since it is nothing to do with connecting the PHY to the MAC, and it has a fixed value. So you can simplify this down to: RMII Master: Outputs a 50Mhz Reference clock which can be connected to the MAC. RMII Slave: Expects a 50MHz Reference clock input, shared with the MAC. > That said, would you like me to include this description (or some parts) in > the binding in addition to what I've already written? Or would you prefer me > to use a more meaningful property name? We don't really have any vendor agnostic consistent naming. dp83867 and dp83869 seems to call this ti,clk-output-sel. Since this is another dp83xxx device, it would be nice if there was consistency between all these TI devices. So could you check if the concept is the same, and if so, change dp83826 to follow what other TI devices do. > BTW, this series has already been merged into the net-next tree, I'm not > sure what procedure to follow in such cases. KAPI don't become fixed until published as a release kernel. We can rework bindings until then. So just submit patches on top of what is already in net-next. Andrew
Hi Andrew, On 29/02/2024 22:23, Andrew Lunn wrote: >>>> --- a/Documentation/devicetree/bindings/net/ti,dp83822.yaml >>>> +++ b/Documentation/devicetree/bindings/net/ti,dp83822.yaml >>>> @@ -80,6 +80,22 @@ properties: >>>> 10625, 11250, 11875, 12500, 13125, 13750, 14375, 15000] >>>> default: 10000 >>>> + ti,rmii-mode: >>>> + description: | >>>> + If present, select the RMII operation mode. Two modes are >>>> + available: >>>> + - RMII master, where the PHY operates from a 25MHz clock reference, >>>> + provided by a crystal or a CMOS-level oscillator >>>> + - RMII slave, where the PHY operates from a 50MHz clock reference, >>>> + provided by a CMOS-level oscillator >>> >>> What has master and slave got to do with this? >>> >>> Sometimes, the MAC provides a clock to the PHY, and all data transfer >>> over the RMII bus is timed by that. >>> >>> Sometimes, the PHY provides a clock to the MAC, and all data transfer >>> over the RMII bus is timed by that. >>> >>> Here there is a clear master/slave relationship, who is providing the >>> clock, who is consuming the clock. However, what you describe does not >>> fit that. Maybe look at other PHY bindings, and copy what they do for >>> clocks. >> >> In fact, I hesitated a lot before choosing this master/slave designation >> because of the same reasoning as you. But the TI DP83826 datasheet [1] uses >> this name for two orthogonal yet connected meanings, here's a copy of the >> corresponding § (in section 9.3.10): >> >> "The DP83826 offers two types of RMII operations: RMII Slave and RMII >> Master. In RMII Master operation, the DP83826 operates from either a 25-MHz >> CMOS-level oscillator connected to XI pin, a 25-MHz crystal connected across >> XI and XO pins. A 50-MHz output clock referenced from DP83826 can be >> connected to the MAC. In RMII Slave operation, the DP83826 operates from a >> 50-MHz CMOS-level oscillator connected to the XI pin and shares the same >> clock as the MAC. Alternatively, in RMII slave mode, the PHY can operate >> from a 50-MHz clock provided by the Host MAC." >> >> So it seems that in some cases this also fits the master/slave relationship >> you describe. > > We are normally interested in this 50Mhz reference clock. So i would > drop all references to 25Mhz. It is not relevant to the binding, since > it is nothing to do with connecting the PHY to the MAC, and it has a > fixed value. > > So you can simplify this down to: > > RMII Master: Outputs a 50Mhz Reference clock which can be connected to the MAC. > > RMII Slave: Expects a 50MHz Reference clock input, shared with the > MAC. > >> That said, would you like me to include this description (or some parts) in >> the binding in addition to what I've already written? Or would you prefer me >> to use a more meaningful property name? > > We don't really have any vendor agnostic consistent naming. dp83867 > and dp83869 seems to call this ti,clk-output-sel. Since this is > another dp83xxx device, it would be nice if there was consistency > between all these TI devices. So could you check if the concept is the > same, and if so, change dp83826 to follow what other TI devices do. So I had a look at this ti,clk-output-sel property on the TI DP8386x bindings, but unfortunately it does not correspond to our use case. In their case, it is used to select one of the various internal clocks to output on the CLK_OUT pin. In our case, we would prefer to describe the direction of the clock (OUT in master mode, IN in slave mode). Given this, should we stick to "ti,rmii-mode" which is consistent with the datasheet terminology, or consider perhaps something like ti,clock-dir-sel (with possible values of in/out)?" Best regards, Jérémie
> > We are normally interested in this 50Mhz reference clock. So i would > > drop all references to 25Mhz. It is not relevant to the binding, since > > it is nothing to do with connecting the PHY to the MAC, and it has a > > fixed value. > > > > So you can simplify this down to: > > > > RMII Master: Outputs a 50Mhz Reference clock which can be connected to the MAC. > > > > RMII Slave: Expects a 50MHz Reference clock input, shared with the > > MAC. > > > > > That said, would you like me to include this description (or some parts) in > > > the binding in addition to what I've already written? Or would you prefer me > > > to use a more meaningful property name? > > > > We don't really have any vendor agnostic consistent naming. dp83867 > > and dp83869 seems to call this ti,clk-output-sel. Since this is > > another dp83xxx device, it would be nice if there was consistency > > between all these TI devices. So could you check if the concept is the > > same, and if so, change dp83826 to follow what other TI devices do. > > > So I had a look at this ti,clk-output-sel property on the TI DP8386x > bindings, but unfortunately it does not correspond to our use case. In their > case, it is used to select one of the various internal clocks to output on > the CLK_OUT pin. > In our case, we would prefer to describe the direction of the clock (OUT in > master mode, IN in slave mode). I would suggest we keep with the current property name, but simplify the description. Focus on the reference clock, and ignore the crystal. Andrew
>>> We are normally interested in this 50Mhz reference clock. So i would >>> drop all references to 25Mhz. It is not relevant to the binding, since >>> it is nothing to do with connecting the PHY to the MAC, and it has a >>> fixed value. >>> >>> So you can simplify this down to: >>> >>> RMII Master: Outputs a 50Mhz Reference clock which can be connected to the MAC. >>> >>> RMII Slave: Expects a 50MHz Reference clock input, shared with the >>> MAC. >>> >>>> That said, would you like me to include this description (or some parts) in >>>> the binding in addition to what I've already written? Or would you prefer me >>>> to use a more meaningful property name? >>> >>> We don't really have any vendor agnostic consistent naming. dp83867 >>> and dp83869 seems to call this ti,clk-output-sel. Since this is >>> another dp83xxx device, it would be nice if there was consistency >>> between all these TI devices. So could you check if the concept is the >>> same, and if so, change dp83826 to follow what other TI devices do. >> >> >> So I had a look at this ti,clk-output-sel property on the TI DP8386x >> bindings, but unfortunately it does not correspond to our use case. In their >> case, it is used to select one of the various internal clocks to output on >> the CLK_OUT pin. >> In our case, we would prefer to describe the direction of the clock (OUT in >> master mode, IN in slave mode). > > I would suggest we keep with the current property name, but simplify > the description. Focus on the reference clock, and ignore the crystal. Ok noted, thanks for your feedback! I will send a v2 containing a simplified description + implement your suggested changes on patch 2. Jérémie
diff --git a/Documentation/devicetree/bindings/net/ti,dp83822.yaml b/Documentation/devicetree/bindings/net/ti,dp83822.yaml index 8f4350be689c..8f23254c0458 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83822.yaml +++ b/Documentation/devicetree/bindings/net/ti,dp83822.yaml @@ -80,6 +80,22 @@ properties: 10625, 11250, 11875, 12500, 13125, 13750, 14375, 15000] default: 10000 + ti,rmii-mode: + description: | + If present, select the RMII operation mode. Two modes are + available: + - RMII master, where the PHY operates from a 25MHz clock reference, + provided by a crystal or a CMOS-level oscillator + - RMII slave, where the PHY operates from a 50MHz clock reference, + provided by a CMOS-level oscillator + The RMII operation mode can also be configured by its straps. + If the strap pin is not set correctly or not set at all, then this can be + used to configure it. + $ref: /schemas/types.yaml#/definitions/string + enum: + - master + - slave + required: - reg