[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <015601db81b8$ee7237f0$cb56a7d0$@samsung.com>
Date: Tue, 18 Feb 2025 09:25:08 +0530
From: "Swathi K S" <swathi.ks@...sung.com>
To: "'Andrew Lunn'" <andrew@...n.ch>
Cc: <krzk+dt@...nel.org>, <andrew+netdev@...n.ch>, <davem@...emloft.net>,
<edumazet@...gle.com>, <kuba@...nel.org>, <pabeni@...hat.com>,
<robh@...nel.org>, <conor+dt@...nel.org>, <richardcochran@...il.com>,
<mcoquelin.stm32@...il.com>, <alexandre.torgue@...s.st.com>,
<rmk+kernel@...linux.org.uk>, <netdev@...r.kernel.org>,
<devicetree@...r.kernel.org>, <linux-stm32@...md-mailman.stormreply.com>,
<linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
"'Pankaj Dubey'" <pankaj.dubey@...sung.com>, <ravi.patel@...sung.com>
Subject: RE: [PATCH v6 1/2] dt-bindings: net: Add FSD EQoS device tree
bindings
> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: 17 February 2025 20:48
> To: Swathi K S <swathi.ks@...sung.com>
> Cc: krzk+dt@...nel.org; andrew+netdev@...n.ch; davem@...emloft.net;
> edumazet@...gle.com; kuba@...nel.org; pabeni@...hat.com;
> robh@...nel.org; conor+dt@...nel.org; richardcochran@...il.com;
> mcoquelin.stm32@...il.com; alexandre.torgue@...s.st.com;
> rmk+kernel@...linux.org.uk; netdev@...r.kernel.org;
> devicetree@...r.kernel.org; linux-stm32@...md-mailman.stormreply.com;
> linux-arm-kernel@...ts.infradead.org; linux-kernel@...r.kernel.org;
'Pankaj
> Dubey' <pankaj.dubey@...sung.com>; ravi.patel@...sung.com
> Subject: Re: [PATCH v6 1/2] dt-bindings: net: Add FSD EQoS device tree
> bindings
>
> > > > > > + 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-
> proces
> > sors/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.
Hi Andrew,
Thanks for the clarification.
Will post v7 with the following updates:
1. Changing phy-mode in dt-binding as shown below:
phy-mode:
enum:
- rgmii
- rgmii-id
- rgmii-rxid
- rgmii-txid
2. Removing phy-mode from .dtsi and example given in dt-binding
3. Add phy-mode to .dts file and specify 'rgmii-id' there.
Hope this will address your review comment.
Thanks,
Swathi
>
> Andrew
Powered by blists - more mailing lists