On Tue, Mar 18, 2025 at 09:07:28PM +0100, Arnd Bergmann wrote: > On Tue, Mar 18, 2025, at 20:13, Mark Brown wrote: > > 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. Modulo the probe deferral it does make a degree of sense in the probe function since there's a reasonable chance things are in a reset state by virtue of never having been touched since power on, you do see things like this as a transition measure. > In case of a broken ACPI table, this would simply fail the > probe() with an error, which seems like a sensible behavior. Yes. If we need to support these ACPI tables the driver will need to learn how to get the hardware back into default state itself, assuming that's possible and there's no FIFO clearing issues or anything.
Attachment:
signature.asc
Description: PGP signature
