[Bug 258994] iic(4): Panics on Nanopi Neo when using 16-bit device addressing width: panic: Assertion strlen(description) < MAX_W_NAME failed at ... sys/kern/subr_witness.c:1914
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 26 Nov 2021 14:25:01 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258994 --- Comment #17 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=04622a7f21157827fe75276a4520a52d3a571a86 commit 04622a7f21157827fe75276a4520a52d3a571a86 Author: Andriy Gapon <avg@FreeBSD.org> AuthorDate: 2021-11-26 08:07:27 +0000 Commit: Andriy Gapon <avg@FreeBSD.org> CommitDate: 2021-11-26 14:17:24 +0000 twsi: move handling of TWSI_CONTROL_ACK into the state machine Previously the code set TWSI_CONTROL_ACK in twsi_transfer() based on whether the first message had a length of one. That was done regardless of whether the message was a read or write and what kind of messages followed it. Now the bit is set or cleared while handling TWSI_STATUS_ADDR_R_ACK state transition based on the current (read) message. The old code did not correctly work in a scenario where a single byte was read from an EEPROM device with two byte addressing. For example: i2c -m tr -a 0x50 -d r -w 16 -o 0 -c 1 -v The reason is that the first message (a write) has two bytes, so TWSI_CONTROL_ACK was set and never cleared. Since the controller did not send NACK the EEPROM sent more data resulting in a buffer overrun. While working on TWSI_STATUS_ADDR_R_ACK I also added support for the zero-length read access and then I did the same for zero-length write access. While rare, those types of I2C transactions are completely valid and are used by some devices. PR: 258994 MFC after: 3 weeks sys/dev/iicbus/twsi/twsi.c | 40 ++++++++++++++++++++++++++-------------- 1 file changed, 26 insertions(+), 14 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.