From nobody Thu Sep 24 13:43:36 2026 Received: from mail-dl2-f43.google.com (mail-dl2-f43.google.com [74.125.229.171]) (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 6B91C395DA9 for ; Thu, 24 Sep 2026 01:45:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.229.171 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790214345; cv=none; b=J6m3lbjxZc50+D4MdWdmxfNZhMtze4kkhn0HU5H5cWIR3uv2lUOX7cFRoDL1ysRdob1xp/+a+gMWfDyCvE8VJlK+HnWEWXgPhYLGL3Po6DvavrB3NMBl0cwrh+TH8/BQm/WyBfaLnJ25mJy0u9atEzw4klN3iYkKUk+MdYv5lMs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790214345; c=relaxed/simple; bh=k/4jwuXnA12hp9k1BEvLCcEgKt2ybI+KTJlDgEkJj5E=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Wgq6qBLfwiIcUus/91EE22NYgCg42dtY3JO0h2G4yvG5I4bcCDM/2Qa0zNBB2+SudqNE2Ihs1smCJZ1+iarvlhsP5MMMDikgBpJT2024bXGMRn89ExJ+BGmHGeNZTLZxIY9ZYvERmuf4k5POUdfEXimCqlFGEKreHBKxd82CjPg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nexthop.ai; spf=pass smtp.mailfrom=nexthop.ai; dkim=pass (2048-bit key) header.d=nexthop.ai header.i=@nexthop.ai header.b=T0LYpTHF; arc=none smtp.client-ip=74.125.229.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nexthop.ai Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=nexthop.ai Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=nexthop.ai header.i=@nexthop.ai header.b="T0LYpTHF" Received: by mail-dl2-f43.google.com with SMTP id a92af1059eb24-1450541ab18so155417c88.0 for ; Wed, 23 Sep 2026 18:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nexthop.ai; s=google; t=1790214342; x=1790819142; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=sciGWXbPKjaBz8QOgB5kzziZxkd6jBEVBtn6uKIW3/M=; b=T0LYpTHFQ4yxEt+FX1kOUNUw58IwY5qRRD3e7qXtuPqVLMk/IRYFB8mSVsJm0avLLy fpf8r8pDgKFfK3toxvVSCLVXmOSwjjG4N6VZ33YzUgWhKXra7VXoEBf609dg9ns3TBxt oL+Y2qspSzzFXSdh0cU4Yoj+9pgg+gjnRXH/8dLXnF1OObo/W4Q+sLHfqO6XOhvI8rcA qMV1jw3K0Q57RziB6sR1o4kRQmnSHwjTWlXrWWdq5fvyfMKigKmkyVhiu4xTFlK6/4Ue 4jcm+4LsYLwVq5iUffHsUHenJgbzZucq62UhRuMNk5t9b4POnEyhSlxWSlwYNFHot61d WIDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790214342; x=1790819142; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=sciGWXbPKjaBz8QOgB5kzziZxkd6jBEVBtn6uKIW3/M=; b=OeMsKUi+TdLD2+/NRCbQbZDaKkpDAKROUxCVcAR1Wk1gCEc/a0uew7WlV1MVBrc61k kRqpZY6fYoTz2vk5QugXKd9AF8PYTIMUDqzSg+y8h9SgYEPEFZlAwhzyubZtqQVpcCfb FR9r+NhDuntHp/eOwI0l+OOIl72tB/NmdbOjFSKjd4bk+s8TAPW8bH4Uol/S9kmRXV5G qRRvBNenRXb97eNQZ6K/ehSAbhV7UlXmqQ0rexul7iioYh8Uqs4250A8K1DZiL5sXcUG dIyYjCRTKBeylo8fk6Ny2C0i7L0yL22/PtJaA9wVz6iVkAQbBESWxoR0b++iminOztlL 2phQ== X-Forwarded-Encrypted: i=1; AKwUvBzMX7fWeeZhmjCfsFYhT6lPKcwnMpaGgQP3L6sjwsbhnFx/S8htK2u2xUCgvIQ6j2JqrmDD1889Bvevzpg=@vger.kernel.org X-Gm-Message-State: AFuF++m+gZV8nJM8D84IBpHVn/KE82rjK77bobDc2N8MJfdHE+F+3rYU h3l7CbnLBr5G3KY19TY5skoR3mtBZKKFusmtF/pza3xj0lH4T3FuClu1fqisf1i/oCPg2NL3VBE D2s1gJxw= X-Gm-Gg: AYBFou2lhC37PttSwgNJT+AIBrZF69e9KOx+sH7MQHzH0Av9pPNLSAHWrEBobGZS1Uk LrpnNJ/IhSFWxLQzg/r5KPGK0uLaF8poZnmEg6z3cMrdO6KuLy0U59pTHUDKq2Qp3POYsGmAf40 ve+KSue8fowkhe/7KySiaP7t+scMxI4NwYOq38ahHrpCiGtSpirTSDJWmylIAR0n+at8k0TCiea MpuDoke7cLfEBsri+TzuTscp9BbbtzTL+U+KQ0RxZrx6YAbvTvNkqAFhRVHtsF9ogZYlXh6Rhbl cc8g/gglr7gh3JBjCh7RXzbIDkXja8b/0IKVrP3PabhQ+n+nZ3QIcQiI24bvwYOwO7s6LrFyFkS enqcIn55OxIgKJ83mw2aZgJj0XWbePr/LNgvLzLKgq8BzfSAXqzSR2Kc4WUu4+Ei2V/frEgo/5i Iq9YEk752HXA3kfWsFc9tyQG82jPlzQGONomOWSJ3h1w16nYgi1VPeI8HDngf3ZeeKIAnoM4PXk Q== X-Received: by 2002:a05:7022:294:20b0:13b:3bee:1e2e with SMTP id a92af1059eb24-14503fa45acmr668581c88.18.1790214342262; Wed, 23 Sep 2026 18:45:42 -0700 (PDT) Received: from [127.0.0.2] ([50.145.100.174]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-14501794269sm2927598c88.8.2026.09.23.18.45.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 18:45:41 -0700 (PDT) From: Abdurrahman Hussain Date: Wed, 23 Sep 2026 18:45:36 -0700 Subject: [PATCH v6 1/3] i2c: xiic: preserve PEC byte length in SMBus block read setup Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260923-i2c-xiic-v6-1-3a15b6397f5a@nexthop.ai> References: <20260923-i2c-xiic-v6-0-3a15b6397f5a@nexthop.ai> In-Reply-To: <20260923-i2c-xiic-v6-0-3a15b6397f5a@nexthop.ai> To: Michal Simek , Andi Shyti , Wolfram Sang , Raviteja Narayanam , Wolfram Sang , Manikanta Guntupalli Cc: Shubhrajyoti Datta , linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, Abdurrahman Hussain , stable@vger.kernel.org X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790214340; l=6559; i=abdurrahman@nexthop.ai; s=20260510; h=from:subject:message-id; bh=k/4jwuXnA12hp9k1BEvLCcEgKt2ybI+KTJlDgEkJj5E=; b=r4M8X37QqLw4CWgFFpJYX3JMWOwMDO9jjlOqzPXK17vlYuyqjFULgyEWCva/UHc8Gkz+yryO/ fl0w4ey4h3cDBcV2DQqK5o7h+KzKVw7U/K42OZjAGtoOqkRRzVJgZdg X-Developer-Key: i=abdurrahman@nexthop.ai; a=ed25519; pk=omTm9cCAbO0ZhS32aKfJDKue0W3sQGpG9ub5eYHif8I= xiic_smbus_block_read_setup() recalculates i2c->rx_msg->len based on the length byte returned by the device, but historically clobbered the PEC byte expectation the SMBus core had baked into msg->len. That dropped the PEC byte from the caller's buffer on the normal and chunked receive-fifo branches. Compute pec_len up-front as (i2c->rx_msg->len - 1) and add it to the new length in every branch: - chunked (rxmsg_len + pec_len > IIC_RX_FIFO_DEPTH): set the drain target to rxmsg_len + 1 + pec_len. - deferred (small enough to drain in one fill but >=3D MIN_LEN total): same. - padded (1 + rxmsg_len + pec_len < SMBUS_BLOCK_READ_MIN_LEN): the hardware needs at least 3 bytes on the bus to exit the read cleanly (the second byte is already being clocked in by the time the ISR reads the length byte and is too late to NACK), so we still pad rx_msg->len up to SMBUS_BLOCK_READ_MIN_LEN. The dummy trailing byte that gets drained must then be trimmed off before handing the message back to the SMBus core; otherwise i2c_smbus_check_pec() reads buf[len-1] (=3D dummy) instead of the real PEC byte at buf[1] and rejects every clean zero-length block read with -EBADMSG. Record the true valid byte count in a new field i2c->smbus_actual_len and trim rx_msg->len down to it in xiic_smbus_trim_len(), called from both completion sites that clear rx_msg: xiic_process()'s RX_FULL branch and xiic_recv_atomic(), which drains the FIFO with interrupts off. smbus_actual_len is per-receive state, so xiic_start_recv() clears it before every receive. Only the padded branch ever sets it, and a block read aborted by arbitration loss or a TX error never reaches the completion site, so without that clear a stale value would trim the length of an unrelated later read. Widen the branch condition from the old "(rxmsg_len =3D=3D 1) || (rxmsg_len =3D=3D 0)" to "(1 + rxmsg_len + pec_len) < MIN_LEN" so that user requests with multi-byte trailing bytes (e.g. pec_len =3D=3D 2 on a zero-length block) flow through the deferred branch instead of getting truncated to MIN_LEN here. Fixes: e4c1ff772e1a ("i2c: xiic: Add smbus_block_read functionality") Cc: stable@vger.kernel.org Acked-by: Michal Simek Signed-off-by: Abdurrahman Hussain --- drivers/i2c/busses/i2c-xiic.c | 39 ++++++++++++++++++++++++++++++++------- 1 file changed, 32 insertions(+), 7 deletions(-) diff --git a/drivers/i2c/busses/i2c-xiic.c b/drivers/i2c/busses/i2c-xiic.c index 3e7735e1dae0..6cb264cbc366 100644 --- a/drivers/i2c/busses/i2c-xiic.c +++ b/drivers/i2c/busses/i2c-xiic.c @@ -73,6 +73,9 @@ enum i2c_scl_freq { * @prev_msg_tx: Previous message is Tx * @quirks: To hold platform specific bug info * @smbus_block_read: Flag to handle block read + * @smbus_actual_len: Valid byte count (length + payload + optional PEC) o= f a + * padded SMBus block read. msg->len is trimmed to this on completion. + * Zero when no trimming is needed. * @input_clk: Input clock to I2C controller * @i2c_clk: I2C SCL frequency * @atomic: Mode of transfer @@ -98,6 +101,7 @@ struct xiic_i2c { bool prev_msg_tx; u32 quirks; bool smbus_block_read; + unsigned int smbus_actual_len; unsigned long input_clk; unsigned int i2c_clk; bool atomic; @@ -539,6 +543,8 @@ static void xiic_smbus_block_read_setup(struct xiic_i2c= *i2c) =20 /* Check if received length is valid */ if (rxmsg_len <=3D I2C_SMBUS_BLOCK_MAX) { + unsigned int pec_len =3D i2c->rx_msg->len - 1; + /* Set Receive fifo depth */ if (rxmsg_len > IIC_RX_FIFO_DEPTH) { /* @@ -546,23 +552,26 @@ static void xiic_smbus_block_read_setup(struct xiic_i= 2c *i2c) * Receive fifo depth should set to Rx fifo capacity minus 1 */ rfd_set =3D IIC_RX_FIFO_DEPTH - 1; - i2c->rx_msg->len =3D rxmsg_len + 1; - } else if ((rxmsg_len =3D=3D 1) || - (rxmsg_len =3D=3D 0)) { + i2c->rx_msg->len =3D rxmsg_len + 1 + pec_len; + } else if (1 + rxmsg_len + pec_len < SMBUS_BLOCK_READ_MIN_LEN) { /* - * Minimum of 3 bytes required to exit cleanly. 1 byte - * already received, Second byte is being received. Have - * to set NACK in read_rx before receiving the last byte + * The HW needs SMBUS_BLOCK_READ_MIN_LEN bytes on the + * bus to exit cleanly: by the time the ISR reads the + * length byte the second byte is already being clocked + * in, too late to NACK. Pad the drain target and record + * the real length, trimmed back on completion so the + * PEC check sees the right byte. */ rfd_set =3D 0; i2c->rx_msg->len =3D SMBUS_BLOCK_READ_MIN_LEN; + i2c->smbus_actual_len =3D 1 + rxmsg_len + pec_len; } else { /* * When Rx msg len less than Rx fifo capacity * Receive fifo depth should set to Rx msg len minus 2 */ rfd_set =3D rxmsg_len - 2; - i2c->rx_msg->len =3D rxmsg_len + 1; + i2c->rx_msg->len =3D rxmsg_len + 1 + pec_len; } xiic_setreg8(i2c, XIIC_RFD_REG_OFFSET, rfd_set); =20 @@ -575,6 +584,16 @@ static void xiic_smbus_block_read_setup(struct xiic_i2= c *i2c) dev_err(i2c->adap.dev.parent, "smbus_block_read Invalid msg length\n"); } =20 +/* + * Undo the setup-time padding of a short SMBus block read before rx_msg is + * cleared, so the PEC check sees the right byte. + */ +static void xiic_smbus_trim_len(struct xiic_i2c *i2c) +{ + if (i2c->rx_msg && i2c->smbus_actual_len) + i2c->rx_msg->len =3D i2c->smbus_actual_len; +} + static void xiic_read_rx(struct xiic_i2c *i2c) { u8 bytes_in_fifo, cr =3D 0, bytes_to_read =3D 0; @@ -797,6 +816,8 @@ static irqreturn_t xiic_process(int irq, void *dev_id) =20 xiic_read_rx(i2c); if (xiic_rx_space(i2c) =3D=3D 0) { + xiic_smbus_trim_len(i2c); + /* this is the last part of the message */ i2c->rx_msg =3D NULL; =20 @@ -938,6 +959,7 @@ static void xiic_recv_atomic(struct xiic_i2c *i2c) return; } =20 + xiic_smbus_trim_len(i2c); i2c->rx_msg =3D NULL; xiic_irq_clr_en(i2c, XIIC_INTR_TX_ERROR_MASK); =20 @@ -955,6 +977,9 @@ static void xiic_start_recv(struct xiic_i2c *i2c) u8 cr =3D 0, rfd_set =3D 0; struct i2c_msg *msg =3D i2c->rx_msg =3D i2c->tx_msg; =20 + /* A stale value from an aborted block read would truncate this msg. */ + i2c->smbus_actual_len =3D 0; + if (!i2c->atomic) dev_dbg(i2c->adap.dev.parent, "%s entry, ISR: 0x%x, CR: 0x%x\n", __func__, xiic_getreg32(i2c, XIIC_IISR_OFFSET), --=20 2.54.0 From nobody Thu Sep 24 13:43:36 2026 Received: from mail-dl2-f12.google.com (mail-dl2-f12.google.com [74.125.229.140]) (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 F26D4399CEC for ; Thu, 24 Sep 2026 01:45:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.229.140 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790214346; cv=none; b=areT09glewZMSGIyOeqqyr8O+CDImyGmY2Y2rBrO17p6dNLLx+xqCMk//9+p9AFIrkoUfUFbhjyZidG13dzbPzRLCaI+LE1fLdWF/MdCv7KyUwgs6lCuVQyZcuMEWJnqQCOXxixS2ZgtAcn+vRkrwO/Fzmkz5sbVzp0C9ydBg/k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790214346; c=relaxed/simple; bh=hjh/huwNpHT4R0O30TFZo10JCsexhfogEIYuCqGs5hs=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=koHqBkbl9/wog2cayhYkkQiG5rJlZELRtxo+063Mqq578DYQ20M51cLW6OD1MgFI+RYXJpmIjy2BCDbXhV1yw+s+K9JklOr8qID8fzeSwo1ielobJWjoRutWP/MR0dwoW0Tx4z4Ax5GUfcWJuTlLQm0w8YHuQWj6imutQUsGhFU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nexthop.ai; spf=pass smtp.mailfrom=nexthop.ai; dkim=pass (2048-bit key) header.d=nexthop.ai header.i=@nexthop.ai header.b=LKsI4lil; arc=none smtp.client-ip=74.125.229.140 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nexthop.ai Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=nexthop.ai Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=nexthop.ai header.i=@nexthop.ai header.b="LKsI4lil" Received: by mail-dl2-f12.google.com with SMTP id a92af1059eb24-142dd05d97cso2289761c88.2 for ; Wed, 23 Sep 2026 18:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nexthop.ai; s=google; t=1790214344; x=1790819144; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=rFtQiwO6/6BJ7wa+vqmBzThl4fhyokGeBbXcNwOcE/A=; b=LKsI4lilf4ixk3TVig9cknJOZ5niwi2Bwx7MxGrbdjGfi9agK74Qkjo6qHboWsW+I3 Zjf0J5IB1Xj766OtPsWdBI7QSXuj6+j4RhSiuQzSGGh1wuZ7V/e9X/ON9TQECH8S+k7z q6Ht8o/7tYXDI9KaOSmIFveva/ckOvaKOKKWfqngsMl33z2OKwoYRHPwVPIhpVqq20Jg ikeHEPRuE2Lp0pXPlz+xTifd2JWMh//Cx1sfQ24TPJ6haDyIcX/Yb9GHsn2868h8/s+B QAWQebrQ5GrJE/UyGwekyQWqcOwRzPdpoiaZZj+81TrTygB9+MjcokC2Q4ElLBTv6PWk iE0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790214344; x=1790819144; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=rFtQiwO6/6BJ7wa+vqmBzThl4fhyokGeBbXcNwOcE/A=; b=oXSsEkblcwi2B7qZGLZLhdq7a7C+w+/qljgw48mRhS2Ke6pFDec5dEMCKQqrg2YGC4 cS6nyvwEWgjmiOwie3EEZwsleVeWs9BzPRSynhYG/hVz4ejBomHub6Z8+m3xspMMMhrr FJbNNVPAjON17lJu+fC38sqQKIVt6II/Oow/ns84TKIFpfCqQY0c1rDcFrv39DWqBvwo l742mJuKu9jrrfVmZc+5GM60h/GGn0MZh64M1OTwx+/BCu80G162jITHRSlIwzICLVeX ZO2UcHPI6H3xNVUJrMsHcKmhZZN66A5Ywxenfux4+I7dxIw7h6yu0XlTssZBsAFfE6C8 i9YQ== X-Forwarded-Encrypted: i=1; AKwUvByU/mJSwGY8klH/bVpBkctWM3CBvpBbXePzmSgGzOl19hhnfICloh2tFT5wNh+5b1HstTYoWT2D7oKfk4Y=@vger.kernel.org X-Gm-Message-State: AFuF++mSG+gRORIrxNd1KyGlZnFVxpBlo6STh64d1Cuy3i6VlP5PUjQl Uz0hhcHDrZfvCW6NEKYhZW2zDyvsL7JzNcuZyjl5QtVufBuGjdeoOYfyrl3yZqcNUyVSG7X1/sX fiUO5fHA= X-Gm-Gg: AYBFou0HN4XFW4QaG4kGf6UP+Il3HlAWsW3v/9unhLvgBkcWEg9g7SMwJa0NDorHZtT /NMERHSq7E+VB9FYnCV710laVu9A5TdjUyCbU8kwim1oU4zDy4CnCZXF4zBsTo539F5xOsaFMJu yDd57jF/nEhFybyyX18HsN70WOkmFmmbK3AS011P+1m75RR8hFNthYnXzQeK3DzoSRqxv5X/P1Q q/yUaioJCkdC48bNwSAkkH5deMmDmlO6Sz4YgS8EwZZZBUV8UuMQheAbmqDjc63hecVA9d2SUER SkwiCMCgj9DbcUKyyYhUIymtqJ5AikTPnfLRbkA36iMNwcmcTgZjSQoPDADK4fEj+AKgVi2gaOF R9VRwrOYG8Wqt8zPgHQDYIEuAd/rmHlii7gkzsU0EMzDJ4uxU1SSMsl6ZVCClHMuBsnlRjovEnD 2MtP0eJKs8b0zNj5zxJD//TDO+YQOSw3bo0037DRCsq0eGQMbBlQwXxw0EroOxzqZiUR2OeH4Ec A== X-Received: by 2002:a05:701b:4292:20b0:143:89a6:9ea9 with SMTP id a92af1059eb24-14503f9735emr748692c88.19.1790214343219; Wed, 23 Sep 2026 18:45:43 -0700 (PDT) Received: from [127.0.0.2] ([50.145.100.174]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-14501794269sm2927598c88.8.2026.09.23.18.45.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 18:45:42 -0700 (PDT) From: Abdurrahman Hussain Date: Wed, 23 Sep 2026 18:45:37 -0700 Subject: [PATCH v6 2/3] i2c: xiic: defer RX_FULL until all trailing bytes are in FIFO Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260923-i2c-xiic-v6-2-3a15b6397f5a@nexthop.ai> References: <20260923-i2c-xiic-v6-0-3a15b6397f5a@nexthop.ai> In-Reply-To: <20260923-i2c-xiic-v6-0-3a15b6397f5a@nexthop.ai> To: Michal Simek , Andi Shyti , Wolfram Sang , Raviteja Narayanam , Wolfram Sang , Manikanta Guntupalli Cc: Shubhrajyoti Datta , linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, Abdurrahman Hussain , stable@vger.kernel.org X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790214340; l=2996; i=abdurrahman@nexthop.ai; s=20260510; h=from:subject:message-id; bh=hjh/huwNpHT4R0O30TFZo10JCsexhfogEIYuCqGs5hs=; b=ESsvAdfXRm0tlYcUbq3pUgtyTWOnDdmGWS56m6a/HeF5Da0WAGiwNahnaVp2p7ITa0+jdFYf/ c8mhvMhlJF/Dy6plYKFa+nUrdBkJh84xQiUAqmZ5J7Qt0jGOh/jwkQx X-Developer-Key: i=abdurrahman@nexthop.ai; a=ed25519; pk=omTm9cCAbO0ZhS32aKfJDKue0W3sQGpG9ub5eYHif8I= For the normal path of xiic_smbus_block_read_setup() (rxmsg_len less than IIC_RX_FIFO_DEPTH), RFD was programmed to rxmsg_len - 2, which fires the RX_FULL interrupt while the last payload byte is still in flight. xiic_read_rx()'s bytes_rem =3D=3D 1 branch then sets NACK on that byte still on the wire, truncating the read in the PEC-enabled case. Raise the threshold so RX_FULL fires only once every remaining byte (payload plus optional PEC) is already buffered in the FIFO. That routes the drain through xiic_read_rx()'s bytes_rem =3D=3D 0 path, which reads everything out and emits the stop cleanly. For the non-PEC path the full payload is still read out through the same bytes_rem =3D=3D 0 branch; the only user-visible change is that the controller waits one extra byte-time before servicing the interrupt. The deferred-fire formula is rxmsg_len + pec_len - 1, and the RFD register at XIIC_RFD_REG_OFFSET is a 4-bit field. Widen the chunk-vs-defer guard to (rxmsg_len + pec_len > IIC_RX_FIFO_DEPTH) so the boundary case rxmsg_len =3D=3D IIC_RX_FIFO_DEPTH with PEC enabled cannot write 16 into that 4-bit register; it routes through the chunked drain instead, which already caps RFD at IIC_RX_FIFO_DEPTH - 1. Fixes: e4c1ff772e1a ("i2c: xiic: Add smbus_block_read functionality") Cc: stable@vger.kernel.org Acked-by: Michal Simek Signed-off-by: Abdurrahman Hussain --- drivers/i2c/busses/i2c-xiic.c | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/drivers/i2c/busses/i2c-xiic.c b/drivers/i2c/busses/i2c-xiic.c index 6cb264cbc366..b4177d655cce 100644 --- a/drivers/i2c/busses/i2c-xiic.c +++ b/drivers/i2c/busses/i2c-xiic.c @@ -546,10 +546,11 @@ static void xiic_smbus_block_read_setup(struct xiic_i= 2c *i2c) unsigned int pec_len =3D i2c->rx_msg->len - 1; =20 /* Set Receive fifo depth */ - if (rxmsg_len > IIC_RX_FIFO_DEPTH) { + if (rxmsg_len + pec_len > IIC_RX_FIFO_DEPTH) { /* - * When Rx msg len greater than or equal to Rx fifo capacity - * Receive fifo depth should set to Rx fifo capacity minus 1 + * Trailing payload (data + optional PEC) exceeds Rx FIFO + * capacity; drain in chunks. Fire RX_FULL when the FIFO is + * full and let the ISR re-arm for the remainder. */ rfd_set =3D IIC_RX_FIFO_DEPTH - 1; i2c->rx_msg->len =3D rxmsg_len + 1 + pec_len; @@ -566,11 +567,8 @@ static void xiic_smbus_block_read_setup(struct xiic_i2= c *i2c) i2c->rx_msg->len =3D SMBUS_BLOCK_READ_MIN_LEN; i2c->smbus_actual_len =3D 1 + rxmsg_len + pec_len; } else { - /* - * When Rx msg len less than Rx fifo capacity - * Receive fifo depth should set to Rx msg len minus 2 - */ - rfd_set =3D rxmsg_len - 2; + /* Defer RX_FULL until all trailing bytes are in FIFO. */ + rfd_set =3D rxmsg_len + pec_len - 1; i2c->rx_msg->len =3D rxmsg_len + 1 + pec_len; } xiic_setreg8(i2c, XIIC_RFD_REG_OFFSET, rfd_set); --=20 2.54.0 From nobody Thu Sep 24 13:43:36 2026 Received: from mail-dl2-f42.google.com (mail-dl2-f42.google.com [74.125.229.170]) (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 BB27439D3FD for ; Thu, 24 Sep 2026 01:45:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.229.170 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790214348; cv=none; b=u7HcxRYF4KiCZ96nSnjD0G1+1c5jDMfcudTot40RZ4uwbRzObdXdfbBGsH698HiNxBezSW/H9DM6Bm17MBiutjRj2JlJNy5MHBdaULQtIkY3ydkCRLlIblXmZRo7LQ2gUblJiBQdLBrzsmT2mJtn9ZSG2R7DpH9+pHVYBRS3yXo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790214348; c=relaxed/simple; bh=Bg5NkWAAvHyt3A3yj80XS79ACYShmuxSKGVO43oYPz4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=XwIMU8F4TblBhq5DeGTGSa6VJlRIvVjyz9Sf605mFYUvIy32BopYFBwPXjxz33s9GRsxHrl2V+im+icG/4TGRwl6hWXgYtStoGBapQ9EfDTlnLZ0AaAl3H29doDYbQewB4B//IH+t+DKTonSCBYEDOCsbcOsIHsH+uYV/DGRftc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nexthop.ai; spf=pass smtp.mailfrom=nexthop.ai; dkim=pass (2048-bit key) header.d=nexthop.ai header.i=@nexthop.ai header.b=kHCm+ey9; arc=none smtp.client-ip=74.125.229.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nexthop.ai Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=nexthop.ai Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=nexthop.ai header.i=@nexthop.ai header.b="kHCm+ey9" Received: by mail-dl2-f42.google.com with SMTP id a92af1059eb24-1437b77c274so959519c88.3 for ; Wed, 23 Sep 2026 18:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nexthop.ai; s=google; t=1790214345; x=1790819145; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ieebBEdwgRwM6KekZkohbUAIizHwSaKZe32zZn7go7M=; b=kHCm+ey9tiS053NLeXnGp46mTEX4CTJb9QuEhkXxKw6I8JBkGNgHfv0tsLDP/6BQFU M3dcpbflKjO2Om2Hv14M/ar3boanePYHXyMEyrdt+N8a0zt3Kt9qSwjH63/QxqjBD8mA xrBmHe7l09etko7gSr68m9uWVeMPYcWhmbM93tcpXnI4L3lC3lRn8dufad6xR60HIfjW RVQfPdMgWXuuXgjMJyddV00trLDo/lTqj4IztxCxVJMCuEwD1hrciEx8Nfz5QFyKfmCp Uffk+MlpHZhhBEregW7m1na7vn7jdI3dRuKZzpyJXx6fnP1HEoDf3YXjhzIJEG/BmXDX 0c6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790214345; x=1790819145; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ieebBEdwgRwM6KekZkohbUAIizHwSaKZe32zZn7go7M=; b=14uy1LovQoqb/V9Jfs4kOiZNZ9QdFRYbDCtKIiYfLMLgVD08vt9ji6oE81yqKK5thk ti2p2S57+rU8INHTK7snKDqRS2tUr0WNQ98C+pDNjWxXwb1VrqlLIpUbTqLGl6XyRj+I UdD7WT/Jmgm31xsG4+tGSD4w4HlPptNNLpFCOfeaaXVgGIxv3el40e6NeTBEOaXIGo3S HDOVR4FDruiYdiyCZHnaHyrgov8UUXNuk0gV8GzmuupRtGlia7i5F0tAiuTtwKmRg6cK pHSacC3FRbavzUhmEmLGmvmcPLLrsMbcVBNtVuy5T+pVs8S8TYehRUL0hiRpHkvpA+N5 KPmQ== X-Forwarded-Encrypted: i=1; AKwUvBymxRDqAc+kvn9wl3yr1z/HgZe8Dv/M2ZGme9PcbBBD+45t5DgcNOYzlBhi87pOzCasAt369Gw8CqAtJXg=@vger.kernel.org X-Gm-Message-State: AFuF++nxZ4Oui8T5o9QspXHzUgLou5wlG6TrGI/vRykT59D3ek1ZCZlx TGe2SCeuWVUy/rLDx+taRuyYA9zl2TF18BKa91tfsIVmS6HvEUfL0t4E8yz2QoJh3PzN1Ersz2T ZAJAGNuw= X-Gm-Gg: AYBFou2rTZN5AZ1snn+edAV4wgcTsphMylOBq9bz7t7MmRBfS21itVBuNP3e4MQc90j ihJMiqENztCs3fMsCiHWE9d5DBnL5FQc6Dc/EikOMt48gVVrKppYc6hWv0pvO+4EWrcY49Yjqhk PkU7mEfNsKJTNSSUSzhnykmuZmCfjZl2FElbjawi+9WR2CjGvEJ40H36VXt2IdhXiQkYhSgL5Ew YSoX/lIZ12zXhIC016jBUaX1nWlRvQOMeQTRsrF1FR+tbY62g09cycFFM7kPBH9K7KtGte85E6H 2y8PFiz2UCRtVS5/fMLmezLnmCmDtjSmdkmhK3AiqyElw6V0RfzVjI3/ENDkW3i6P0Bj7KDtjDI /0t+mho0sYH/r+yMMXZk7H+6g6o2ItpRXNHDFjQzzmEoVZ4y8kn8H1fAHfsaizJasitJ01bEiwp O0mh4oAFc2l7fwPXgSg9v2Ar4IeJ4OdXjuW+Ht1qfBZXW3wcl8x38zC19NdO8+NJGpSz4WomzJX mTzqs/eOxXl X-Received: by 2002:a05:701b:464d:b0:13b:975d:74e0 with SMTP id a92af1059eb24-14503f2ecb5mr605349c88.8.1790214344742; Wed, 23 Sep 2026 18:45:44 -0700 (PDT) Received: from [127.0.0.2] ([50.145.100.174]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-14501794269sm2927598c88.8.2026.09.23.18.45.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 18:45:44 -0700 (PDT) From: Abdurrahman Hussain Date: Wed, 23 Sep 2026 18:45:38 -0700 Subject: [PATCH v6 3/3] i2c: xiic: don't clobber msg->len to signal block-read completion Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260923-i2c-xiic-v6-3-3a15b6397f5a@nexthop.ai> References: <20260923-i2c-xiic-v6-0-3a15b6397f5a@nexthop.ai> In-Reply-To: <20260923-i2c-xiic-v6-0-3a15b6397f5a@nexthop.ai> To: Michal Simek , Andi Shyti , Wolfram Sang , Raviteja Narayanam , Wolfram Sang , Manikanta Guntupalli Cc: Shubhrajyoti Datta , linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, Abdurrahman Hussain , stable@vger.kernel.org X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790214340; l=2009; i=abdurrahman@nexthop.ai; s=20260510; h=from:subject:message-id; bh=Bg5NkWAAvHyt3A3yj80XS79ACYShmuxSKGVO43oYPz4=; b=qFUA265qvuxhLpUmsONKjmI+890eW6TegPL4ejNVHCxg7BhwfRvUx5J2mId0Q73bl+JzaU3da kKnVPT0LVT0DtRfa/MazyqQI6uHZayGN/ngRyqxPV6aCXGvGTo4zlf3 X-Developer-Key: i=abdurrahman@nexthop.ai; a=ed25519; pk=omTm9cCAbO0ZhS32aKfJDKue0W3sQGpG9ub5eYHif8I= At the end of a SMBus block read the BNB handler force-set tx_msg->len =3D 1 to push xiic_tx_space() to zero so the STATE_DONE branch would fire. Two problems: 1. tx_msg and rx_msg alias the same i2c_msg struct during a receive (see xiic_start_recv), so overwriting tx_msg->len also changes rx_msg->len. The i2c core's i2c_smbus_check_pec() then reads the PEC from the wrong offset -- buf[0] instead of buf[rxmsg_len + 1] -- and either mis-validates or returns -EBADMSG. 2. xiic_start_recv sets tx_pos =3D msg->len (typically 2 when PEC is enabled). xiic_tx_space() is unsigned msg->len - tx_pos, so setting msg->len =3D 1 with tx_pos =3D 2 underflows to 0xFFFFFFFF and xiic_tx_space() never compares equal to 0 -- the STATE_DONE check falls through to STATE_ERROR, giving -EIO. Instead, advance tx_pos up to msg->len. That drives tx_space to 0 without touching msg->len, preserving the buffer length that xiic_smbus_block_read_setup() already grew to cover the length byte, the payload and the optional PEC byte. Fixes: e4c1ff772e1a ("i2c: xiic: Add smbus_block_read functionality") Cc: stable@vger.kernel.org Acked-by: Michal Simek Signed-off-by: Abdurrahman Hussain --- drivers/i2c/busses/i2c-xiic.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-xiic.c b/drivers/i2c/busses/i2c-xiic.c index b4177d655cce..5d8492ed25f1 100644 --- a/drivers/i2c/busses/i2c-xiic.c +++ b/drivers/i2c/busses/i2c-xiic.c @@ -884,8 +884,11 @@ static irqreturn_t xiic_process(int irq, void *dev_id) =20 if (i2c->tx_msg && i2c->smbus_block_read) { i2c->smbus_block_read =3D false; - /* Set requested message len=3D1 to indicate STATE_DONE */ - i2c->tx_msg->len =3D 1; + /* + * Drive xiic_tx_space() to 0 to signal STATE_DONE + * without truncating the rx_msg length. + */ + i2c->tx_pos =3D i2c->tx_msg->len; } =20 if (!i2c->tx_msg) --=20 2.54.0