summaryrefslogtreecommitdiffstats
path: root/arch/xtensa
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2021-08-26 11:26:00 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2021-08-26 11:26:00 -0700
commit1a6d80ff2419e8ad627b4bf4775a8b4c70af535d (patch)
tree83b814e10525c0fa9dd56d57879112c79edc4c68 /arch/xtensa
parent97d8cc20085f63cfbf0b123295e12cf9ad66a03c (diff)
parent3eb9cdffb39701743973382860f214026f4d7825 (diff)
downloadlinux-stable-1a6d80ff2419e8ad627b4bf4775a8b4c70af535d.tar.gz
linux-stable-1a6d80ff2419e8ad627b4bf4775a8b4c70af535d.tar.bz2
linux-stable-1a6d80ff2419e8ad627b4bf4775a8b4c70af535d.zip
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fix from Will Deacon: "We received a report this week that the generic version of pfn_valid(), which we switched to this merge window in 16c9afc77660 ("arm64/mm: drop HAVE_ARCH_PFN_VALID"), interacts badly with dma_map_resource() due to the following check: /* Don't allow RAM to be mapped */ if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr)))) return DMA_MAPPING_ERROR; Since the ongoing saga to determine the semantics of pfn_valid() is unlikely to be resolved this week (does it indicate valid memory, or just the presence of a struct page, or whether that struct page has been initialised?), just revert back to our old version of pfn_valid() for 5.14. Summary: - Fix dma_map_resource() by reverting back to old pfn_valid() code" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: Partially revert "arm64/mm: drop HAVE_ARCH_PFN_VALID"
Diffstat (limited to 'arch/xtensa')
0 files changed, 0 insertions, 0 deletions