hw/bus: Update sanity check for locking #3510
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Code assume that node can be locked only once and
second lock is probably for another node.
Lock are internally use on each transaction.
Write, read, write then read transactions can be
used with just one lock.
spiflash driver locks node when it wants to write, however writing consist of two transactions fist
command is sent (4 bytes) then another write is
done with separate buffer. CS must be low during
those two writes. While write could be performed
successfully current implementation would require
SPI controller to be unlocked between writes.
This could potentially lead to SPI controller
being locked for another device while CS is still
down for spi flash.
In fact due to sanity check spi flash driver
did not work at all with any bus driver since
code tried to lock device before writes and
then both writes would fail due to nested lock
sanity check.
Now sanit check verifies that nested lock is
for same device.