[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 #18 from commit-hook@FreeBSD.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=ff1e8581806f70e54fecddf8a6a23488dc7b968a

commit ff1e8581806f70e54fecddf8a6a23488dc7b968a
Author:     Andriy Gapon <avg@FreeBSD.org>
AuthorDate: 2021-11-26 09:48:21 +0000
Commit:     Andriy Gapon <avg@FreeBSD.org>
CommitDate: 2021-11-26 14:20:27 +0000

    twsi: support more message combinations in transfers

    Most prominently, add support for a transfer where a write with no-stop
    flag is followed by a write with no-start flag.  Logically, it's a
    single larger write, but consumers may want to split it like that
    because one part can be a register ID and the other part can be data to
    be written to (or starting at) that register.

    Such a transfer can be created by i2c tool and iic(4) driver, e.g., for
    an EEPROM write at specific offset:
        i2c -m tr -a 0x50 -d w -w 16 -o 0 -c 8 -v < /dev/random

    This should be fixed by new code that handles the end of data transfer
    for both reads and writes.  It handles two existing conditions and one
    new.  Namely:
    - the last message has been completed -- end of transfer;
    - a message has been completed and the next one requires the start
      condition;
    - a message has been completed and the next one should be sent without
      the start condition.

    In the last case we simply switch to the next message and start sending
    its data.  Reads without the start condition are not supported yet,
    though.  That's because we NACK the last byte of the previous message,
    so the device stops sending data.  To fix this we will need to add a
    look-ahead at the next message when handling the penultimate byte of the
    current one.

    This change also fixed a bug where msg_idx was not incremented after a
    read message.  Apparently, typically a read message is a last message in
    a transfer, so the bug did not cause much trouble.

    PR:             258994
    MFC after:      3 weeks

 sys/dev/iicbus/twsi/twsi.c | 85 +++++++++++++++++++++++++++++-----------------
 1 file changed, 53 insertions(+), 32 deletions(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.