summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/bin/task-analyzer-record
diff options
context:
space:
mode:
authorVincent Jardin <vjardin@free.fr>2026-07-13 20:11:59 +0200
committerAndi Shyti <andi.shyti@kernel.org>2026-07-14 16:39:39 +0200
commitcb2fc37857693b55909fb77dc2c87cfbc1cdc476 (patch)
treecd412c91ed352e7d5e4565a356482cda7fc5a0d3 /tools/perf/scripts/python/bin/task-analyzer-record
parent627b6c94b817c2ee00c854d102a5da08105ad0a7 (diff)
i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)
SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range. Fixes: 8e8782c71595 ("i2c: imx: add SMBus block read support") Signed-off-by: Vincent Jardin <vjardin@free.fr> Cc: <stable@vger.kernel.org> # v3.16+ Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Acked-by: Carlos Song <carlos.song@nxp.com> Reviewed-by: Stefan Eichenberger <eichest@gmail.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260713-for-upstream-i2c-lx2160-fix-v1-v3-1-073ac9e103a5@free.fr
Diffstat (limited to 'tools/perf/scripts/python/bin/task-analyzer-record')
0 files changed, 0 insertions, 0 deletions