[PATCH v2 11/15] arm64: drtm: Add macro definitions for DEN0113

[Jason Gunthorpe]

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