On Tue, Mar 18, 2025 at 10:02:47AM -0700, Breno Leitao wrote: > Makes sense. Another question, for platforms like this one that doesn't > have the device reset methods, what can we do to stop the bleed? > Basically every message that is sent to the SPI controller will fail, > which will trigger the device_reet() which is a no-op, but the device > will continue to be online. Should we disable the device after some > point? The SPI controller is only going to be doing something because some driver for an attached SPI device is trying to do something. Presumably whatever driver that is won't be having a good time and can hopefully figure something out, though given that SPI is simple and not hotpluggable this isn't really something that comes up a lot in production so I'd be unsurprised to see things just keep on retrying. I'd expect to see any substantial error handling in the driver for the device rather than in the controller. Obviously there's something wrong with the device description here which is upsetting the controller driver. > Regarding this patchset, I understand that patch #1 is not ideal as > discussed above, what about patch 2 and 3? If I didn't say anything they're probably fine.
Attachment:
signature.asc
Description: PGP signature
