Mon, Feb 09, 2026 at 09:08:03PM +0100, [email protected] wrote: >On Mon, Feb 9, 2026 at 7:38 AM Jiri Pirko <[email protected]> wrote: >> >> From: Jiri Pirko <[email protected]> >> >> Currently the flags, which are unused, are validated for all heaps. >> Since the follow-up patch introduces a flag valid for only one of the >> heaps, allow to specify the valid flags per-heap. > >I'm not really in this space anymore, so take my feedback with a grain of salt. > >While the heap allocate flags argument is unused, it was intended to >be used for generic allocation flags that would apply to all or at >least a wide majority of heaps. > >It was definitely not added to allow for per-heap or heap specific >flags (as this patch tries to utilize it). That was the mess we had >with ION driver that we were trying to avoid. > >The intent of dma-buf heaps is to try to abstract all the different >device memory constraints so there only needs to be a [usage] -> >[heap] mapping, and otherwise userland can be generalized so that it >doesn't need to be re-written to work with different devices/memory >types. Adding heap-specific allocation flags prevents that >generalization. > >So instead of adding heap specific flags, the general advice has been >to add a separate heap name for the flag property.
Right, my original idea was to add a separate heap. Then I spotted the flags and seemed like a great fit. Was not aware or the history or original intention. Would be probably good to document it for future generations. So instead of flag, I will add heap named something like "system_cc_decrypted" to implement this. Thanks!
