[PATCH AUTOSEL 6.19-5.10] HID: mcp2221: cancel last I2C command on read error

[Sasha Levin]

From: Romain Sioen <romain.sioen@xxxxxxxxxxxxx>

[ Upstream commit e31b556c0ba21f20c298aa61181b96541140b7b9 ]

When an I2C SMBus read operation fails, the MCP2221 internal state machine
may not reset correctly, causing subsequent transactions to fail.

By adding a short delay and explicitly cancelling the last command,
we ensure the device is ready for the next operation.

Fix an issue where i2cdetect was not able to detect all devices correctly
on the bus.

Signed-off-by: Romain Sioen <romain.sioen@xxxxxxxxxxxxx>
Signed-off-by: Jiri Kosina <jkosina@xxxxxxxx>
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
---

LLM Generated explanations, may be completely bogus:

Now I have a complete picture. Let me summarize the analysis.

## Analysis

### What the commit fixes

The MCP2221 is a USB-to-I2C/UART bridge chip. When an I2C SMBus read
operation exhausts its 5 retries (meaning the device didn't become
ready), the function `mcp_i2c_smbus_read` previously returned the error
immediately without cleaning up the device's internal state machine.
This left the I2C bus in a stuck state, causing subsequent I2C
transactions to fail.

The fix adds two lines before the error return:
1. `usleep_range(980, 1000)` - a small delay needed by the device
2. `mcp_cancel_last_cmd(mcp)` - sends a cancel command to reset the
   device state and free the I2C bus

### Is this a real bug fix?

Yes. The commit message explicitly states this fixes a real-world issue:
`i2cdetect` was unable to detect all devices on the bus. This is a
functional bug where failed reads leave the MCP2221 in a bad state,
breaking subsequent operations.

### Pattern consistency

The fix follows the **exact same pattern** already used in two other
places in the same driver:
1. `mcp_chk_last_cmd_status_free_bus()` (line 225-226):
   `usleep_range(980, 1000)` + `mcp_cancel_last_cmd(mcp)` on error
2. `mcp_set_i2c_speed()` (line 244-245): same pattern on error

This is simply adding the same established error recovery to a path that
was missing it.

### Scope and risk

- **2 lines added** - extremely small and surgical
- **No behavioral change** on the success path
- Only affects the error path after all 5 retries are exhausted
- Uses well-established functions already present in the driver
- Low risk of regression - the alternative (not cancelling) is already
  broken

### Stable criteria assessment

- **Obviously correct**: Follows the same pattern used elsewhere in the
  driver for the same purpose
- **Fixes a real bug**: I2C bus gets stuck, preventing device detection
- **Small and contained**: 2 lines added, single file, single error path
- **No new features**: Just error recovery

### Verification

- git log confirmed this is commit b4664742e46dc, merged recently
- Read the full `mcp_cancel_last_cmd()` function at line 204-211: sends
  `MCP2221_I2C_CANCEL` to reset device state
- Read `mcp_chk_last_cmd_status_free_bus()` at line 216-230: confirms
  the same `usleep + cancel` pattern is established
- Read `mcp_set_i2c_speed()` at line 232-249: confirms the same pattern
  in a third location
- The fix is self-contained with no dependencies on other commits
- The `mcp_cancel_last_cmd` function has existed since at least v6.1
  (introduced with the read refactoring), so it's available in stable
  trees
- Author is from Microchip (the chip vendor), adding credibility to the
  fix

**YES**

 drivers/hid/hid-mcp2221.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index 33603b019f975..ef3b5c77c38e3 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -353,6 +353,8 @@ static int mcp_i2c_smbus_read(struct mcp2221 *mcp,
 				usleep_range(90, 100);
 				retries++;
 			} else {
+				usleep_range(980, 1000);
+				mcp_cancel_last_cmd(mcp);
 				return ret;
 			}
 		} else {
-- 
2.51.0