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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ