hw/input/tsc210x: Don't abort on bad SPI word widths
commitbad187dfcb0834dd67d1bfa40a305a08f0d5641a
authorPeter Maydell <peter.maydell@linaro.org>
Mon, 21 Feb 2022 14:07:50 +0000 (21 14:07 +0000)
committerPeter Maydell <peter.maydell@linaro.org>
Wed, 2 Mar 2022 19:27:36 +0000 (2 19:27 +0000)
tree1ced7099c3c99f1efd58573636982931df8e9422
parente212fb05cd2694fdb7a20abe8f0968715d67f9e5
hw/input/tsc210x: Don't abort on bad SPI word widths

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>
Message-id: 20220221140750.514557-1-peter.maydell@linaro.org
hw/input/tsc210x.c