netdev - Re: [PATCH 1/4] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <693c3d1e-a65b-47ea-9b21-ce1d4a772066@sirena.org.uk>
Date: Wed, 10 Sep 2025 16:09:05 +0100
From: Mark Brown <broonie@...nel.org>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: Marco Felsch <m.felsch@...gutronix.de>,
	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,
	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 05:43:28PM +0300, Vladimir Oltean wrote:
> 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.

...

> 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.

I suspect you're reading too much into the datasheet there.  I suspect
that what it's trying to say is that the reset signal only works with
stable power and clocks, that it must be held low for the 5us while
those conditions hold and that you have to do at least one cold reset
after power on.  The above wording is pretty common in datasheets and I
know in a bunch of cases it was carried forward kind of blindly rather
than looking at the actual device requirements.

> 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.

I'm not sure not including the signal in the DT bindings is going to
influence board designers much either way TBH.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)