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] [day] [month] [year] [list]

Message-Id: <6cf8af69-634e-40fa-af45-912540b29aac@app.fastmail.com>
Date: Tue, 18 Mar 2025 21:07:28 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Mark Brown" <broonie@...ian.org>
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 20:13, Mark Brown wrote:
> 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...

Right, I see now that it's doing a rather silly

       if (device_reset(tqspi->dev) < 0)
               dev_warn_once(tqspi->dev, "device reset failed\n");

after which it just continues instead of propagating returning
the error from the probe function. This is also broken when
the reset controller driver has not been loaded yet and it
should do an -EPROBE_DEFER.

In case of a broken ACPI table, this would simply fail the
probe() with an error, which seems like a sensible behavior.

    Arnd