[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250910125611.wmyw2b4jjtxlhsqw@skbuf>
Date: Wed, 10 Sep 2025 15:56:11 +0300
From: Vladimir Oltean <vladimir.oltean@....com>
To: Jonas Rebmann <jre@...gutronix.de>
Cc: Andrew Lunn <andrew@...n.ch>, Vladimir Oltean <olteanv@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>,
Shengjiu Wang <shengjiu.wang@....com>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
netdev@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-sound@...r.kernel.org,
imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 1/4] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios
property
On Wed, Sep 10, 2025 at 02:35:21PM +0200, Jonas Rebmann wrote:
> Both the nxp,sja1105 and the nxp,sja1110 series feature an active-low
> reset pin, rendering reset-gpios a valid property for all of the
> nxp,sja1105 family.
>
> Signed-off-by: Jonas Rebmann <jre@...gutronix.de>
> ---
> Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
> index 9432565f4f5d..8f4ef9d64556 100644
> --- a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
> +++ b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
> @@ -32,6 +32,11 @@ properties:
> reg:
> maxItems: 1
>
> + reset-gpios:
> + description:
> + GPIO to be used to reset the whole device
> + maxItems: 1
> +
> spi-cpha: true
> spi-cpol: true
>
>
> --
> 2.51.0.178.g2462961280
>
There are multiple issues with the reset line and I was considering
dropping driver support for it.
The most important issue is the fact that, according to NXP document
AH1704, the RST_N signal has to be kept asserted for 5 us after power-on
reset. That is hard to achieve if this pin is routed to an SoC GPIO.
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.
So, at least for this particular switch, having a "reset-gpios" actively
points towards a potential violation of its POR timing requirements.
That is, unless the power rails are also software-controlled. But they
aren't.
Powered by blists - more mailing lists