All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Swathi K S <swathi.ks@samsung.com>
Cc: krzk+dt@kernel.org, andrew+netdev@lunn.ch, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	robh@kernel.org, conor+dt@kernel.org, richardcochran@gmail.com,
	mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com,
	rmk+kernel@armlinux.org.uk, netdev@vger.kernel.org,
	devicetree@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	'Pankaj	Dubey' <pankaj.dubey@samsung.com>,
	ravi.patel@samsung.com
Subject: Re: [PATCH v6 1/2] dt-bindings: net: Add FSD EQoS device tree bindings
Date: Mon, 17 Feb 2025 16:18:11 +0100	[thread overview]
Message-ID: <18746e2f-4124-4f85-97d2-a040b78b4b34@lunn.ch> (raw)
In-Reply-To: <011901db80fb$8e968f60$abc3ae20$@samsung.com>

> > > > > +  phy-mode:
> > > > > +    enum:
> > > > > +      - rgmii-id
> > > >
> > > > phy-mode is normally a board property, in the .dts file, since the
> > > > board
> > > might
> > > > decide to have extra long clock lines and so want 'rgmii'.

> Hi Andrew, 
> What you said is right. Generally, PCB provides internal delay.

It is actually pretty unusual for the PCB to add the delays. But there
are some boards which do this. Which is why you should support it.

> But in this case, due to customer request, the delay was added into SoC.

Idealy, by the PHY. However, in terms of DT, the board .dts file just
needs to say 'rmgii-id', meaning that the board does not provide the
delays, so the MAC/PHY pair needs to provide the delay.

> The following doc on rgmii says that "Devices which implement internal delay
> shall be referred to as RGMII-ID. 
> Devices may offer an option to operate with/without internal delay and still
> remain compliant with this spec"
> https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/imx-processors/2
> 0655/1/RGMIIv2_0_final_hp.pdf
> 
> Also, the driver is in such a way that it handles all four rgmii in the same
> way. 
> 
> Considering this, could you let us know what will be the right approach to
> take in this case?

List all four phy-modes in the binding. They should all be
valid. However, the .dtsi file should not list a phy-mode, since it is
a board property, not a SoC property.

	Andrew

  reply	other threads:[~2025-02-17 15:18 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20250213044950epcas5p1a7badb480a7e8d843fe0ff51bcf5cbf4@epcas5p1.samsung.com>
2025-02-13  4:46 ` [PATCH v6 0/2] net: stmmac: dwc-qos: Add FSD EQoS support Swathi K S
     [not found]   ` <CGME20250213044955epcas5p110d1e582c8ee02579ead73f9686819ff@epcas5p1.samsung.com>
2025-02-13  4:46     ` [PATCH v6 1/2] dt-bindings: net: Add FSD EQoS device tree bindings Swathi K S
2025-02-13  7:54       ` Krzysztof Kozlowski
2025-02-13 11:04         ` Swathi K S
2025-02-13 12:00           ` Krzysztof Kozlowski
2025-02-14  4:53             ` Swathi K S
2025-02-14  7:31               ` Krzysztof Kozlowski
2025-02-14  9:33                 ` Swathi K S
2025-02-14 10:55                   ` Krzysztof Kozlowski
2025-02-14  0:19       ` Andrew Lunn
2025-02-14  5:17         ` Swathi K S
2025-02-14 13:10           ` Andrew Lunn
2025-02-17  5:19             ` Swathi K S
2025-02-17 15:18               ` Andrew Lunn [this message]
2025-02-18  3:55                 ` Swathi K S
2025-02-18 15:33                   ` Andrew Lunn
     [not found]   ` <CGME20250213044959epcas5p1b6f6d5554f69b5c24a5b4a15c8bf1fc9@epcas5p1.samsung.com>
2025-02-13  4:46     ` [PATCH v6 2/2] net: stmmac: dwc-qos: Add FSD EQoS support Swathi K S

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=18746e2f-4124-4f85-97d2-a040b78b4b34@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pankaj.dubey@samsung.com \
    --cc=ravi.patel@samsung.com \
    --cc=richardcochran@gmail.com \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=robh@kernel.org \
    --cc=swathi.ks@samsung.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.