mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Daniel Machon <daniel.machon@microchip.com>
Cc: UNGLinuxDriver@microchip.com, Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Lars Povlsen <lars.povlsen@microchip.com>,
	Steen Hegelund <Steen.Hegelund@microchip.com>,
	Horatiu Vultur <horatiu.vultur@microchip.com>,
	Russell King <linux@armlinux.org.uk>,
	jacob.e.keller@intel.com, robh@kernel.org, krzk+dt@kernel.org,
	conor+dt@kernel.org, devicetree@vger.kernel.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH net-next v2 8/8] dt-bindings: net: sparx5: document RGMII MAC delays
Date: Tue, 19 Nov 2024 01:59:54 +0100	[thread overview]
Message-ID: <5b9d79f1-ccdd-47c3-a02a-5ff0b12c1fb8@lunn.ch> (raw)
In-Reply-To: <20241115092237.gzpat4x6kjipb2x7@DEN-DL-M70577>

On Fri, Nov 15, 2024 at 09:22:37AM +0000, Daniel Machon wrote:
> Hi Andrew,
> 
> > > The lan969x switch device supports two RGMII port interfaces that can be
> > > configured for MAC level rx and tx delays.
> > >
> > > Document two new properties {rx,tx}-internal-delay-ps. Make them
> > > required properties, if the phy-mode is one of: rgmii, rgmii_id,
> > > rgmii-rxid or rgmii-txid. Also specify accepted values.
> > 
> > This is unusual if you look at other uses of {rt}x-internal-delay-ps.
> > It is generally an optional parameter, and states it defaults to 0 if
> > missing, and is ignored by the driver if phy-mode is not an rgmii
> > variant.
> 
> Is unusual bad? :-)

Depends. Having a uniform usage is good, it causes less confusion. But
strict enforcement also has its plus side.

> I thought that requiring the properties would make
> misconfigurations (mismatching phy-modes and MAC delays) more obvious,
> as you were forced to specify exactly what combination you want in the
> DT.  Maybe not. I can change it,  no problem.

Do these ports only support RGMII? The general pattern is that ports
supporting RGMII also support other modes, GMII, MII, rev-GMII,
rev-MII etc. For these other modes RGMII delays are meaningless. The
general pattern is that they are allowed in DT, but are just ignored.

If the LAN969x ports only support RGMII, and you are enforcing the
four RGMII modes in DT, you could also enforce the delays are present
and only have all allowed values. But i would not have the enforcement
any more strict than the other ports. Do you enforce the phy-modes for
the ports with a PCS?

	Andrew

  reply	other threads:[~2024-11-19  1:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-13 21:11 [PATCH net-next v2 0/8] net: lan969x: add RGMII support Daniel Machon
2024-11-13 21:11 ` [PATCH net-next v2 1/8] net: sparx5: do some preparation work Daniel Machon
2024-11-13 21:11 ` [PATCH net-next v2 2/8] net: sparx5: add function for RGMII port check Daniel Machon
2024-11-13 21:11 ` [PATCH net-next v2 3/8] net: sparx5: use is_port_rgmii() throughout Daniel Machon
2024-11-13 21:11 ` [PATCH net-next v2 4/8] net: sparx5: use phy_interface_mode_is_rgmii() Daniel Machon
2024-11-13 21:11 ` [PATCH net-next v2 5/8] net: sparx5: verify RGMII speeds Daniel Machon
2024-11-13 21:11 ` [PATCH net-next v2 6/8] net: lan969x: add RGMII registers Daniel Machon
2024-11-13 21:11 ` [PATCH net-next v2 7/8] net: lan969x: add RGMII implementation Daniel Machon
2024-11-13 21:11 ` [PATCH net-next v2 8/8] dt-bindings: net: sparx5: document RGMII MAC delays Daniel Machon
2024-11-14 20:06   ` Conor Dooley
2024-11-18 10:50     ` Daniel Machon
2024-11-20 17:46       ` Conor Dooley
2024-11-14 20:13   ` Andrew Lunn
2024-11-15  9:22     ` Daniel Machon
2024-11-19  0:59       ` Andrew Lunn [this message]
2024-11-19 11:43         ` Daniel Machon
2024-11-14 11:55 ` [PATCH net-next v2 0/8] net: lan969x: add RGMII support Robert Marko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5b9d79f1-ccdd-47c3-a02a-5ff0b12c1fb8@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=Steen.Hegelund@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=conor+dt@kernel.org \
    --cc=daniel.machon@microchip.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=horatiu.vultur@microchip.com \
    --cc=jacob.e.keller@intel.com \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=lars.povlsen@microchip.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®