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: <20250910153454.ibh6w7ntxraqvftb@skbuf>
Date: Wed, 10 Sep 2025 18:34:54 +0300
From: Vladimir Oltean <vladimir.oltean@....com>
To: Mark Brown <broonie@...nel.org>
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 04:09:05PM +0100, Mark Brown wrote:
> > 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.

No, it doesn't say that, and I had discussions with the application
engineering team for this chip about this :-/

I can't comment on anything extrapolated outside of the SJA1105/SJA1110.

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

Either way, something has to nudge at least the software developer
towards finding and reading the vendor's relevant documentation.

In that sense, 'reset-gpios' is misleading to say the least, because
everyone sees a reset GPIO and has the human tendency to think there
isn't anything more to be known about it (like I also did).

To be clear, I'm saying that supporting 'reset-gpios' in this driver was
a mistake, at least in the form where its supplies and clocks aren't
also under control. I'm not sure it's a mistake that we need to document,
and if we do, there need to be a lot more disclaimers. Also, I'm pretty
sure nothing will break if driver support for it is simply removed.