aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm64/include/asm/acpi.h
diff options
context:
space:
mode:
authorWill Deacon <will.deacon@arm.com>2018-11-07 23:06:15 +0000
committerWill Deacon <will.deacon@arm.com>2018-11-27 12:18:07 +0000
commit6460d32014717686d3b7963595950ba2c6d1bb5e (patch)
tree39fa3b5df880d312133b035ba2b011cacb1b47d8 /arch/arm64/include/asm/acpi.h
parentarm64: mm: Don't wait for completion of TLB invalidation when page aging (diff)
downloadlinux-dev-6460d32014717686d3b7963595950ba2c6d1bb5e.tar.xz
linux-dev-6460d32014717686d3b7963595950ba2c6d1bb5e.zip
arm64: io: Ensure calls to delay routines are ordered against prior readX()
A relatively standard idiom for ensuring that a pair of MMIO writes to a device arrive at that device with a specified minimum delay between them is as follows: writel_relaxed(42, dev_base + CTL1); readl(dev_base + CTL1); udelay(10); writel_relaxed(42, dev_base + CTL2); the intention being that the read-back from the device will push the prior write to CTL1, and the udelay will hold up the write to CTL1 until at least 10us have elapsed. Unfortunately, on arm64 where the underlying delay loop is implemented as a read of the architected counter, the CPU does not guarantee ordering from the readl() to the delay loop and therefore the delay loop could in theory be speculated and not provide the desired interval between the two writes. Fix this in a similar manner to PowerPC by introducing a dummy control dependency on the output of readX() which, combined with the ISB in the read of the architected counter, guarantees that a subsequent delay loop can not be executed until the readX() has returned its result. Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Will Deacon <will.deacon@arm.com>
Diffstat (limited to 'arch/arm64/include/asm/acpi.h')
0 files changed, 0 insertions, 0 deletions