Linux Tegra architecture development
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Mark Brown" <broonie@debian.org>
Cc: "Breno Leitao" <leitao@debian.org>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Jon Hunter" <jonathanh@nvidia.com>,
	"Sowjanya Komatineni" <skomatineni@nvidia.com>,
	"Laxman Dewangan" <ldewangan@nvidia.com>,
	linux-tegra@vger.kernel.org, linux-spi@vger.kernel.org,
	linux-kernel@vger.kernel.org, rmikey@meta.com,
	kernel-team@meta.com,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	noodles@earth.li, "Jarkko Sakkinen" <jarkko@kernel.org>,
	"Peter Huewe" <peterhuewe@gmx.de>,
	jgg@ziepe.c
Subject: Re: [PATCH 1/3] spi: tegra210-quad: use device_reset_optional() instead of device_reset()
Date: Tue, 18 Mar 2025 21:07:28 +0100	[thread overview]
Message-ID: <6cf8af69-634e-40fa-af45-912540b29aac@app.fastmail.com> (raw)
In-Reply-To: <fbeca9fd-38a6-49ba-bb5f-6df5302d139d@sirena.org.uk>

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

  reply	other threads:[~2025-03-18 20:07 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-17 15:44 [PATCH 0/3] spi: tegra210-quad: Improve reset and tx failures Breno Leitao
2025-03-17 15:44 ` [PATCH 1/3] spi: tegra210-quad: use device_reset_optional() instead of device_reset() Breno Leitao
2025-03-17 16:45   ` Mark Brown
2025-03-17 16:56     ` Breno Leitao
2025-03-17 17:24       ` Mark Brown
2025-03-18 10:36         ` Breno Leitao
2025-03-18 12:48           ` Mark Brown
2025-03-18 17:02             ` Breno Leitao
2025-03-18 17:34               ` Mark Brown
2025-03-18 18:29                 ` Breno Leitao
2025-03-18 18:32                   ` Breno Leitao
2025-03-18 19:00                     ` Arnd Bergmann
2025-03-18 19:13                       ` Mark Brown
2025-03-18 20:07                         ` Arnd Bergmann [this message]
2025-03-19 10:09                           ` Breno Leitao
2025-03-19 18:26                             ` Thierry Reding
2025-03-19 18:53                               ` Breno Leitao
2025-03-21 12:40                                 ` Thierry Reding
2025-03-21 16:28                                   ` Breno Leitao
2025-03-24 13:17                                     ` Thierry Reding
2025-03-25 16:56                                       ` Breno Leitao
2025-03-25 17:05                                         ` Thierry Reding
2025-03-28 13:18                                           ` Breno Leitao
2025-03-19 13:11                           ` Mark Brown
2025-03-18 18:35                   ` Mark Brown
2025-03-18 19:08                     ` Breno Leitao
2025-03-18 19:16                       ` Mark Brown
2025-03-17 15:44 ` [PATCH 2/3] spi: tegra210-quad: use WARN_ON_ONCE instead of WARN_ON for timeouts Breno Leitao
2025-03-17 15:44 ` [PATCH 3/3] spi: tegra210-quad: add rate limiting and simplify timeout error message Breno Leitao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6cf8af69-634e-40fa-af45-912540b29aac@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=broonie@debian.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jarkko@kernel.org \
    --cc=jgg@ziepe.c \
    --cc=jonathanh@nvidia.com \
    --cc=kernel-team@meta.com \
    --cc=ldewangan@nvidia.com \
    --cc=leitao@debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=noodles@earth.li \
    --cc=peterhuewe@gmx.de \
    --cc=rmikey@meta.com \
    --cc=skomatineni@nvidia.com \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox