Tue, Mar 24, 2026 at 12:25:46AM +0100, [email protected] wrote: >On Mon, Mar 16, 2026 at 5:59 AM Jiri Pirko <[email protected]> wrote:
[..] >> --- a/drivers/dma-buf/heaps/system_heap.c >> +++ b/drivers/dma-buf/heaps/system_heap.c >> @@ -10,17 +10,25 @@ >> * Andrew F. Davis <[email protected]> >> */ >> >> +#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! [..]
