diff options
| author | Nicholas Piggin <npiggin@gmail.com> | 2020-05-08 14:34:00 +1000 |
|---|---|---|
| committer | Michael Ellerman <mpe@ellerman.id.au> | 2020-05-19 00:10:05 +1000 |
| commit | d7b14c5c042865070a1411078ab49ea17bad0b41 (patch) | |
| tree | 35bb0b32fea8fb00ffe4b2bd904534a37aa8ef97 /arch/powerpc/kernel/setup_64.c | |
| parent | dff681e95a23f28b3c688a8bd5535f78bd726bc8 (diff) | |
| download | linux-d7b14c5c042865070a1411078ab49ea17bad0b41.tar.gz linux-d7b14c5c042865070a1411078ab49ea17bad0b41.tar.bz2 linux-d7b14c5c042865070a1411078ab49ea17bad0b41.zip | |
powerpc/pseries/ras: fwnmi sreset should not interlock
PAPR does not specify that fwnmi sreset should be interlocked, and
PowerVM (and therefore now QEMU) do not require it.
These "ibm,nmi-interlock" calls are ignored by firmware, but there
is a possibility that the sreset could have interrupted a machine
check and release the machine check's interlock too early, corrupting
it if another machine check came in.
This is an extremely rare case, but it should be fixed for clarity
and reducing the code executed in the sreset path. Firmware also
does not provide error information for the sreset case to look at, so
remove that comment.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
[mpe: Use __be64 to silence some sparse warnings]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200508043408.886394-9-npiggin@gmail.com
Diffstat (limited to 'arch/powerpc/kernel/setup_64.c')
0 files changed, 0 insertions, 0 deletions