[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250318-furry-piquant-orca-da28c2@leitao>
Date: Tue, 18 Mar 2025 10:02:47 -0700
From: Breno Leitao <leitao@...ian.org>
To: Mark Brown <broonie@...ian.org>
Cc: Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
Sowjanya Komatineni <skomatineni@...dia.com>,
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
Subject: Re: [PATCH 1/3] spi: tegra210-quad: use device_reset_optional()
instead of device_reset()
On Tue, Mar 18, 2025 at 12:48:13PM +0000, Mark Brown wrote:
> Well, that's not clear to me. It seems likely to work a lot of the time
> on probe but I don't know how well it handles a warm reboot for example.
> Like I say the error handling case seems more likely to be at least less
> effective without a reset controller so it'd be worth logging. In the
> DT the reset controller is a required property which suggests the driver
> might be assuming it's got the hardware into a known state.
Makes sense. Another question, for platforms like this one that doesn't
have the device reset methods, what can we do to stop the bleed?
Basically every message that is sent to the SPI controller will fail,
which will trigger the device_reet() which is a no-op, but the device
will continue to be online. Should we disable the device after some
point?
Regarding this patchset, I understand that patch #1 is not ideal as
discussed above, what about patch 2 and 3?
Thanks
--breno
Powered by blists - more mailing lists