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: <20250910164231.cnrexx4ds3cdg6lu@skbuf>
Date: Wed, 10 Sep 2025 19:42:31 +0300
From: Vladimir Oltean <vladimir.oltean@....com>
To: Marco Felsch <m.felsch@...gutronix.de>
Cc: Mark Brown <broonie@...nel.org>, 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:53:59PM +0200, Marco Felsch wrote:
> IMHO silently removing the support will break designs for sure and
> should never be done. As said, imagine that the firmware will handle the
> supplies and the driver only needs to release the reset. If you silently
> remove the support, the device will be kept in reset-state. In field
> firmware updates are seldom, so you break your device by updating to a
> new kernel.
> 
> One could argue that the driver supported it but there was no dt-binding
> yet, so it was a hidden/unstable feature but I don't know the policy.

Ok, I didn't think about, or meet, the case where Linux is required by
previous boot stages to deassert the reset. It is the first time you are
explicitly saying this, though.

So we can keep and document the 'reset-gpios' support, but we need to
explicitly point out that if present, it does not supplant the need to
ensure the proper POR sequence as per AH1704.