[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <q53apce4sltvnyd75j4o7taatocxiduq56fqsoxp3vrjmaqphk@o5kce2wb3dnz>
Date: Tue, 25 Mar 2025 18:05:28 +0100
From: Thierry Reding <thierry.reding@...il.com>
To: Breno Leitao <leitao@...ian.org>
Cc: Arnd Bergmann <arnd@...db.de>, jonathanh@...dia.com,
skomatineni@...dia.com, Mark Brown <broonie@...ian.org>,
Laxman Dewangan <ldewangan@...dia.com>, linux-tegra@...r.kernel.org, linux-spi@...r.kernel.org,
linux-kernel@...r.kernel.org, rmikey@...a.com, kernel-team@...a.com,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, noodles@...th.li, Jarkko Sakkinen <jarkko@...nel.org>,
Peter Huewe <peterhuewe@....de>
Subject: Re: [PATCH 1/3] spi: tegra210-quad: use device_reset_optional()
instead of device_reset()
On Tue, Mar 25, 2025 at 09:56:10AM -0700, Breno Leitao wrote:
> On Mon, Mar 24, 2025 at 02:17:11PM +0100, Thierry Reding wrote:
> > On Fri, Mar 21, 2025 at 09:28:34AM -0700, Breno Leitao wrote:
> > > Hello Thierry,
> > >
> > > On Fri, Mar 21, 2025 at 01:40:44PM +0100, Thierry Reding wrote:
> > > > Can you maybe help clarify at what point you start seeing errors induced
> > > > by the recovery mechanism?
> > >
> > > This is after a while. Something happen to QSPI and the warnings and
> > > device reset failed start going haywire.
> > >
> > > Most of the machines are fine, but, some get into this situation.
> >
> > Is it always the same devices, or does it happen randomly?
>
> We got this in two different and unrelated machines, already.
>
> I want to come back to how the driver should behave. We probably want to
> distinguish what is the correct behaviour we expect from the driver,
> they are (IMO):
>
> 1) The reset handlers are NOT optional and the device should fail to
> probe.
>
> 2) The reset handlers ARE optional, and we should mark them as such.
>
> Can you shed some light on what is the right behaviour we want to
> implement?
>
> From what I am hearing, we are more inclined towards 2). Is this
> correct?
Yes, I think 2) is what I'd be inclined towards. _RST is clearly not
available for at least certain firmware releases, so they are de-facto
optional.
Even if they are ever implemented, it'd be wise to keep supporting the
case where they are not available, so treating them as optional is the
right way to go.
Thierry
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists