diff options
author | Ryan Harkin <ryan.harkin@linaro.org> | 2016-02-09 08:52:32 +0000 |
---|---|---|
committer | Ard Biesheuvel <ard.biesheuvel@linaro.org> | 2016-02-10 17:56:39 +0100 |
commit | a4626006bbf86113453aeb7920895e66cdd04737 (patch) | |
tree | 755bea0bfc74590934ea761bd2f7aa5498a21a13 /ArmPkg/Library/ArmGicArchSecLib | |
parent | 7d0f92e8fd68e1f1242f36c203400be23954d563 (diff) | |
download | edk2-a4626006bbf86113453aeb7920895e66cdd04737.tar.gz |
EmbeddedPkg/Lan9118Dxe: use MemoryFence
When reviewing my LAN9118 driver PCD patch [1], Ard Biesheuvel noted
that most calls to gBS->Stall() in this driver seem to be used to
prevent timing issues between the device updating data and the host
reading the values. And that replacing most of these calls with a
MemoryFence() would be more robust.
The only exceptions are the stalls that are enclosed inside retry loops:
- in the AutoNegotiate() function.
This stall is waiting for the link to negotiate, which may require
stalling until it is ready.
- in the Lan9118Initialize() function.
These two stalls are waiting for devices and time out after a number
of retries.
- in the SoftReset() function.
This stall is inside a loop where the comment states:
"If time taken exceeds 100us, then there was an error condition"
In these instances, I kept the stall, but also added a MemoryFence().
[1] http://article.gmane.org/gmane.comp.bios.edk2.devel/7389
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Diffstat (limited to 'ArmPkg/Library/ArmGicArchSecLib')
0 files changed, 0 insertions, 0 deletions