[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fbeca9fd-38a6-49ba-bb5f-6df5302d139d@sirena.org.uk>
Date: Tue, 18 Mar 2025 19:13:10 +0000
From: Mark Brown <broonie@...ian.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Breno Leitao <leitao@...ian.org>,
Thierry Reding <thierry.reding@...il.com>,
Jon 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,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, noodles@...th.li,
Jarkko Sakkinen <jarkko@...nel.org>,
Peter Huewe <peterhuewe@....de>, jgg@...pe.c
Subject: Re: [PATCH 1/3] spi: tegra210-quad: use device_reset_optional()
instead of device_reset()
On Tue, Mar 18, 2025 at 08:00:05PM +0100, Arnd Bergmann wrote:
> That does sound like the easiest answer: if the spi controller driver
> knows that it needs a reset but there is no reset controller, shutting
> itself down and removing its child devices seems like the least
> offensive action.
In that case it's probably more just refuse to probe in the first case
without the reset controller. Given that the device isn't working at
all it seems like the hardware description is broken anyway...
> No idea if there are other spi controllers that do something like this.
I'm really not thrilled about adding runtime error handling at that
level in the controller - it'll start to get into policy stuff if anyone
does something clever and realistically it's all broken hardware
description or very severe physical failure type stuff.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists