| Message ID | 20220221140750.514557-1-peter.maydell@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | hw/input/tsc210x: Don't abort on bad SPI word widths | expand |
Peter Maydell <peter.maydell@linaro.org> writes: > The tsc210x doesn't support anything other than 16-bit reads on the > SPI bus, but the guest can program the SPI controller to attempt > them anyway. If this happens, don't abort QEMU, just log this as > a guest error. > > This fixes our machine_arm_n8x0.py:N8x0Machine.test_n800 > acceptance test, which hits this assertion. > > The reason we hit the assertion is because the guest kernel thinks > there is a TSC2005 on this SPI bus address, not a TSC210x. (The n810 > *does* have a TSC2005 at this address.) The TSC2005 supports the > 24-bit accesses which the guest driver makes, and the TSC210x does > not (that is, our TSC210x emulation is not missing support for a word > width the hardware can handle). It's not clear whether the problem > here is that the guest kernel incorrectly thinks the n800 has the > same device at this SPI bus address as the n810, or that QEMU's n810 > board model doesn't get the SPI devices right. At this late date > there no longer appears to be any reliable information on the web > about the hardware behaviour, but I am inclined to think this is a > guest kernel bug. In any case, we prefer not to abort QEMU for > guest-triggerable conditions, so logging the error is the right thing > to do. > > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/736 > Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
diff --git a/hw/input/tsc210x.c b/hw/input/tsc210x.c index 182d3725fc9..e0362d71719 100644 --- a/hw/input/tsc210x.c +++ b/hw/input/tsc210x.c @@ -23,6 +23,7 @@ #include "hw/hw.h" #include "audio/audio.h" #include "qemu/timer.h" +#include "qemu/log.h" #include "sysemu/reset.h" #include "ui/console.h" #include "hw/arm/omap.h" /* For I2SCodec */ @@ -909,8 +910,11 @@ uint32_t tsc210x_txrx(void *opaque, uint32_t value, int len) TSC210xState *s = opaque; uint32_t ret = 0; - if (len != 16) - hw_error("%s: FIXME: bad SPI word width %i\n", __func__, len); + if (len != 16) { + qemu_log_mask(LOG_GUEST_ERROR, + "%s: bad SPI word width %i\n", __func__, len); + return 0; + } /* TODO: sequential reads etc - how do we make sure the host doesn't * unintentionally read out a conversion result from a register while
The tsc210x doesn't support anything other than 16-bit reads on the SPI bus, but the guest can program the SPI controller to attempt them anyway. If this happens, don't abort QEMU, just log this as a guest error. This fixes our machine_arm_n8x0.py:N8x0Machine.test_n800 acceptance test, which hits this assertion. The reason we hit the assertion is because the guest kernel thinks there is a TSC2005 on this SPI bus address, not a TSC210x. (The n810 *does* have a TSC2005 at this address.) The TSC2005 supports the 24-bit accesses which the guest driver makes, and the TSC210x does not (that is, our TSC210x emulation is not missing support for a word width the hardware can handle). It's not clear whether the problem here is that the guest kernel incorrectly thinks the n800 has the same device at this SPI bus address as the n810, or that QEMU's n810 board model doesn't get the SPI devices right. At this late date there no longer appears to be any reliable information on the web about the hardware behaviour, but I am inclined to think this is a guest kernel bug. In any case, we prefer not to abort QEMU for guest-triggerable conditions, so logging the error is the right thing to do. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/736 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> --- hw/input/tsc210x.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)