linux-kernel - Re: [PATCH 1/3] spi: tegra210-quad: use device_reset_optional() instead of device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <47c40ec0-291c-4664-a66e-d76bd6360c0d@sirena.org.uk>
Date: Tue, 18 Mar 2025 17:34:55 +0000
From: Mark Brown <broonie@...ian.org>
To: Breno Leitao <leitao@...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 10:02:47AM -0700, Breno Leitao wrote:

> 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?

The SPI controller is only going to be doing something because some
driver for an attached SPI device is trying to do something.  Presumably
whatever driver that is won't be having a good time and can hopefully
figure something out, though given that SPI is simple and not
hotpluggable this isn't really something that comes up a lot in
production so I'd be unsurprised to see things just keep on retrying.
I'd expect to see any substantial error handling in the driver for the
device rather than in the controller.

Obviously there's something wrong with the device description here which
is upsetting the controller driver.

> Regarding this patchset, I understand that patch #1 is not ideal as
> discussed above, what about patch 2 and 3?

If I didn't say anything they're probably fine.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)