summaryrefslogtreecommitdiffstats
path: root/EmbeddedPkg/EmbeddedPkg.dec
diff options
context:
space:
mode:
authorRyan Harkin <ryan.harkin@linaro.org>2016-02-09 08:52:32 +0000
committerArd Biesheuvel <ard.biesheuvel@linaro.org>2016-02-10 17:56:39 +0100
commita4626006bbf86113453aeb7920895e66cdd04737 (patch)
tree755bea0bfc74590934ea761bd2f7aa5498a21a13 /EmbeddedPkg/EmbeddedPkg.dec
parent7d0f92e8fd68e1f1242f36c203400be23954d563 (diff)
downloadedk2-a4626006bbf86113453aeb7920895e66cdd04737.tar.gz
edk2-a4626006bbf86113453aeb7920895e66cdd04737.tar.bz2
edk2-a4626006bbf86113453aeb7920895e66cdd04737.zip
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 'EmbeddedPkg/EmbeddedPkg.dec')
0 files changed, 0 insertions, 0 deletions