On Wed, Oct 21, 2026 at 10:43:36AM -0700, Jonathan Cameron wrote: > > +/* > > + * The spec uses 4KB pages for sizes and alignment throughout, see v1.4B > > + * sections 3.3, 3.13, 3.14 and 3.15. > > + */ > > +#define ARM_DRTM_PAGE_SIZE 4096 > > Maybe use SZ_4K from linux/sizes.h
Done > > +/* v1.4B section 3.3 "DRTM_FEATURES" */ > > +#define ARM_DRTM_SMC_FEATURES (ARM_DRTM_SMC_FN_BASE + > > 0x01) > > +/* X1 input parameter */ > > +#define ARM_DRTM_FEATURE_SELECTOR BIT_U64(63) > > Maybe define the alternate masking for function ID - for completeness if > nothing else. #define ARM_DRTM_FEATURE_FUNCID_MASK GENMAKS_U64(31, 0) > > +/* v1.4B Table 6 "DMA protection features" */ > > +#define ARM_DRTM_FEATURE_DMA_PROTECTION 0x03 > > +#define ARM_DRTM_DMA_PROTECTION_MASK GENMASK_U64(7, 0) > > +/* Only valid if ARM_DRTM_DMA_PROTECTION_REGION is supported */ > > +#define ARM_DRTM_MAX_REGIONS_MASK GENMASK_U64(23, 8) > > + > > +/* > > + * DMA protection types. ARM_DRTM_DMA_PROTECTION_MASK is a bitmap indexed > > by > > + * these, and the Launch Features ARM_DRTM_LAUNCH_DMA_PROTECTION_MASK field > > + * holds one. > > + */ > > +#define ARM_DRTM_DMA_PROTECTION_COMPLETE 0 > > +#define ARM_DRTM_DMA_PROTECTION_REGION 1 > > The dual use of these for bitmap indexes in one place and > values in another seems fragile. Maybe it is better to have > different naming for the two even though the values match? My interpretation is this is the intent of the spec. One place is a bitmap of options and the other place is the bitmap index of a valid option that was selected. So they should have the numbering always. I actually preferred it like this after you suggested it > > > +/* v1.4B section 3.4 "DRTM_DYNAMIC_LAUNCH" */ > > +#define ARM_DRTM_SMC_DYNAMIC_LAUNCH (ARM_DRTM_SMC_FN_BASE + > > 0x04) > > + > > +/* v1.4B section 3.5 "DRTM_UNPROTECT_MEMORY" */ > > +#define ARM_DRTM_SMC_UNPROTECT_MEMORY (ARM_DRTM_SMC_FN_BASE + > > 0x03) > > + > > +/* v1.4B section 3.6 "DRTM_CLOSE_LOCALITY" */ > > +#define ARM_DRTM_SMC_CLOSE_LOCALITY (ARM_DRTM_SMC_FN_BASE + > > 0x05) > > + > > +/* v1.4B section 3.7 "DRTM_GET_ERROR" */ > > +#define ARM_DRTM_SMC_GET_ERROR (ARM_DRTM_SMC_FN_BASE + > > 0x06) > > + > > +/* v1.4B section 3.8 "DRTM_SET_ERROR" */ > > I know I'm the one who asks for references, but maybe the SMC numbers are > obvious > enough without given the name matches the spec section? The table references > etc below are excellent! The do no harm beyond a bit of bloat though so I > don't > mind if you want to keep them. Let's keep them, the comment visually sets the sections apart.. > > +/* v1.4B Table 8 "Definition for error IDs (Bits[10:3])" */ > > +#define ARM_DRTM_ERROR_ID_NONE 0x0 > > +#define ARM_DRTM_ERROR_ID_PARAMETERS 0x2 > > +#define ARM_DRTM_ERROR_ID_SECURE_EXCEPTION 0x3 > > +#define ARM_DRTM_ERROR_ID_TCB_HASH_UNLOCKED 0x4 > > I'd use NOT_LOCKED to align with spec. Maybe it makes a subtle > difference somewhere? UNLOCKED might imply a transition to that > state, where as NOT_LOCKED doesn't. Meh, doesn't really matter > as I'm probably over thinking this. Sure, easy Thanks, Jason
