Attention is currently required from: Simon Buhrow, Alan Green, Edward O'Callaghan, Anastasia Klimchuk, Samir Ibradžić.

View Change

1 comment:

• File ft2232_spi.c:

  • Patch Set #25, Line 295: 9

    I counted 15 (lines 303, 309, 320, 328, 335). […]

    I see 6 potential paths, due to the 3 if's but the second may end
    the path prematurely with the `continue;`:

    • false, false, false: 303, 335 (empty command, actually impossible due to the loop condition)
    • false, false, true: 303, 328, 335 (read)
    • false, true, *: 303, 320 (empty command with continuation, impossible due to the loop condition)
    • true, false, false: 303, 309, 335 (write without continuation)
    • true, false, true: 303, 309, 328, 335 (write+read)
    • true, true, *: 303, 309, 320 (write with continuation)

    Turns out there's actually only 4 paths :) The simple write+read wins
    with 4 * 3 == 12 (assert CS#, write, read, de-assert CS#). Overhead
    for any continuation would be accounted for in the next iteration.

    Now that it's decoded (admittedly, it doesn't look like it), I think
    it could get more obvious if the continuation check would be moved
    after the regular CS# de-assertion. i.e.

        assert cs#
        if (write)
            write command
        if (read)
            read command
        de-assert cs#
        if (!read && possible continuation)
            continue
        send_buf()

    Simon, what do you think? That should make it clear that we always do

    • assert - foo - de-assert,
    • eventually either continue with the next iteration or call send_buf().

To view, visit change 40477. To unsubscribe, or for help writing mail filters, visit settings.