Tue, Mar 24, 2026 at 12:25:46AM +0100, tjmercier@google.com wrote:
On Mon, Mar 16, 2026 at 5:59 AM Jiri Pirko jiri@resnulli.us wrote:
[..]
--- a/drivers/dma-buf/heaps/system_heap.c +++ b/drivers/dma-buf/heaps/system_heap.c @@ -10,17 +10,25 @@
Andrew F. Davis <afd@ti.com>*/
+#include <linux/cc_platform.h> #include <linux/dma-buf.h> #include <linux/dma-mapping.h> #include <linux/dma-heap.h> #include <linux/err.h> #include <linux/highmem.h> +#include <linux/mem_encrypt.h> #include <linux/mm.h> +#include <linux/set_memory.h> #include <linux/module.h> +#include <linux/pgtable.h> #include <linux/scatterlist.h> #include <linux/slab.h> #include <linux/vmalloc.h>
+struct system_heap_priv {
bool decrypted;+};
Hi Jiri,
I wonder if it'd better to call this cc_decrypted (or I guess cc_shared based on Robin's comment in the previous patch) like the DMA attr? There's a separate effort for "restricted" heaps with TEE for (encrypted) video playback, which doesn't involve VMs or RDMA. I think the cc_ prefix might help avoid any confusion between the usecase here and restricted heaps.
Sure. I'll rename this.
Thanks!
[..]