tree ffe72764a64305c820d5268beee0ebd6127bc8ee
parent 4be9ff9402e9ef417af32115cff61b506eddff52
author Daniel Jarai <daniel.jarai@bartec-pixavi.com> 1591716841 +0200
committer Daniel Jarai <daniel.jarai@bartec-pixavi.com> 1591899631 +0200

nanohub: i2c: fix transfer ID race

The I2C queue works by maintaining two counters:
 - "last" is the ID of the last transfer, assigned to new transfers
   created by calling i2cMasterTxRx, and incremented (getting and
   incrementing the value is atomic)
 - "next" is the ID of the next, not necessarily existing
   transfer; starting with "last + 1", when a transfer finishes, the
   queue is checked for transfers with the current value, and it's
   incremented (getting and incrementing the value is atomic)

Illustrating this, here's how it normally works:
 1. the bus is idle, last=1, next=2
 2. i2cMasterTxRx is called, starting transfer A with ID=1, marking the
    bus busy
 3. i2cMasterTxRx is called, enqueuing transfer B with ID=2
 4. transfer A finishes; the queue is checked for transfers with ID=next
    (next=2), picking up and starting transfer B
 5. transfer B finishes; the queue is checked for transfers with ID=next
    (next=3), but as no such transfer exists, the bus is marked idle

However, consider the following scenario:
 1. the bus is idle, last=1, next=2
 2. i2cMasterTxRx is called, setting ID=1 for transfer A, but before
    starting the transfer, it's interrupted
 3. the interrupt also calls i2cMasterTxRx, starting transfer B
    with ID=2
 4. execution returns to the original call, enqueuing transfer A
    (as the bus is now busy)
 5. transfer B finishes; the queue is checked for transfers with ID=next
    (next=2), but as transfer A has ID=1 in the queue, it's ignored

From this point, "last" and "next" aren't in sync anymore, essentially
breaking the queue.

To fix this, remove "next", and always pick up the transfer with the
lowest ID in the queue. This shouldn't have any negative side effect,
as the order of the transfers will be preserved, but it fixes this race
condition: in the above scenario, transfer A will be picked up after
transfer B.

Change-Id: I6af55f62037430aa31190bc587a70ae99de2fb3b