Re: [PATCH v4] Input: ads7846 - don't use scratch for tx_buf when clearing register

[Dmitry Torokhov]

On Thu, May 07, 2026 at 04:49:43PM +0000, Kris Bahnsen wrote:
> The workaround for XPT2046 clears the command register, giving the
> touchscreen controller a NOP. The change incorrectly re-uses the
> req->scratch variable which is used as rx_buf for xfer[5], so by
> the time xfer[6] occurs, the contents of req->scratch may not be
> 0. It was found that the touchscreen controller can end up in
> a completely unresponsive state due to it being given a command
> the driver does not expect.
> 
> Instead, rely on the spi_transfer behavior of tx_buf being NULL to
> transmit all 0 bits and use the scratch variable for the rx_buf for
> both the 1 byte command to and 2 byte response from the controller.
> 
> Also relocates the scratch member of struct ser_req to force it
> into a different cache line to prevent any potential issues of
> DMA stepping on unrelated data in other struct members due to
> sharing the same cache line.
> 
> This change was tested on real TSC2046 and ADS7843 controllers,
> but not the XPT2046 the workaround was originally created for.
> Confirming that the original modification to clear the command
> register does not impact either real controller.
> 
> Fixes: 781a07da9bb94 ("Input: ads7846 - add dummy command register clearing cycle")
> Cc: stable@xxxxxxxxxxxxxxx
> Co-developed-by: Mark Featherston <mark@xxxxxxxxxxxxxx>
> Signed-off-by: Mark Featherston <mark@xxxxxxxxxxxxxx>
> Signed-off-by: Kris Bahnsen <kris@xxxxxxxxxxxxxx>
> ---
> 
> V1 -> V2: Don't use rx_buf when clearing command reg
> V2 -> V3: Modify original 2 xfer command to eliminate dev_err()
>           output on xfer with len and NULL buffers
> V3 -> V4: Move scratch to end of ser_req to force it to a new
>           cache line.
> 
> V4 Note:  Change to moving scratch was tested against an SPI
>           controller without DMA. We do not currently have a
>           platform using this controller on an SPI bus supporting
>           DMA.


Marek, any chance you could give it a quick spin?

Thanks!

-- 
Dmitry