On Mon, Aug 17, 2026 at 10:17:43AM +0530, Ekansh Gupta wrote: > Introduce DRM_IOCTL_QDA_QUERY, a query IOCTL that lets user-space > retrieve information about the DSP a given /dev/accel/accel* node > represents. > > The IOCTL takes a query_type selector as input, so it can be extended > to return additional parameters (capabilities, attributes) in the > future without adding new IOCTLs: drm_ioctl() zero-extends the argument > structure, so new fields can be appended to struct drm_qda_query as > long as they go at the end. The first supported query, > QDA_QUERY_DSP_NAME, returns the DSP domain name (e.g. "cdsp", "adsp"). > > The UAPI header include/uapi/drm/qda_accel.h defines the command number, > the DRM_IOWR IOCTL definition, the query_type values, and struct > drm_qda_query. It follows the standard DRM UAPI conventions: fixed-width > types, a C++ extern "C" guard, and GPL-2.0-only WITH Linux-syscall-note > licensing. > > qda_ioctl_query() validates the reserved pad field, dispatches on > query_type, and copies the DSP name from qda_dev.dsp_name into the > user-supplied buffer with strscpy(). Unknown query types are rejected > with -EINVAL. > > qda_drv.c registers the qda_ioctls[] table with the drm_driver so the > DRM core dispatches DRM_IOCTL_QDA_QUERY to qda_ioctl_query().
Please tell your AI agent to stop describing patch contents. Ask it to describe the reasons for the change. > > Assisted-by: Claude:claude-sonnet-5 > Signed-off-by: Ekansh Gupta <[email protected]> > --- > Changes in v2: > - Add a query_type input selector so the IOCTL can return different > parameters in future, and switch DRM_IOR -> DRM_IOWR so the input > reaches the kernel (Dmitry Baryshkov) > - Reject unknown query types and a non-zero pad with -EINVAL > + > +/* > + * QDA IOCTL command numbers > + * > + * These define the command numbers for QDA-specific IOCTLs. > + * They are used with DRM_COMMAND_BASE to create the full IOCTL numbers. > + */ > +#define DRM_QDA_QUERY 0x00 > + > +/* > + * QDA IOCTL definitions > + * > + * These macros define the actual IOCTL numbers used by userspace > applications. > + * They combine the command numbers with DRM_COMMAND_BASE and specify the > + * data structure and direction (read/write) for each IOCTL. Is it not obvious? > + */ > +#define DRM_IOCTL_QDA_QUERY DRM_IOWR(DRM_COMMAND_BASE + > DRM_QDA_QUERY, \ > + struct drm_qda_query) > + > +/* Query type definitions for drm_qda_query */ > +#define QDA_QUERY_DSP_NAME 1 Why is it necessary for the userspace? > + > +/** > + * struct drm_qda_query - Device information query structure > + * @query_type: Type of query (input) > + * @pad: Padding for 64-bit alignment (must be zero) > + * @dsp_name: Null-terminated name of the DSP (returned when query_type is > QDA_QUERY_DSP_NAME) > + * > + * This structure is used with DRM_IOCTL_QDA_QUERY to query device attributes > + * based on @query_type. > + */ > +struct drm_qda_query { > + __u32 query_type; > + __u32 pad; What for? If you have u8 array afterwards, you don't need the padding. > + __u8 dsp_name[16]; > +}; > + > +#if defined(__cplusplus) > +} > +#endif > + > +#endif /* __QDA_ACCEL_H__ */ > > -- > 2.34.1 > -- With best wishes Dmitry
