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
