[PATCH] i2c: xiic: don't fail a read whose data is already in the RX FIFO
Michal Simek
michal.simek at amd.com
Sun Nov 1 23:16:45 PST 2026
On 11/2/26 06:13, Shubhrajyoti Datta wrote:
> On Tue, Oct 6, 2026 at 12:21 AM Siddarth Chilukuri via B4 Relay
> <devnull+siddarth.nexthop.ai at kernel.org> wrote:
>>
>> From: Siddarth Chilukuri <siddarth at nexthop.ai>
>>
>> When the controller is the master receiver, TX_ERROR is set once the
>> core has NACKed the last byte ("transmit complete" in PG090). We have
>> seen xiic_process() run with TX_ERROR set but RX_FULL not yet set,
>> while the RX FIFO already holds all of the remaining bytes of the
>> message.
>>
>> xiic_process() treats TX_ERROR without RX_FULL as an error, so in this
>> case it reinitializes the core, the data in the FIFO is lost, and the
>> read returns -EIO even though it finished on the bus. The next read on
>> the same adapter can also return stale data without reporting an error.
>>
>> Fix this by checking the RX FIFO in the error path. If the message is
>> a read, there was no arbitration loss, and the FIFO has all of the
>> remaining bytes, handle it the same way as RX_FULL and complete the
>> message. Since IISR is toggle-on-write, only clear RX_FULL if it was
>> actually set.
>>
>> We found this on a system with several AXI IIC controllers in one PCIe
>> FPGA that share an interrupt. It only happens when at least two
>> controllers are busy at the same time. With 12 QSFP-DD modules being
>> read in parallel for 480 seconds, the failures went from 2083 -EIO and
>> 1158 reads with wrong data (out of 11.2M reads) to none.
>>
>> Fixes: e1d5b6598cdc ("i2c: Add support for Xilinx XPS IIC Bus Interface")
>> Cc: stable at vger.kernel.org
>> Signed-off-by: Siddarth Chilukuri <siddarth at nexthop.ai>
>> ---
> Reviewed-by: Shubhrajyoti Datta <shubhrajyoti.datta at amd.com>
Acked-by: Michal Simek <michal.simek at amd.com>
Thanks,
Michal
More information about the linux-arm-kernel
mailing list