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

[Vladimir Oltean <vladimir.oltean@nxp.com>]

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.