summaryrefslogtreecommitdiff
path: root/mm/util.c
diff options
context:
space:
mode:
authorMark Brown <broonie@kernel.org>2025-06-24 01:30:49 +0300
committerMark Brown <broonie@kernel.org>2025-06-24 01:30:49 +0300
commit1256eb42db5d1635f4c6da5b1b58db0b53320883 (patch)
tree4a06ef5a4ed8e2f67ead59ad4257a7e6524ed8b1 /mm/util.c
parent5fc2c383125c2b4b6037e02ad8796b776b25e6d0 (diff)
parent8f9cf02c8852837923f1cdacfcc92e138513325c (diff)
downloadlinux-1256eb42db5d1635f4c6da5b1b58db0b53320883.tar.xz
spi: microchip-core-qspi: Add regular transfers
Merge series from Conor Dooley <conor@kernel.org>: This is a v2 of a patchset I sent about this time last year, adding the regular transfer_one_message op to the microchip-core-qspi driver. In that v1 Mark expressed his dislike for that op, so v2 is using prepare/unprepare/transfer_one instead. The unprepare implementation still contains the 750 us delay that the driver had back in v1. I've heard a suggestion internally as to why this is needed, but it was unsubstantiated, so I still have no justification for it. I held off on sending a v2 because of a lack of explanation for the delay, but I don't wanna hold off forever for something I might never understand.
Diffstat (limited to 'mm/util.c')
-rw-r--r--mm/util.c40
1 files changed, 40 insertions, 0 deletions
diff --git a/mm/util.c b/mm/util.c
index 448117da071f..0b270c43d7d1 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -1131,3 +1131,43 @@ void flush_dcache_folio(struct folio *folio)
}
EXPORT_SYMBOL(flush_dcache_folio);
#endif
+
+/**
+ * compat_vma_mmap_prepare() - Apply the file's .mmap_prepare() hook to an
+ * existing VMA
+ * @file: The file which possesss an f_op->mmap_prepare() hook
+ * @vma: The VMA to apply the .mmap_prepare() hook to.
+ *
+ * Ordinarily, .mmap_prepare() is invoked directly upon mmap(). However, certain
+ * 'wrapper' file systems invoke a nested mmap hook of an underlying file.
+ *
+ * Until all filesystems are converted to use .mmap_prepare(), we must be
+ * conservative and continue to invoke these 'wrapper' filesystems using the
+ * deprecated .mmap() hook.
+ *
+ * However we have a problem if the underlying file system possesses an
+ * .mmap_prepare() hook, as we are in a different context when we invoke the
+ * .mmap() hook, already having a VMA to deal with.
+ *
+ * compat_vma_mmap_prepare() is a compatibility function that takes VMA state,
+ * establishes a struct vm_area_desc descriptor, passes to the underlying
+ * .mmap_prepare() hook and applies any changes performed by it.
+ *
+ * Once the conversion of filesystems is complete this function will no longer
+ * be required and will be removed.
+ *
+ * Returns: 0 on success or error.
+ */
+int compat_vma_mmap_prepare(struct file *file, struct vm_area_struct *vma)
+{
+ struct vm_area_desc desc;
+ int err;
+
+ err = file->f_op->mmap_prepare(vma_to_desc(vma, &desc));
+ if (err)
+ return err;
+ set_vma_from_desc(vma, &desc);
+
+ return 0;
+}
+EXPORT_SYMBOL(compat_vma_mmap_prepare);