> static int tegra_drm_open(struct drm_device *drm, struct drm_file *filp) > { > - return 0; > + struct tegra_drm_fpriv *fpriv; > + int err = 0; > + > + fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL); > + if (!fpriv) > + return -ENOMEM; > + > + INIT_LIST_HEAD(&fpriv->contexts); > + filp->driver_priv = fpriv; > +
who frees this? > +struct tegra_drm_syncpt_incr_args { > + __u32 id; > +}; add 32-bits of padding here > + > +struct tegra_drm_syncpt_wait_args { > + __u32 id; > + __u32 thresh; > + __s32 timeout; > + __u32 value; > +}; > + > +#define DRM_TEGRA_NO_TIMEOUT (-1) > + > +struct tegra_drm_open_channel_args { > + __u32 class; > + void *context; no pointers use u64, align them to 64-bits, so 32-bits of padding, > +}; > + > +struct tegra_drm_get_channel_param_args { > + void *context; > + __u32 value; Same padding + uint64_t for void * > +}; > + > +struct tegra_drm_syncpt_incr { > + __u32 syncpt_id; > + __u32 syncpt_incrs; > +}; > + > +struct tegra_drm_cmdbuf { > + __u32 mem; > + __u32 offset; > + __u32 words; > +}; add padding > + > +struct tegra_drm_reloc { > + __u32 cmdbuf_mem; > + __u32 cmdbuf_offset; > + __u32 target; > + __u32 target_offset; > + __u32 shift; > +}; add padding > + > +struct tegra_drm_waitchk { > + __u32 mem; > + __u32 offset; > + __u32 syncpt_id; > + __u32 thresh; > +}; > + > +struct tegra_drm_submit_args { > + void *context; > + __u32 num_syncpt_incrs; > + __u32 num_cmdbufs; > + __u32 num_relocs; > + __u32 submit_version; > + __u32 num_waitchks; > + __u32 waitchk_mask; > + __u32 timeout; > + struct tegra_drm_syncpt_incrs *syncpt_incrs; > + struct tegra_drm_cmdbuf *cmdbufs; > + struct tegra_drm_reloc *relocs; > + struct tegra_drm_waitchk *waitchks; > + > + __u32 pad[5]; /* future expansion */ > + __u32 fence; /* Return value */ > +}; lose all the pointers for 64-bit aligned uint64_t. Probably should align all of these on __u64 and __u32 usage if possible. i'll look at the rest of the patches, but I need to know what commands can be submitted via this interface and what are the security implications of it. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/