summaryrefslogtreecommitdiff
path: root/crypto/echainiv.c
diff options
context:
space:
mode:
authorNathan Lynch <nathanl@linux.ibm.com>2023-01-24 17:04:48 +0300
committerMichael Ellerman <mpe@ellerman.id.au>2023-01-30 09:53:05 +0300
commit12fd66651df6c807b7b6f420ee0fd420f54991f4 (patch)
treedf61e5f84f38c1bf61259f2545863515e8979f31 /crypto/echainiv.c
parent599af49155467148afaf0bc3c0114bd80fd4491f (diff)
downloadlinux-12fd66651df6c807b7b6f420ee0fd420f54991f4.tar.xz
powerpc/rtas: upgrade internal arch spinlocks
At the time commit f97bb36f705d ("powerpc/rtas: Turn rtas lock into a raw spinlock") was written, the spinlock lockup detection code called __delay(), which will not make progress if the timebase is not advancing. Since the interprocessor timebase synchronization sequence for chrp, cell, and some now-unsupported Power models can temporarily freeze the timebase through an RTAS function (freeze-time-base), the lock that serializes most RTAS calls was converted to arch_spinlock_t to prevent kernel hangs in the lockup detection code. However, commit bc88c10d7e69 ("locking/spinlock/debug: Remove spinlock lockup detection code") removed that inconvenient property from the lock debug code several years ago. So now it should be safe to reintroduce generic locks into the RTAS support code, primarily to increase lockdep coverage. Making rtas_lock a spinlock_t would violate lock type nesting rules because it can be acquired while holding raw locks, e.g. pci_lock and irq_desc->lock. So convert it to raw_spinlock_t. There's no apparent reason not to upgrade timebase_lock as well. Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20230124140448.45938-5-nathanl@linux.ibm.com
Diffstat (limited to 'crypto/echainiv.c')
0 files changed, 0 insertions, 0 deletions