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

[Kris Bahnsen <kris@embeddedts.com>]

Dmitry,

On 4/29/26 12:19 PM, Dmitry Torokhov wrote:
> On Mon, Apr 27, 2026 at 05:46:57PM +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. Also set rx_buf to NULL because the value
>> returned does not matter. Thus moving the 3 byte pattern to clear
>> the command register to a single message.
> 
> Unfortunately my suggestion was flawed: I think this will flood the logs
> with "Bufferless transfer has length %3". We need to have either tx or
> rx buffer :(

Ah. I do see that dev_err() line in spi_transfer_one_message().
All of my testing up to this point has been with an SPI host driver
that implements its own transfer_one() operation so that error
was never actually reached.

I'll send a v3 today that reverts back to the two separate xfers,
using scratch for the rx_buf, and then NULL for tx_buf. That
sounds like that should be the path of least resistance.

> 
> Thanks.
> 

-- 
Kris Bahnsen
Software Engineer
embeddedTS