Re: [PATCH v6,04/24] v4l: add documentation for restricted memory flag

[Nicolas Dufresne <nicolas.dufresne@collabora.com>]

Hi,

Le mercredi 12 juin 2024 à 13:37 +0900, Tomasz Figa a écrit :
> > Why is this flag needed ? Given that the usage model requires the V4L2
> > device to be a dma buf importer, why would userspace set the
> > V4L2_BUF_CAP_SUPPORTS_RESTRICTED_MEM flag and pass a non-restricted
> > buffer to the device ?
> 
> Given that the flag is specified at REQBUF / CREATE_BUFS time, it's
> actually useful to tell the driver the queue is operating in restricted
> (aka secure) mode.
> 
> I suppose we could handle that at the time of a first QBUF, but that
> would make the driver initialization and validation quite a bit of pain.
> So I'd say that the design being proposed here makes things simpler and
> more clear, even if it doesn't add any extra functionality.

There is few more reasons I notice in previous series (haven't read the latest):

- The driver needs to communicate through the OPTEE rather then SCP and some
communication are needed just to figure-out things like supported profile/level
resolutions etc.
- The driver needs to allocate auxiliary buffers in secure heap too, allocation
at runtime are not the best

Note that the discussion around this flag already took place in the very first
iteration of the serie, it was originally using a CID and that was a proposed
replacement from Hans.

regards,
Nicolas