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

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.

quoted

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.

quoted

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.

quoted

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