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(-)

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
-- 
2.25.1

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>

-- 
Alex Bennée