From: Michael Zaidman <michael.zaidman@gmail.com>
To: Jiri Kosina <jikos@kernel.org>, Benjamin Tissoires <bentiss@kernel.org>
Cc: Linus Walleij <linusw@kernel.org>,
Bartosz Golaszewski <brgl@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jirislaby@kernel.org>,
Raman Varabets <kernel-linux-20260610-80b7ab08@raman.v1.sg>,
Germain Hebert <germain.hebert@ca.abb.com>,
Christina Quast <contact@christina-quast.de>,
Rio Liu <rio@r26.me>, Bruno Giacomazzi <brunoceg1@gmail.com>,
linux-input@vger.kernel.org, linux-serial@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-i2c@vger.kernel.org,
linux-kernel@vger.kernel.org,
Michael Zaidman <michael.zaidman@gmail.com>,
Chris Keeser <chriskeeser@meta.com>
Subject: [PATCH v2 10/15] HID: ft260: i2c: fix large write transaction failure
Date: Sat, 31 Oct 2026 00:36:32 +0200 [thread overview]
Message-ID: <20261030223637.86907-11-michael.zaidman@gmail.com> (raw)
In-Reply-To: <20261030223637.86907-1-michael.zaidman@gmail.com>
Fixes a regression from commit 5afac727defa ("HID: ft260: missed NACK
from busy device"), which waited for bus-idle after every HID write
report except when the report flag was exactly FT260_FLAG_START.
Multi-report I2C writes keep the bus busy between chunks for atomicity.
Treating those middle reports like a final STOP caused ft260_xfer_status()
to spin on -EAGAIN after the second HID report and fail large writes.
Write-then-read combined transfers still worked.
Pass the bus-busy check policy from the caller: ft260_i2c_write() and
ft260_smbus_write() wait for idle only when the report they send carries
STOP; intermediate chunks and the command phase of a combined transfer
do not.
The SMBus side matters for register reads. The command phase is written
with FT260_FLAG_START and no STOP, because a repeated START read follows
and the controller deliberately keeps the bus busy to keep the
transaction atomic. Checking the busy bit there makes
ft260_xfer_status() return -EAGAIN on every retry and the command write
fail with -EIO, which breaks probing of clients that read registers:
ads1x19 6-0040: Failed to read config register: -5
leds-pca963x: probe of 6-0008 failed with error -5
Fixes: 5afac727defa ("HID: ft260: missed NACK from busy device")
Reported-by: Chris Keeser <chriskeeser@meta.com>
Closes: https://github.com/MichaelZaidman/hid-ft260/issues/35
Tested-by: Chris Keeser <chriskeeser@meta.com>
Reported-by: Bruno Giacomazzi <brunoceg1@gmail.com>
Closes: https://github.com/MichaelZaidman/hid-ft260/issues/42
Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
---
drivers/hid/hid-ft260.c | 35 ++++++++++++++++-------------------
1 file changed, 16 insertions(+), 19 deletions(-)
diff --git a/drivers/hid/hid-ft260.c b/drivers/hid/hid-ft260.c
index dca0250f2c25..65835e13fa2a 100644
--- a/drivers/hid/hid-ft260.c
+++ b/drivers/hid/hid-ft260.c
@@ -576,9 +576,14 @@ static int ft260_xfer_status(struct ft260_device *dev, u8 bus_busy)
}
dev->clock = le16_to_cpu(report.clock);
- ft260_dbg("bus_status %#02x, clock %u\n", report.bus_status,
- dev->clock);
+ ft260_dbg("bus_status %#02x, clock %u, bus_busy %#02x\n",
+ report.bus_status, dev->clock, bus_busy);
+ /*
+ * Do not check the busy bit for combined transactions
+ * since the controller keeps the bus busy between writing
+ * and reading IOs to ensure an atomic operation.
+ */
if (report.bus_status & (FT260_I2C_STATUS_CTRL_BUSY | bus_busy))
return -EAGAIN;
@@ -612,13 +617,10 @@ static int ft260_hid_output_report(struct hid_device *hdev, u8 *data,
}
static int ft260_hid_output_report_check_status(struct ft260_device *dev,
- u8 *data, int len)
+ u8 *data, int len, u8 bus_busy)
{
- u8 bus_busy;
int ret, usec, try = 100;
struct hid_device *hdev = dev->hdev;
- struct ft260_i2c_write_request_report *rep =
- (struct ft260_i2c_write_request_report *)data;
ret = ft260_hid_output_report(hdev, data, len);
if (ret < 0) {
@@ -635,16 +637,6 @@ static int ft260_hid_output_report_check_status(struct ft260_device *dev,
ft260_dbg("wait %d usec, len %d\n", usec, len);
}
- /*
- * Do not check the busy bit for combined transactions
- * since the controller keeps the bus busy between writing
- * and reading IOs to ensure an atomic operation.
- */
- if (rep->flag == FT260_FLAG_START)
- bus_busy = 0;
- else
- bus_busy = FT260_I2C_STATUS_BUS_BUSY;
-
do {
ret = ft260_xfer_status(dev, bus_busy);
if (ret != -EAGAIN)
@@ -661,6 +653,7 @@ static int ft260_hid_output_report_check_status(struct ft260_device *dev,
static int ft260_i2c_write(struct ft260_device *dev, u8 addr, u8 *data,
int len, u8 flag)
{
+ u8 bus_busy = 0;
int ret, wr_len, idx = 0;
struct ft260_i2c_write_request_report *rep =
(struct ft260_i2c_write_request_report *)dev->i2c_wr_buf;
@@ -673,8 +666,10 @@ static int ft260_i2c_write(struct ft260_device *dev, u8 addr, u8 *data,
do {
if (len <= FT260_WR_I2C_DATA_MAX) {
wr_len = len;
- if (flag == FT260_FLAG_START_STOP)
+ if (flag == FT260_FLAG_START_STOP) {
rep->flag |= FT260_FLAG_STOP;
+ bus_busy = FT260_I2C_STATUS_BUS_BUSY;
+ }
} else {
wr_len = FT260_WR_I2C_DATA_MAX;
}
@@ -690,7 +685,7 @@ static int ft260_i2c_write(struct ft260_device *dev, u8 addr, u8 *data,
rep->flag, data[0]);
ret = ft260_hid_output_report_check_status(dev, (u8 *)rep,
- wr_len + 4);
+ wr_len + 4, bus_busy);
if (ret < 0) {
ft260_dbg("failed with %d\n", ret);
return ret;
@@ -731,7 +726,9 @@ static int ft260_smbus_write(struct ft260_device *dev, u8 addr, u8 cmd,
ft260_dbg("rep %#02x addr %#02x cmd %#02x datlen %d replen %d\n",
rep->report, addr, cmd, rep->length, len);
- ret = ft260_hid_output_report_check_status(dev, (u8 *)rep, len);
+ ret = ft260_hid_output_report_check_status(dev, (u8 *)rep, len,
+ (flag & FT260_FLAG_STOP) ?
+ FT260_I2C_STATUS_BUS_BUSY : 0);
if (ret < 0)
ft260_dbg("failed with %d\n", ret);
--
2.43.0
next prev parent reply other threads:[~2026-10-30 22:37 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-30 22:36 [PATCH v2 00/15] HID: ft260: add UART and GPIO support, plus I2C fixes Michael Zaidman
2026-10-30 22:36 ` [PATCH v2 01/15] HID: ft260: add serial driver Michael Zaidman
2026-10-30 23:00 ` sashiko-bot
2026-10-30 22:36 ` [PATCH v2 02/15] HID: ft260: uart: fix the " Michael Zaidman
2026-10-30 23:03 ` sashiko-bot
2026-10-30 22:36 ` [PATCH v2 03/15] HID: ft260: add GPIO support Michael Zaidman
2026-10-30 22:53 ` sashiko-bot
2026-10-30 22:36 ` [PATCH v2 04/15] HID: ft260: i2c: reduce driver module loading time Michael Zaidman
2026-10-30 22:44 ` sashiko-bot
2026-10-30 22:36 ` [PATCH v2 05/15] HID: ft260: i2c: silence sysfs store big-numbers Michael Zaidman
2026-10-30 22:47 ` sashiko-bot
2026-10-30 22:36 ` [PATCH v2 06/15] HID: ft260: i2c: reduce bus-error message severity Michael Zaidman
2026-10-30 22:44 ` sashiko-bot
2026-10-30 22:36 ` [PATCH v2 07/15] HID: ft260: uart: enable flow control Michael Zaidman
2026-10-30 22:47 ` sashiko-bot
2026-10-30 22:36 ` [PATCH v2 08/15] HID: ft260: uart: add modem pins control via ioctl Michael Zaidman
2026-10-30 22:55 ` sashiko-bot
2026-10-30 22:36 ` [PATCH v2 09/15] HID: ft260: group sysfs attrs per HID interface Michael Zaidman
2026-10-30 22:48 ` sashiko-bot
2026-10-30 22:36 ` Michael Zaidman [this message]
2026-10-30 22:43 ` [PATCH v2 10/15] HID: ft260: i2c: fix large write transaction failure sashiko-bot
2026-10-30 22:36 ` [PATCH v2 11/15] HID: ft260: workaround for TN_189 errata endpoint STALL after enumeration Michael Zaidman
2026-10-30 22:59 ` sashiko-bot
2026-10-30 22:36 ` [PATCH v2 12/15] HID: ft260: i2c: abort in-flight transfers with STOP before reset Michael Zaidman
2026-10-30 22:49 ` sashiko-bot
2026-10-30 22:36 ` [PATCH v2 13/15] HID: ft260: i2c: reject an I2C clock outside the supported range Michael Zaidman
2026-10-30 22:47 ` sashiko-bot
2026-10-30 22:36 ` [PATCH v2 14/15] HID: ft260: i2c: fix i2c_reset sysfs store return value Michael Zaidman
2026-10-30 22:48 ` sashiko-bot
2026-10-30 22:36 ` [PATCH v2 15/15] HID: ft260: i2c: recover a bus held by a slave Michael Zaidman
2026-10-30 22:59 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261030223637.86907-11-michael.zaidman@gmail.com \
--to=michael.zaidman@gmail.com \
--cc=bentiss@kernel.org \
--cc=brgl@kernel.org \
--cc=brunoceg1@gmail.com \
--cc=chriskeeser@meta.com \
--cc=contact@christina-quast.de \
--cc=germain.hebert@ca.abb.com \
--cc=gregkh@linuxfoundation.org \
--cc=jikos@kernel.org \
--cc=jirislaby@kernel.org \
--cc=kernel-linux-20260610-80b7ab08@raman.v1.sg \
--cc=linusw@kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=rio@r26.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox