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: <20250328-cinnamon-mushroom-of-proficiency-a17ba8@leitao>
Date: Fri, 28 Mar 2025 06:18:36 -0700
From: Breno Leitao <leitao@...ian.org>
To: Thierry Reding <thierry.reding@...il.com>, broonie@...ian.org
Cc: Arnd Bergmann <arnd@...db.de>, jonathanh@...dia.com,
	skomatineni@...dia.com, Mark Brown <broonie@...ian.org>,
	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>
Subject: Re: [PATCH 1/3] spi: tegra210-quad: use device_reset_optional()
 instead of device_reset()

On Tue, Mar 25, 2025 at 06:05:28PM +0100, Thierry Reding wrote:

> > I want to come back to how the driver should behave. We probably want to
> > distinguish what is the correct behaviour we expect from the driver,
> > they are (IMO):
> > 
> > 1) The reset handlers are NOT optional and the device should fail to
> >    probe.
> > 
> > 2) The reset handlers ARE optional, and we should mark them as such.
> > 
> > Can you shed some light on what is the right behaviour we want to
> > implement?
> > 
> > From what I am hearing, we are more inclined towards 2). Is this
> > correct?
> 
> Yes, I think 2) is what I'd be inclined towards. _RST is clearly not
> available for at least certain firmware releases, so they are de-facto
> optional.
> 
> Even if they are ever implemented, it'd be wise to keep supporting the
> case where they are not available, so treating them as optional is the
> right way to go.

Thanks for the clarification, Thierry! 

Do you know if this reset method also optional for device tree devices?

So, these are the options we have now, based on the clarification above:

1) Mark the device_reset() as optional for this device, as proposed in
   this current patch.

2) Ignore that this is optional completely, and let that "device failed"
   message to go be displayed every time the device is probed and restarted.

3) Create an "device_reset_optional_on_acpi_but_not_on_dt()" method if
   this method is only optional on ACPI devices. Waiting on Thierry to
   clarify this part.