[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

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.