Message-ID: <20250910144328.do6t5ilfeclm2xa4@skbuf>
Date: Wed, 10 Sep 2025 17:43:28 +0300
From: Vladimir Oltean <vladimir.oltean@....com>
To: Marco Felsch <m.felsch@...gutronix.de>
Cc: Jonas Rebmann <jre@...gutronix.de>, Andrew Lunn <andrew@...n.ch>,
	imx@...ts.linux.dev, linux-kernel@...r.kernel.org,
	Eric Dumazet <edumazet@...gle.com>,
	Fabio Estevam <festevam@...il.com>, Rob Herring <robh@...nel.org>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	devicetree@...r.kernel.org, Conor Dooley <conor+dt@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>, linux-sound@...r.kernel.org,
	Mark Brown <broonie@...nel.org>,
	linux-arm-kernel@...ts.infradead.org, netdev@...r.kernel.org,
	Shengjiu Wang <shengjiu.wang@....com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Vladimir Oltean <olteanv@...il.com>,
	Shawn Guo <shawnguo@...nel.org>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH 1/4] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios
 property

On Wed, Sep 10, 2025 at 04:30:44PM +0200, Marco Felsch wrote:
> Can you please elaborate a bit more? I was curious and checked the
> AH1704, it says:
> 
> "The RST_N signal must be kept low for at least 5 us after all power
> supplies and reference clock signals become stable."
> 
> This is very common, so the driver only needs to ensure that the pin was
> pulled low for at least 5us but not exact 5us.

The statement says that during power-up, when the supply voltages and
clocks rise in order to become within spec, the reset signal must be
held low. This requirement lasts for up to 5 us more after the other
signals are in spec.

> > Additionally, routing the reset signal to a host SoC GPIO does not bring
> > any particular benefit, since the switch can be (and is) also reset by
> > the driver over SPI.
> 
> I don't know the switch but it's also common that a so called
> software-reset may not reset all registers, state machines, etc.

Neither should you assume that RST_N resets everything. I can't be a lot
more specific, but asserting RST_N at runtime is essentially equivalent
to a cold reset as done over SPI, as done by sja1105pqrs_reset_cmd().

> There it's common practice that the driver tries to pull the hw reset
> line and if not present falls back to a software reset.
> 
> > So, at least for this particular switch, having a "reset-gpios" actively
> > points towards a potential violation of its POR timing requirements.
> 
> Really? Please see my above comment.
> 
> > That is, unless the power rails are also software-controlled. But they
> > aren't.
> 
> AH1704 Fig.10 just illustrate a reset and power-on sequence. I highly
> doubt that the host can't pull the hw rest line if the supplies and the
> clock is already running.

I didn't say that it can't pull the reset line if the supplies/clocks
are in spec.

I said that _while the supplies and clocks aren't in spec and 5 us after
they become in spec_, RST_N has to be kept low.

And if you plan to do that from the GPIO function of your SoC, the SoC
might be busy doing other stuff, like booting, and no one might be
driving the RST_N voltage to a defined state.

It really depends on a lot of factors including the reset timing and
supply voltage distribution of the PCB, but RST_N has essentially 2
purposes. One is ensuring proper POR sequencing, the other is cold
resetting at runtime. You can do the latter over SPI with identical
outcome, which leaves proper POR sequencing, which is not best served by
a GPIO in my experience.

> You're right about the fact that the driver is currently not able to do
> a proper power-on sequence, so the kernel relies on the prev. firmware
> or the hw-setup. But this is another problem.
> 
> Regards,
>   Marco

Powered by blists - more mailing lists