From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f99.google.com (mail-dl1-f99.google.com [74.125.82.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 22B6C31E107 for ; Thu, 7 May 2026 16:49:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.99 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778172601; cv=none; b=IrWHV9xiBJBEHNJVabVJm1NVDzdC6sgIwHl/4OpRhwYWVsbfcZ8+P9UrWHQIeSFXTJ9LTD0hGcqna8t2dz+90soqOaqFBn2Znh67fmFCLz/5mxggc4sIey/FcqwXGcUDzqt5+gwtYDgdq7Z+nK97sJZ6K3mECU49grfYXat45so= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778172601; c=relaxed/simple; bh=g+o8Gax6yXxVJ9Ymvpwj7De47snR6AbkdQJOz9rOYXw=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=bU0LjZnl8DjwaybtFNN0kuCT2zB94qD5E+jpeb4aN7ZDNONUTtuc/2u/ZeBmWruC/oAsSRyFrIoadpM/AibLW6o8NrDHaIJx9lKng0aKDGe+KYP8JWhJ/EA7/sK0k7Qefx2d6jhLdnbIRPmzpRP7FrWNbBGgOmgjVM9J+uPTsQI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=embeddedTS.com; spf=pass smtp.mailfrom=embeddedts.com; dkim=pass (1024-bit key) header.d=embeddedts.com header.i=@embeddedts.com header.b=qafyK8Cv; arc=none smtp.client-ip=74.125.82.99 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=embeddedTS.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=embeddedts.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=embeddedts.com header.i=@embeddedts.com header.b="qafyK8Cv" Received: by mail-dl1-f99.google.com with SMTP id a92af1059eb24-12713e56abdso737026c88.1 for ; Thu, 07 May 2026 09:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embeddedts.com; s=google; t=1778172598; x=1778777398; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=vqcAML0ZZ43DsvITP1E2cCodXpE6DI+947s+bAV6M6c=; b=qafyK8CvTdEgqBnkFua3jfjtE4gqMWnJD20A3y/53xiSB2VCLFidb0Fwlrxt9OvCz9 10x90hxiTV2NcaQ6QXenz6s+W2+M14dR8ZFv/S6G1v0d/h/BnFiQOZQDUH/oX7sHVwIb 0u1M49DrLmsQNHt8HljYV6AYvtB+a9VEwfb0g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778172598; x=1778777398; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vqcAML0ZZ43DsvITP1E2cCodXpE6DI+947s+bAV6M6c=; b=dyfHL9x6mKyBjIaQgF+KJrQkaY5CSbo00Xi3ox112Elp2KMuuHbt42cdIkCetJ+x79 l+cFyNwYUYn4HRn+SaTMaUosffbjgMItc1KlGQW/qvf2K5j/9L3ZSgPwryEr7AMHVpOq RxJSDPr938haulm7A3VbKgC+2qVlwo9xKO99Pbp7MHb4a465ECMgX3CrgZ+5eZQ7X79+ ud8iGudTPPWpaj45DTKaj9xj6USThMlIyMt1tK7lDEyogVikgACl/aC97gaZcmBWCLv4 9l68XW77APXllYWk2Rd/VL8WGnlR89gEEaAoNdNunFolJhhQBrxWcKd3krqjxKZJQxBF KJSg== X-Forwarded-Encrypted: i=1; AFNElJ9ItwpIXcFj6xVdr/i7A16RHiWsIxVVsU0oWg2Vj58mxmgg9TNqYct+SZ2yTEq9gltkkiqJXw19xjMMB/k=@vger.kernel.org X-Gm-Message-State: AOJu0YwpErwebNfAiC7RpAzg+yPuTCba2+7K67D+WFWhRkh9nb8Pqic0 NFt9npuqgehFhD9OmMV0VAS3M/6B+Clmo7tD2Jp5Y1cJXCrw4amRXuvAxn3vSBfPLG8Sb8jJQma BbrldBqJmXh+PjKAfv4yJ51e1PZwVnTSYIJzO X-Gm-Gg: AeBDietyKe/gbg+jEz36c3OKYmdUpxQdPJzAhtnwP+LXxrz/VmvCfmiNXguougVkiGh WYgEsEOJx7SAUb8Jq8e1XVk4STKPDSIbBE6nQ3nUfoQBRit3NxV1yeUyiFjukIZpBgmZK//e2QJ psh1RkW2Mi6xWaqNKr9dTAGb6ILOrwuHHwyGYvOAgcyg1ocFwdDf4RE54H3gSea79G5WgZl7pGz 4W1Bj3s9VX+AOL0rAp3zkaRwMT5KsTN1ZpZdoR0yXZJly7YWTOA+lfaeEHCFlwvVGaCbjRA3PS6 vZ7N2dUCbzo/RUwF6rcovlMJdjOqyDaoB3LtiVKeRuu7trvY7XbjsrYoIWx3aY/n2VCV8wB5svL KsZAovdakt5VdE64Mu9X1ZFa8/Pyz1f9e0uF19zAs3tTESk2u X-Received: by 2002:a05:7022:986:b0:12c:6ec9:3f1 with SMTP id a92af1059eb24-1323b0b726emr1668516c88.21.1778172598081; Thu, 07 May 2026 09:49:58 -0700 (PDT) Received: from tornado.. (wsip-70-191-90-18.ph.ph.cox.net. [70.191.90.18]) by smtp-relay.gmail.com with ESMTPS id a92af1059eb24-131f99a5a9dsm498874c88.4.2026.05.07.09.49.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 May 2026 09:49:58 -0700 (PDT) X-Relaying-Domain: embeddedts.com From: Kris Bahnsen To: Dmitry Torokhov , Marek Vasut Cc: Kris Bahnsen , stable@vger.kernel.org, Mark Featherston , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v4] Input: ads7846 - don't use scratch for tx_buf when clearing register Date: Thu, 7 May 2026 16:49:43 +0000 Message-Id: <20260507164943.760009-1-kris@embeddedTS.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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@vger.kernel.org Co-developed-by: Mark Featherston Signed-off-by: Mark Featherston Signed-off-by: Kris Bahnsen --- 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. drivers/input/touchscreen/ads7846.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c index 4b39f7212d35..1ae1ae42582a 100644 --- a/drivers/input/touchscreen/ads7846.c +++ b/drivers/input/touchscreen/ads7846.c @@ -325,7 +325,6 @@ struct ser_req { u8 ref_on; u8 command; u8 ref_off; - u16 scratch; struct spi_message msg; struct spi_transfer xfer[8]; /* @@ -333,6 +332,7 @@ struct ser_req { * transfer buffers to live in their own cache lines. */ __be16 sample ____cacheline_aligned; + u16 scratch; }; struct ads7845_ser_req { @@ -403,8 +403,7 @@ static int ads7846_read12_ser(struct device *dev, unsigned command) spi_message_add_tail(&req->xfer[5], &req->msg); /* clear the command register */ - req->scratch = 0; - req->xfer[6].tx_buf = &req->scratch; + req->xfer[6].rx_buf = &req->scratch; req->xfer[6].len = 1; spi_message_add_tail(&req->xfer[6], &req->msg); base-commit: dd6c438c3e64a5ff0b5d7e78f7f9be547803ef1b -- 2.34.1