From: Christoph Stoidner <C.Stoidner@phytec.de>
To: Stefan Wahren <wahrenst@gmx.net>, Andrew Lunn <andrew@lunn.ch>
Cc: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"imx@lists.linux.dev" <imx@lists.linux.dev>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"upstream@lists.phytec.de" <upstream@lists.phytec.de>
Subject: Re: [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio
Date: Mon, 26 May 2025 09:09:03 +0000 [thread overview]
Message-ID: <34a4441d4b4ed8db7cac585ce93ec2357738cc11.camel@phytec.de> (raw)
In-Reply-To: <b2ea6b7f-3623-4486-82a0-cab97053a53e@gmx.net>
Hi Stefan,
On Mo, 2025-05-26 at 08:44 +0200, Stefan Wahren wrote:
> Hi Andrew,
> hi Christoph
>
> Am 24.05.25 um 19:44 schrieb Andrew Lunn:
> > > diff --git a/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
> > > b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
> > > index 88c2657b50e6..b481097f08a4 100644
> > > --- a/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
> > > @@ -68,6 +68,8 @@ mdio: mdio {
> > > ethphy1: ethernet-phy@1 {
> > > compatible = "ethernet-phy-ieee802.3-c22";
> > > reg = <1>;
> > > + reset-gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
> > > + reset-assert-us = <30>;
> > Is there anything in the datasheet about needing a delay after the
> > reset? There is a DT property for this:
> >
> > reset-deassert-us:
> > description:
> > Delay after the reset was deasserted in microseconds. If
> > this property is missing the delay will be skipped.
> is it the time until the PHY finished its post reset stabilization
> (datasheet to call it T2 "reset to SMI ready")?
The T2 ("Post reset stabilization time") in the datasheet is the time
"prior to MDC preamble for register access", that is defined with 2ms.
I did not use reset-deassert-us for it, because the first register
access does anyway occur much later (I measured 4000ms).
And we have the same for T4, the "Post power-up stabilization time".
It is defined with a time of 50ms as "prior to MDC preamble for
register access". But also here we just know, the register access
happens much later - and treated it as enough.
Formally, this may be valid to specify the 2ms as reset-deassert-us.
But since the first register access is so much later, I thought we can
save those 2ms.
Are you fine with that?
Regards,
Christoph
> >
> > Anyway:
> >
> > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> >
> > Andrew
> >
>
next prev parent reply other threads:[~2025-05-26 9:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-24 11:23 [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio Christoph Stoidner
2025-05-24 17:44 ` Andrew Lunn
2025-05-24 21:37 ` AW: " Christoph Stoidner
2025-05-26 6:44 ` Stefan Wahren
2025-05-26 9:09 ` Christoph Stoidner [this message]
2025-05-26 9:24 ` Stefan Wahren
2025-05-26 10:04 ` Christoph Stoidner
2025-05-26 12:14 ` Stefan Wahren
2025-05-28 18:30 ` Christoph Stoidner
2025-05-28 19:29 ` Andrew Lunn
2025-05-30 13:40 ` Christoph Stoidner
2025-06-02 2:09 ` Andrew Lunn
2025-06-02 11:46 ` Christoph Stoidner
2025-06-02 12:26 ` Andrew Lunn
2025-07-08 8:35 ` [Upstream] " Primoz Fiser
2025-07-18 17:33 ` Christoph Stoidner
2025-07-18 17:47 ` Andrew Lunn
2025-08-07 12:53 ` Christoph Stoidner
2025-08-20 2:36 ` Shawn Guo
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=34a4441d4b4ed8db7cac585ce93ec2357738cc11.camel@phytec.de \
--to=c.stoidner@phytec.de \
--cc=andrew@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=festevam@gmail.com \
--cc=imx@lists.linux.dev \
--cc=kernel@pengutronix.de \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=upstream@lists.phytec.de \
--cc=wahrenst@gmx.net \
/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;
as well as URLs for NNTP newsgroup(s).