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
