summaryrefslogtreecommitdiffstats
path: root/arch/arm64/include/uapi
diff options
context:
space:
mode:
authorMark Brown <broonie@kernel.org>2024-02-09 17:53:36 +0100
committerCatalin Marinas <catalin.marinas@arm.com>2024-02-22 20:32:47 +0100
commit21eb468e9fc11692952c42f86a44d07f94803d4f (patch)
tree2605d7ceb033f3375ad2800ca51de833704771a5 /arch/arm64/include/uapi
parentarm64: make member of struct pt_regs and it's offset macro in the same order (diff)
downloadlinux-21eb468e9fc11692952c42f86a44d07f94803d4f.tar.xz
linux-21eb468e9fc11692952c42f86a44d07f94803d4f.zip
arm64/sve: Document that __SVE_VQ_MAX is much larger than needed
__SVE_VQ_MAX is defined without comment as 512 but the actual architectural maximum is 16, a substantial difference which might not be obvious to readers especially given the several different units used for specifying vector sizes in various contexts and the fact that it's often used via macros. In an effort to minimise surprises for users who might assume the value is the architectural maximum and use it to do things like size allocations add a comment noting the difference, and add a note for SVE_VQ_MAX to aid discoverability. Signed-off-by: Mark Brown <broonie@kernel.org> Acked-by: Dave Martin <Dave.Martin@arm.com> Link: https://lore.kernel.org/r/20240209-arm64-sve-vl-max-comment-v2-1-111b283469ee@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Diffstat (limited to 'arch/arm64/include/uapi')
-rw-r--r--arch/arm64/include/uapi/asm/sve_context.h11
1 files changed, 11 insertions, 0 deletions
diff --git a/arch/arm64/include/uapi/asm/sve_context.h b/arch/arm64/include/uapi/asm/sve_context.h
index 754ab751b523..72aefc081061 100644
--- a/arch/arm64/include/uapi/asm/sve_context.h
+++ b/arch/arm64/include/uapi/asm/sve_context.h
@@ -13,6 +13,17 @@
#define __SVE_VQ_BYTES 16 /* number of bytes per quadword */
+/*
+ * Yes, __SVE_VQ_MAX is 512 QUADWORDS.
+ *
+ * To help ensure forward portability, this is much larger than the
+ * current maximum value defined by the SVE architecture. While arrays
+ * or static allocations can be sized based on this value, watch out!
+ * It will waste a surprisingly large amount of memory.
+ *
+ * Dynamic sizing based on the actual runtime vector length is likely to
+ * be preferable for most purposes.
+ */
#define __SVE_VQ_MIN 1
#define __SVE_VQ_MAX 512