From a67708418d3af9ea8246dde58cb618492751a2e9 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 2 Sep 2025 14:21:35 +0200 Subject: [PATCH] 5.15-stable patches added patches: hid-mcp2221-don-t-set-bus-speed-on-every-transfer.patch hid-mcp2221-handle-reads-greater-than-60-bytes.patch revert-drm-dp-change-aux-dpcd-probe-address-from-dpcd_rev-to-lane0_1_status.patch --- ...on-t-set-bus-speed-on-every-transfer.patch | 126 ++++++++++++++++++ ...1-handle-reads-greater-than-60-bytes.patch | 104 +++++++++++++++ ...ress-from-dpcd_rev-to-lane0_1_status.patch | 40 ++++++ queue-5.15/series | 3 + 4 files changed, 273 insertions(+) create mode 100644 queue-5.15/hid-mcp2221-don-t-set-bus-speed-on-every-transfer.patch create mode 100644 queue-5.15/hid-mcp2221-handle-reads-greater-than-60-bytes.patch create mode 100644 queue-5.15/revert-drm-dp-change-aux-dpcd-probe-address-from-dpcd_rev-to-lane0_1_status.patch diff --git a/queue-5.15/hid-mcp2221-don-t-set-bus-speed-on-every-transfer.patch b/queue-5.15/hid-mcp2221-don-t-set-bus-speed-on-every-transfer.patch new file mode 100644 index 0000000000..74aa703ce0 --- /dev/null +++ b/queue-5.15/hid-mcp2221-don-t-set-bus-speed-on-every-transfer.patch @@ -0,0 +1,126 @@ +From 02a46753601a24e1673d9c28173121055e8e6cc9 Mon Sep 17 00:00:00 2001 +From: Hamish Martin +Date: Wed, 25 Oct 2023 16:55:13 +1300 +Subject: HID: mcp2221: Don't set bus speed on every transfer + +From: Hamish Martin + +commit 02a46753601a24e1673d9c28173121055e8e6cc9 upstream. + +Since the initial commit of this driver the I2C bus speed has been +reconfigured for every single transfer. This is despite the fact that we +never change the speed and it is never "lost" by the chip. +Upon investigation we find that what was really happening was that the +setting of the bus speed had the side effect of cancelling a previous +failed command if there was one, thereby freeing the bus. This is the +part that was actually required to keep the bus operational in the face +of failed commands. + +Instead of always setting the speed, we now correctly cancel any failed +commands as they are detected. This means we can just set the bus speed +at probe time and remove the previous speed sets on each transfer. +This has the effect of improving performance and reducing the number of +commands required to complete transfers. + +Signed-off-by: Hamish Martin +Signed-off-by: Jiri Kosina +Fixes: 67a95c21463d ("HID: mcp2221: add usb to i2c-smbus host bridge") +[romain.sioen@microchip.com: backport to stable, up to 6.8. Add "Fixes" tag] +Signed-off-by: Romain Sioen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hid/hid-mcp2221.c | 41 +++++++++++++++++++++++++++-------------- + 1 file changed, 27 insertions(+), 14 deletions(-) + +--- a/drivers/hid/hid-mcp2221.c ++++ b/drivers/hid/hid-mcp2221.c +@@ -169,6 +169,25 @@ static int mcp_cancel_last_cmd(struct mc + return mcp_send_data_req_status(mcp, mcp->txbuf, 8); + } + ++/* Check if the last command succeeded or failed and return the result. ++ * If the command did fail, cancel that command which will free the i2c bus. ++ */ ++static int mcp_chk_last_cmd_status_free_bus(struct mcp2221 *mcp) ++{ ++ int ret; ++ ++ ret = mcp_chk_last_cmd_status(mcp); ++ if (ret) { ++ /* The last command was a failure. ++ * Send a cancel which will also free the bus. ++ */ ++ usleep_range(980, 1000); ++ mcp_cancel_last_cmd(mcp); ++ } ++ ++ return ret; ++} ++ + static int mcp_set_i2c_speed(struct mcp2221 *mcp) + { + int ret; +@@ -223,7 +242,7 @@ static int mcp_i2c_write(struct mcp2221 + usleep_range(980, 1000); + + if (last_status) { +- ret = mcp_chk_last_cmd_status(mcp); ++ ret = mcp_chk_last_cmd_status_free_bus(mcp); + if (ret) + return ret; + } +@@ -290,7 +309,7 @@ static int mcp_i2c_smbus_read(struct mcp + if (ret) + return ret; + +- ret = mcp_chk_last_cmd_status(mcp); ++ ret = mcp_chk_last_cmd_status_free_bus(mcp); + if (ret) + return ret; + +@@ -310,11 +329,6 @@ static int mcp_i2c_xfer(struct i2c_adapt + + mutex_lock(&mcp->lock); + +- /* Setting speed before every transaction is required for mcp2221 */ +- ret = mcp_set_i2c_speed(mcp); +- if (ret) +- goto exit; +- + if (num == 1) { + if (msgs->flags & I2C_M_RD) { + ret = mcp_i2c_smbus_read(mcp, msgs, MCP2221_I2C_RD_DATA, +@@ -399,9 +413,7 @@ static int mcp_smbus_write(struct mcp222 + if (last_status) { + usleep_range(980, 1000); + +- ret = mcp_chk_last_cmd_status(mcp); +- if (ret) +- return ret; ++ ret = mcp_chk_last_cmd_status_free_bus(mcp); + } + + return ret; +@@ -419,10 +431,6 @@ static int mcp_smbus_xfer(struct i2c_ada + + mutex_lock(&mcp->lock); + +- ret = mcp_set_i2c_speed(mcp); +- if (ret) +- goto exit; +- + switch (size) { + + case I2C_SMBUS_QUICK: +@@ -870,6 +878,11 @@ static int mcp2221_probe(struct hid_devi + if (i2c_clk_freq < 50) + i2c_clk_freq = 50; + mcp->cur_i2c_clk_div = (12000000 / (i2c_clk_freq * 1000)) - 3; ++ ret = mcp_set_i2c_speed(mcp); ++ if (ret) { ++ hid_err(hdev, "can't set i2c speed: %d\n", ret); ++ return ret; ++ } + + mcp->adapter.owner = THIS_MODULE; + mcp->adapter.class = I2C_CLASS_HWMON; diff --git a/queue-5.15/hid-mcp2221-handle-reads-greater-than-60-bytes.patch b/queue-5.15/hid-mcp2221-handle-reads-greater-than-60-bytes.patch new file mode 100644 index 0000000000..121316941c --- /dev/null +++ b/queue-5.15/hid-mcp2221-handle-reads-greater-than-60-bytes.patch @@ -0,0 +1,104 @@ +From 2682468671aa0b4d52ae09779b48212a80d71b91 Mon Sep 17 00:00:00 2001 +From: Hamish Martin +Date: Wed, 25 Oct 2023 16:55:14 +1300 +Subject: HID: mcp2221: Handle reads greater than 60 bytes + +From: Hamish Martin + +commit 2682468671aa0b4d52ae09779b48212a80d71b91 upstream. + +When a user requests more than 60 bytes of data the MCP2221 must chunk +the data in chunks up to 60 bytes long (see command/response code 0x40 +in the datasheet). +In order to signal that the device has more data the (undocumented) byte +at byte index 2 of the Get I2C Data response uses the value 0x54. This +contrasts with the case for the final data chunk where the value +returned is 0x55 (MCP2221_I2C_READ_COMPL). The fact that 0x55 was not +returned in the response was interpreted by the driver as a failure +meaning that all reads of more than 60 bytes would fail. + +Add support for reads that are split over multiple chunks by looking for +the response code indicating that more data is expected and continuing +the read as the code intended. Some timing delays are required to ensure +the chip has time to refill its FIFO as data is read in from the I2C +bus. This timing has been tested in my system when configured for bus +speeds of 50KHz, 100KHz, and 400KHz and operates well. + +Signed-off-by: Hamish Martin +Signed-off-by: Jiri Kosina +Fixes: 67a95c21463d0 ("HID: mcp2221: add usb to i2c-smbus host bridge") +[romain.sioen@microchip.com: backport to stable, up to 6.8. Add "Fixes" tag] +Signed-off-by: Romain Sioen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hid/hid-mcp2221.c | 32 +++++++++++++++++++++++--------- + 1 file changed, 23 insertions(+), 9 deletions(-) + +--- a/drivers/hid/hid-mcp2221.c ++++ b/drivers/hid/hid-mcp2221.c +@@ -44,6 +44,7 @@ enum { + MCP2221_I2C_MASK_ADDR_NACK = 0x40, + MCP2221_I2C_WRADDRL_SEND = 0x21, + MCP2221_I2C_ADDR_NACK = 0x25, ++ MCP2221_I2C_READ_PARTIAL = 0x54, + MCP2221_I2C_READ_COMPL = 0x55, + MCP2221_ALT_F_NOT_GPIOV = 0xEE, + MCP2221_ALT_F_NOT_GPIOD = 0xEF, +@@ -279,6 +280,7 @@ static int mcp_i2c_smbus_read(struct mcp + { + int ret; + u16 total_len; ++ int retries = 0; + + mcp->txbuf[0] = type; + if (msg) { +@@ -302,20 +304,31 @@ static int mcp_i2c_smbus_read(struct mcp + mcp->rxbuf_idx = 0; + + do { ++ /* Wait for the data to be read by the device */ ++ usleep_range(980, 1000); ++ + memset(mcp->txbuf, 0, 4); + mcp->txbuf[0] = MCP2221_I2C_GET_DATA; + + ret = mcp_send_data_req_status(mcp, mcp->txbuf, 1); +- if (ret) +- return ret; +- +- ret = mcp_chk_last_cmd_status_free_bus(mcp); +- if (ret) +- return ret; +- +- usleep_range(980, 1000); ++ if (ret) { ++ if (retries < 5) { ++ /* The data wasn't ready to read. ++ * Wait a bit longer and try again. ++ */ ++ usleep_range(90, 100); ++ retries++; ++ } else { ++ return ret; ++ } ++ } else { ++ retries = 0; ++ } + } while (mcp->rxbuf_idx < total_len); + ++ usleep_range(980, 1000); ++ ret = mcp_chk_last_cmd_status_free_bus(mcp); ++ + return ret; + } + +@@ -776,7 +789,8 @@ static int mcp2221_raw_event(struct hid_ + mcp->status = -EIO; + break; + } +- if (data[2] == MCP2221_I2C_READ_COMPL) { ++ if (data[2] == MCP2221_I2C_READ_COMPL || ++ data[2] == MCP2221_I2C_READ_PARTIAL) { + buf = mcp->rxbuf; + memcpy(&buf[mcp->rxbuf_idx], &data[4], data[3]); + mcp->rxbuf_idx = mcp->rxbuf_idx + data[3]; diff --git a/queue-5.15/revert-drm-dp-change-aux-dpcd-probe-address-from-dpcd_rev-to-lane0_1_status.patch b/queue-5.15/revert-drm-dp-change-aux-dpcd-probe-address-from-dpcd_rev-to-lane0_1_status.patch new file mode 100644 index 0000000000..67245802b5 --- /dev/null +++ b/queue-5.15/revert-drm-dp-change-aux-dpcd-probe-address-from-dpcd_rev-to-lane0_1_status.patch @@ -0,0 +1,40 @@ +From imre.deak@intel.com Tue Sep 2 13:49:03 2025 +From: Imre Deak +Date: Thu, 28 Aug 2025 20:49:27 +0300 +Subject: Revert "drm/dp: Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS" +To: +Cc: , , Sasha Levin + +From: Imre Deak + +This reverts commit a19b31f854a8992dfa35255f43efd19be292b15c which is +commit a40c5d727b8111b5db424a1e43e14a1dcce1e77f upstream. + +The upstream commit a40c5d727b8111b5db424a1e43e14a1dcce1e77f ("drm/dp: +Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS") the +reverted commit backported causes a regression, on one eDP panel at +least resulting in display flickering, described in detail at the Link: +below. The issue fixed by the upstream commit will need a different +solution, revert the backport for now. + +Cc: intel-gfx@lists.freedesktop.org +Cc: dri-devel@lists.freedesktop.org +Cc: Sasha Levin +Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14558 +Signed-off-by: Imre Deak +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/drm_dp_helper.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/drm_dp_helper.c ++++ b/drivers/gpu/drm/drm_dp_helper.c +@@ -336,7 +336,7 @@ ssize_t drm_dp_dpcd_read(struct drm_dp_a + * monitor doesn't power down exactly after the throw away read. + */ + if (!aux->is_remote) { +- ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, DP_LANE0_1_STATUS, ++ ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, DP_DPCD_REV, + buffer, 1); + if (ret != 1) + goto out; diff --git a/queue-5.15/series b/queue-5.15/series index 66cf0b6a73..14f8054021 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -27,3 +27,6 @@ revert-drm-amdgpu-fix-incorrect-vm-flags-to-map-bo.patch dma-pool-ensure-dma_direct_remap-allocations-are-decrypted.patch net-usb-qmi_wwan-add-telit-cinterion-le910c4-wwx-new-compositions.patch drm-nouveau-disp-always-accept-linear-modifier.patch +hid-mcp2221-don-t-set-bus-speed-on-every-transfer.patch +hid-mcp2221-handle-reads-greater-than-60-bytes.patch +revert-drm-dp-change-aux-dpcd-probe-address-from-dpcd_rev-to-lane0_1_status.patch -- 2.47.3