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

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

On 25-09-10, Vladimir Oltean wrote:
> 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@pengutronix.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.

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.

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

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.

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

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

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.

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.

On 25-09-10, Vladimir Oltean wrote:
> 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.

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.

Regards,
  Marco

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.

On 25-09-10, Vladimir Oltean wrote:
> 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.

We could do that but I think that no one should assume that the driver
ensures this due to the missing power-supply and clock support. But this
goes to the DT maintainers. IMHO we shouldn't mention any document
within the binding, maybe within the commit message, since those
documents may get removed.

Regards,
  Marco

On Wed, Sep 10, 2025 at 06:55:18PM +0200, Marco Felsch wrote:
> On 25-09-10, Vladimir Oltean wrote:
> > 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.
> 
> We could do that but I think that no one should assume that the driver
> ensures this due to the missing power-supply and clock support. But this
> goes to the DT maintainers. IMHO we shouldn't mention any document
> within the binding, maybe within the commit message, since those
> documents may get removed.

We probably have lots of dead links... So what's one more possible one. 
If the information is useful, then I'd put the link there.

Rob

On Wed, Sep 10, 2025 at 06:34:54PM +0300, Vladimir Oltean wrote:
> On Wed, Sep 10, 2025 at 04:09:05PM +0100, Mark Brown wrote:

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

Fair enough if this chip is unusually unstable, TBH I'm surprised to
see something currently available that's so fragile - internal POR
circuits aren't exactly new or exciting and do make things so much more
robust.